VC200应用程序正常初始化失败-0xc0150002

1、最近几天被这个问题困惑了许久。不禁感叹微软的东东真是越做越烂了，也终于明白了时隔 12 年大家仍然死守 VC6 的原因。用 VC2005 编译的程序，编译时没有任何错误，但是运行时就是提示应用程序正常初始化失败”！查找了各方面资料，做了各种尝试，网上说什么的都有：有让安装 vc2005sp1 补丁的；有让安装 vcredist_x86.exe 的；有让把 CRT 库的 dll 直接拷贝到程序目录的；有让清理注册表的；有让装.NetFramework 新版本的;有让查manifest 的；结果我尝试了半天，几乎都是浪费时间。上面最后一条说的还算正确，只是作者把事情描述得太繁琐了。现在把处理的方法

2、说一下，省得大家再走弯路：1 .VC2003、VC2005、VC2008 及其后续版本，对底层最基本的 CRT、MFC、ATL 库都进行了重构，为了避免不同版本的库引起冲突，重构后的库文件一般放在C:windowsWinSxS 文件夹中，并用特定的文件夹文件名称进行标识；2 .与 VC6 不同，VC2003、VC2005、VC2008 及其后续版本，引入了 manifest清单的概念，即应用程序编译后会同时生成对应的.manifest 文件,并将该.manifest 文件作为资源编译到 dll 或者 exe 中去。.manifest 文件实际上是一个 XML 格式的文本文件，里面记录了 dll

3、 或 exe 中要引用的 CRT、MFC、ATL 库的版本和名称。VC6 编译的应用程序对 CRT、MFC、ATL 的 dll 都是直接调用，而 VC2003、VC2005、VC2008编译的程序都是先查询编译到资源中的 manifest 中的记录，然后按照记录提供的版本和名称去搜寻对应的 CRT、MFC、ATL 库以及随库发布的.manifest 文件，搜寻的路径包括当前目录、C:windowsWinSxS 等等，如果没有找到对应的库文件，则提示应用程序正常初始化失败”；3 .因此解决这个问题的办法就是：（a）用文本编辑器打开 exe 或 dll 对应的.manifest 文件,查看它引用的

4、 CRT、MFC、ATL 库的版本；或者，用 UltraEdit 直接打开 exe 或者 dll,从资源区中找到编译进去的.manifest 信息,找到它引用的CRT、MFC、ATL 库的版本；或者，运行程序，当程序弹出应用程序正常初始化失败”对话框时，在桌面上右键点击我的电脑-管理”-事件查看器”-系统”，双击查看其中的记录，可以看到出错的原因是因为缺少了某某版本的 CRT、MFC、ATL 库，记录下这个版本信息；（b）记录到的库的版本信息一般类似于“Microsoft.VC90.DebugCRT,之后至 UC:windowsWinSxS 或者 VC200X 的安装文件夹中搜索包含这个字符串

5、的文件夹和文件， 将搜索到的 dll 和.manifest 文件都拷贝到应用程序所在的文件夹中，其中 1.manifest 文件必须重命名为“Microsoft.VC90.DebugCRT.manifest 这里以 （Microsoft.VC90.DebugCRT 为例） ，这样应用程序就可以正常运行了；（c）注意：库的.manifest 文件和 dll 要一同拷贝到应用程序根目录去，因为应用程序会将编译到内部的 manifest 信息与外部的.manifest 文件进行对比，之后才会对库的 dll 进行调用。如果只拷贝库的 dll 文件是没有用的；4.如果本机编译和运行程序都 ok,但是将编

6、译好的程序拿到其它机器上确无法运行，则多半也是这个原因。另外，如果提示应用程序配置不正确”，大多也是因为上面所说的 CRT、MFC、 ATL 库版本与应用程序不匹配导致的，可以如法炮制进行解决；在网上找出了这些方法：方法一：在类似 C:ProgramFilesMicrosoftVisualStudio8VCredistDebug_NonRedistx86Microsoft.VC80,DebugCRT 下找到了下列文件：msvcm80d.dllmsvcp80d.dllmsvcr80d.dllMicrosoft.VC80.DebugCRT.manifest 把这几个文件拷贝到目标机器上， 与运行程

7、序同一文件夹或放到 system32 下，就可以正确运行了。其他 release 版、MFC 程序什么的都是拷 redist 下相应文件夹下的文件就可以了，文件夹后都有标识！方法二：修改编译选项，将/MD 或/MDd 改为/MT 或/MTd,这样就实现了对 VC 运行时库的静态链接，在运行时就不再需要 VC 的 dll 了。方法三：工程属性配置属性常规MFC 的使用，选择在静态库中使用 mfc”这样生成的 exe 文件应该就可以在其他机器上跑了。方法四：你的 vc8 安装盘上找到再分发包 vcredist_xxx.exe 和你的程序捆绑安装在大部分机上都可以运行了，唯独在我的测试机上还是报应用

8、程序配置错误。刚开始怀疑是还缺少 dll,在能跑的机上把 windows/system32 目录下所有的 msvc*.dll 都复制到这台机的运行目录，还是不行！极度郁闷X-!后来实在没辙了，就在 VC 环境中才 T 开了 EXE 来查看它内嵌的 manifest 资源，无奈了看了一会，带着心中对 manifest 的咒骂，突然发现这个 manifest 带了两个版本 CRT 的依赖：再打开 Microsoft.VC80.CRT.manifest 一看，是这样：就是说，我们 EXE 的 Manifest 里多了一个版本依赖，那就把后面那个依赖删除试试。于是就把工程设置的生成 manifest

