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

1、最近几天被这个问题困惑了许久。不禁感叹微软的东东真是越做越烂了，也终于明白了时隔12年大家仍然死守VC6的原因。用VC2005编译的程序，编译时没有任何错误，但是运行时就是提示应用程序正常初始化失败”！查找了各方面资料，做了各种尝试，网上说什么的都 有：有让安装vc2005 sp1补丁的；有让安装 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或exe中要引用的CRT、M

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

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

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

6、quot;应用程序配置不正确”，大多也是 因为上面所说的CRT、MFC、ATL库版本与应用程序不匹配导致的，可以如法 炮制进行解决；在网上找出了这些方法：方法一：在类似 C:Program FilesMicrosoft Visual Studio 8VCredistDebug_NonRedistx86Microsoft.VC80,DebugCRT下找到了下列文件：msvcm80d.dllmsvcp80d.dll msvcr80d.dll Microsoft.VC80.DebugCRT .manifest 把这几个文件拷贝到目标机器上，与运行程序同一文件夹或放到system32下，就可以正确运行

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

8、32目录下所有的 msvc*.dll都复制到这台机的运行目录，还是不行！极度郁闷X-!后来实在没辙了，就在 VC环境中才T开了 EXE来查看它内嵌的manifest资源，无奈了看了一会，带着心中对manifest的咒骂，突然发现这个manifest带了两个版本CRT的依赖：再打开 Microsoft.VC80.CRT .manifest 一看，是这样：就是说，我们 EXE的Manifest里多了一个版本依赖，那就把后面那个依赖删除试试。 于是就把工程设置的生成manifest的选项去掉，手工改了一下 manifest放到程序目录下，发现果然可以运行了！还有个问题没有明白，就是VC为什么在自 傻

9、脆anifest里带了两个依赖呢，上网再查了 一下，发现在 msdnonline 上说'8.0.50608.0'这个版本是在 XP下用的，8.0.50727.762'这个版本是在 Vista 下用的(),可是我用的是'8.0.50727.762'在XP下运行的好好的！想不通是它错了还是别的原因。后来在 CRT的源码里面搜索'8.0.50727.762',找到了'8.0.50608.0'也在那里。#if defined _USE_RTM_VERSION#define _CRT_ASSEMBLY_VERSION8.0.5060

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

11、决"应用程序配置不正确，程序无法启动"2009-03-03 10:05在使用VC+200琳境下生成的程序，放置到未安装VC环境的机器下后，有时候 会出现程序无法执行的错误，其提示是：应用程序配置不正确，程序无法启动， 重新安装应用程序可能解决问题。实际上，重装是解决不了问题的，解决的一种方法是查看*ermediate.manifest 文件，比如文件的内容是：<?xml version='1.0' encoding='UTF-8' standalone='yes'?><assembly xmln

12、s='urn:schemas-microsoft-com:asm.v1'manifestVersion='1.0'><dependency><dependentAssembly><assemblyIdentity type='win32' name='Microsoft.VC80.CRT'version='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b&

13、#39; /></dependentAssembly></dependency><dependency><dependentAssembly><assemblyIdentity type='win32' name='Microsoft.VC80.MFC'version='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /></depende

14、ntAssembly></dependency><dependency><dependentAssembly>version='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /></dependentAssembly></dependency></assembly>需要注意这个文件中的3个关键词：Microsoft.VC80.CRT , Microsoft.

15、VC80.MFC 和 Microsoft.VC80.DebugCRT。寻找到.”Program Files"Microsoft Visual Studio 8"VC"redist文件夹下面，找到这些名称的子文件夹，拷贝它们下面所有的文件到希望发布的EXES：件下面，一起打包。这些文件也就是 mfc80.dll , msvcr80.dll , msvcp80.dll 和 Microsoft.VC80.CRT.manifest 等。此错误发生的原因是在目标机器上需要这些 文件的支持。Visual C+ LibrariesVisual C+ Libraries as S

16、hared Side-by-Side AssembliesIn Visual C+ 2005, the ATL, MFC,Standard C+, and CRTlibraries support the new deployment model available on Windows XP, Windows Server 2003, and WindowsVista. The DLLs corresponding to all Visual C+libraries have been grouped into several shared side-by-side assemblies a

17、nd are installed into the native assembly cache, also called the WinSxSfolder, under the operating system root directory. Similarly, while building a C+ application using Visual C+ 2005, by default the compiler and the linker generate a manifest file that describes runtime dependencies of this appli

18、cation on Visual C+ libraries.Visual C+ libraries cannot be used by a C/C+ application without a manifest binding the application to these libraries. If a C/C+ application that depends on a Visual C+library does not use a manifest, then an attempt to load the Visual C+ library as a dependent DLL fro

19、m the application-local folder will result in an error messageindicating that this is an unsupported way of loading a Visual C+ library.-Note:On versions of Windows that do not support deployment of shared side-by-side assemblies, such as Windows98 and Windows 2000 Server, the Visual C+ libraries ar

20、e installed in the System32 folder and WinSxS folder under the operating system root directory. This setup enables running Visual C+ applications on these operating system versions because they do not support manifest-based binding of applications todependent DLLs. On these operating systems, when a

21、n application is loaded, the corresponding manifest file is ignored and the operating systems searches for dependent DLLs using paths set in the current running environment. However, on upgrading the operating system to a version that support manifest-based binding, such as WindowsXP, Windows Server

22、 2003, or Windows Vista, applications built with manifests start using the DLLs installed in the WinSxS folder.This change to the deployment model of Visual C+libraries prevents the problem of version conflicts between DLLs that occur whenyou add updates or configurations to a machine, and will allo

23、w support of side-by-side installation of two different Visual C+ toolsets. It will also allow you to produce reliable, self-describing applications and components that will not conflict with existing components. For more information on the advantages of new deployment model, please see Concepts of Isolated Applications and Side-by-side Assemblies . To learn about how this may impact deployment of existing native C+ applications, please refer to Redistributing Visual C+ Files .Visual C+ libraries have been packaged in several shared side-by-side assemblies with