9、的选项去掉，手工改了一下 manifest 放到程序目录下，发现果然可以运行了！还有个问题没有明白，就是 VC 为什么在自傻脆 anifest 里带了两个依赖呢，上网再查了一下，发现在msdnonline 上说8.0.50608.0这个版本是在 XP 下用的，8.0.50727.762这个版本是在 Vista 下用的(http:/ XP 下运行的好好的！想不通是它错了还是别的原因。后来在 CRT 的源码里面搜索8.0.50727.762,找到了8.0.50608.0也在那里。#ifdefined_USE_RTM_VERSION#define_CRT_ASSEMBLY_VERSION8.0.50

10、608.0”#else#define_CRT_ASSEMBLY_VERSIOI8.0.50727.762”#endif显然默认的版本是“8.0.50727.762:除非定义了_USE_RTM_VERSION!那为什么我们的工程会生成两个版本的依赖呢，明明这个地方是二选一的。一开始怀疑是工程设置引起的，我就把我们的工程拷出来，把里面的文件删掉，再复制一些向导生成的文件进来，编译一看，manifest里只有一个8.0.50727.762,说明工程设置没有问题！最后我怀疑是工程链接的那些库的问题，因为有些库是用 VC6 或者 VC2003 编译的，但是有些库没有代码，编不了，没法尝试了。VC+解决应

11、用程序配置不正确，程序无法启动2009-03-0310:05在使用 VC+200 琳境下生成的程序， 放置到未安装 VC 环境的机器下后， 有时候会出现程序无法执行的错误，其提示是：应用程序配置不正确，程序无法启动，重新安装应用程序可能解决问题。实际上，重装是解决不了问题的，解决的一种方法是查看*ermediate.manifest 文件，比如文件的内容是：version=8.0.50727.762processorArchitecture=x86publicKeyToken=1fc8b3b9a1e18e3b/需要注意这个文件中的 3 个关键词：Microsoft.VC80.CR

12、T,Microsoft.VC80.MFC 和 Microsoft.VC80.DebugCRT。寻找到.”ProgramFilesMicrosoftVisualStudio8VCredist 文件夹下面， 找到这些名称的子文件夹，拷贝它们下面所有的文件到希望发布的 EXES：件下面，一起打包。这些文件也就是 mfc80.dll,msvcr80.dll,msvcp80.dll 和 Microsoft.VC80.CRT.manifest 等。此错误发生的原因是在目标机器上需要这些文件的支持。VisualC+LibrariesVisualC+LibrariesasSharedSide-by-SideA

13、ssembliesInVisualC+2005,theATL,MFC,StandardC+,andCRTlibrariessupportthenewdeploymentmodelavailableonWindowsXP,WindowsServer2003,andWindowsVista.TheDLLscorrespondingtoallVisualC+librarieshavebeengroupedintoseveralsharedside-by-sideassembliesandareinstalledintothenativeassemblycache,alsocalledtheWinSx

14、Sfolder,undertheoperatingsystemrootdirectory.Similarly,whilebuildingaC+applicationusingVisualC+2005,bydefaultthecompilerandthelinkergenerateamanifestfilethatdescribesruntimedependenciesofthisapplicationonVisualC+libraries.VisualC+librariescannotbeusedbyaC/C+applicationwithoutamanifestbindingtheappli

15、cationtotheselibraries.IfaC/C+applicationthatdependsonaVisualC+librarydoesnotuseamanifest,thenanattempttoloadtheVisualC+libraryasadependentDLLfromtheapplication-localfolderwillresultinanerrormessageindicatingthatthisisanunsupportedwayofloadingaVisualC+library.-Note:OnversionsofWindowsthatdonotsuppor

16、tdeploymentofsharedside-by-sideassemblies,suchasWindows98andWindows2000Server,theVisualC+librariesareinstalledintheSystem32folderandWinSxSfolderundertheoperatingsystemrootdirectory.ThissetupenablesrunningVisualC+applicationsontheseoperatingsystemversionsbecausetheydonotsupportmanifest-basedbindingof

17、applicationstodependentDLLs.Ontheseoperatingsystems,whenanapplicationisloaded,thecorrespondingmanifestfileisignoredandtheoperatingsystemssearchesfordependentDLLsusingpathssetinthecurrentrunningenvironment.However,onupgradingtheoperatingsystemtoaversionthatsupportmanifest-basedbinding,suchasWindowsXP

18、,WindowsServer2003,orWindowsVista,applicationsbuiltwithmanifestsstartusingtheDLLsinstalledintheWinSxSfolder.ThischangetothedeploymentmodelofVisualC+librariespreventstheproblemofversionconflictsbetweenDLLsthatoccurwhenyouaddupdatesorconfigurationstoamachine,andwillallowsupportofside-by-sideinstallati

19、onoftwodifferentVisualC+toolsets.Itwillalsoallowyoutoproducereliable,self-describingapplicationsandcomponentsthatwillnotconflictwithexistingcomponents.Formoreinformationontheadvantagesofnewdeploymentmodel,pleaseseeConceptsofIsolatedApplicationsandSide-by-sideAssemblies.TolearnabouthowthismayimpactdeploymentofexistingnativeC+applications,pleaserefertoRedistributingVisualC+Files.VisualC+librarieshavebeenpackagedinseveralsharedside-by-sideassemblieswithcorrespondingmanifestfiles.AssemblyNameMicrosoft.VC90.ATLMicrosoft.VC90.CRTMicrosoft.VC90.Deb