[zz]VC2005-应用程序正常初始化失败-0xc0150002
最近几天被这个问题困惑了许久。 不禁感叹微软的东东真是越做越烂了，也终于明白了时隔12年大家仍然死守VC6的原因。。
用VC2005编译的程序，编译时没有任何错误，但是运行时就是提示“应用程序正常初始化失败”！！ 查找了各方面资料，做了各种尝试，网上说什么的都有：有让安装vc2005 sp1补丁的；有让安装vcredist_x86.exe的; 有让把CRT库的dll直接拷贝到程序目录的; 有让清理注册表的;有让装.NetFramework新版本的;有让查manifest的;
结果我尝试了半天,几乎都是浪费时间。上面最后一条说的还算正确，只是作者把事情描述得太繁琐了。。现在把处理的方法说一下，省得大家再走弯路：
1. VC2003、VC2005、VC2008及其后续版本，对底层最基本的CRT、MFC、ATL库都进行了重构，为了避免不同版本的库引起冲突，重构后的库文件一般放在 C:\\windows\WinSxS 文件夹中,并用特定的文件夹\文件名称进行标识；
2. 与VC6不同, VC2003、VC2005、VC2008及其后续版本，引入了manifest清单的概念，即应用程序编译后会同时生成对应的.manifest文件,并将该.manifest文件作为资源编译到dll或者exe中去。.manifest文件实际上是一个XML格式的文本文件，里面记录了dll或exe中要引用的CRT、MFC、ATL库的版本和名称。VC6编译的应用程序对CRT、MFC、ATL的dll都是直接调用，而VC2003、VC2005、VC2008编译的程序都是先查询编译到资源中的manifest中的记录，然后按照记录提供的版本和名称去搜寻对应的CRT、MFC、ATL库以及随库发布的.manifest文件，搜寻的路径包括当前目录、C:\\windows\WinSxS 等等，如果没有找到对应的库文件，则提示“应用程序正常初始化失败”；
3.因此解决这个问题的办法就是：（a）用文本编辑器打开exe或dll对应的.manifest文件,查看它引用的CRT、MFC、ATL库的版本；或者，用UltraEdit直接打开exe或者dll，从资源区中找到编译进去的.manifest信息,找到它引用的CRT、MFC、ATL库的版本；或者，运行程序，当程序弹出“应用程序正常初始化失败”对话框时，在桌面上右键点击“我的电脑”－“管理”－“事件查看器”－“系统”，双击查看其中的记录，可以看到出错的原因是因为缺少了某某版本的CRT、MFC、ATL库，记录下这个版本信息；（b）记录到的库的版本信息一般类似于“Microsoft.VC90.DebugCRT”，之后到C:\\windows\WinSxS 或者VC200X的安装文件夹中搜索包含这个字符串的文件夹和文件，将搜索到的dll和.manifest文件都拷贝到应用程序所在的文件夹中,其中,.manifest文件必须重命名为“Microsoft.VC90.DebugCRT.manifest”(这里以Microsoft.VC90.DebugCRT为例)，这样应用程序就可以正常运行了；（c）注意：库的.manifest文件和dll要一同拷贝到应用程序根目录去,因为应用程序会将编译到内部的manifest信息与外部的.manifest文件进行对比,之后才会对库的dll进行调用。如果只拷贝库的dll文件是没有用的；
4.如果本机编译和运行程序都ok，但是将编译好的程序拿到其它机器上确无法运行，则多半也是这个原因。另外,如果提示"应用程序配置不正确"，大多也是因为上面所说的CRT、MFC、ATL库版本与应用程序不匹配导致的，可以如法炮制进行解决；
在网上找出了这些方法：
方法一：
在类似C:\Program
Files\Microsoft Visual Studio 8\VC\redi
st\Debug_NonRedist\x86\Microsoft.VC80.DebugCRT
下找到了下列文件：
msvcm80d.dll
msvcp80d.dll
msvcr80d.dll
Microsoft.VC80.DebugCRT.manifest
把这几个文件拷贝到目标机器上，与运行程序同一文件夹或放到system32下，就可以正确运行了。
其他release版、MFC程序什么的都是拷redist下相应文件夹下的文件就可以了,文件夹后都有标识!
方法二：
修改编译选项，将/MD或/MDd 改为 /MT或/MTd，这样就实现了对VC运行时库的静态链接，在运行时就不再需要VC的dll了。
方法三:
工程－》属性－》配置属性－》常规－》MFC的使用，选择“在静态库中使用mfc”
这样生成的exe文件应该就可以在其他机器上跑了。
方法四:
你的vc8安装盘上找到再分发包vcredist_xxx.exe和你的程序捆绑安装
在大部分机上都可以运行了，唯独在我的测试机上还是报应用程序配置错误。刚开始怀疑是还缺少dll，在能跑的机上把windows/system32目录下所有的msvc*.dll都复制到这台机的运行目录，还是不行！极度郁闷※×…！后来实在没辙了，就在VC环境中打开了EXE来查看它内嵌的manifest资源，无奈了看了一会，带着心中对manifest的咒骂，突然发现这个manifest带了两个版本CRT的依赖：
再打开Microsoft.VC80.CRT.manifest一看，是这样：
就是说，我们EXE的Manifest里多了一个版本依赖，那就把后面那个依赖删除试试。于是就把工程设置的生成manifest的选项去掉，手工改了一下manifest放到程序目录下，发现果然可以运行了！
还有个问题没有明白，就是VC为什么在自傻膍anifest里带了两个依赖呢，上网再查了一下，发现在msdnonline上说'8.0.50608.0'这个版本是在XP下用的，'8.0.50727.762'这个版本是在Vista下用的（http://msdn.microsoft.com/en-us/library/ms235342(VS.80).aspx），可是我用的是'8.0.50727.762'在XP下运行的好好的！想不通是它错了还是别的原因。后来在CRT的源码里面搜索'8.0.50727.762'，找到了～'8.0.50608.0'也在那里。
#if defined
_USE_RTM_VERSION
#define
_CRT_ASSEMBLY_VERSION “8.0.50608.0”
#else
#define _CRT_ASSEMBLY_VERSION
“8.0.50727.762”
#endif
显然默认的版本是“8.0.50727.762”，除非定义了_USE_RTM_VERSION！那为什么我们的工程会生成两个版本的依赖呢，明明这个地方是二选一的。一开始怀疑是工程设置引起的，我就把我们的工程拷出来，把里面的文件删掉，再复制一些向导生成的文件进来，编译一看，manifest里只有一个'8.0.50727.762'，说明工程设置没有问题！最后我怀疑是工程链接的那些库的问题，因为有些库是用VC6或者VC2003编译的，但是有些库没有代码，编不了，没法尝试了。
VC++ 解决"应用程序配置不正确，程序无法启动"
2009-03-03 10:05
|
在使用VC++2005环境下生成的程序，放置到未安装VC环境的机器下后，有时候会出现程序无法执行的错误，其提示是：应用程序配置不正确，程序无法启动，重新安装应用程序可能解决问题。 Visual C++ Libraries Visual C++ Libraries as Shared Side-by-Side Assemblies In Visual C++ 2005, the ATL, MFC, Standard C++, and CRT libraries support the new deployment model available on Windows XP, Windows Server 2003, and Windows Vista. The DLLs corresponding to all Visual C++ libraries have been grouped into several shared side-by-side assemblies and are installed into the native assembly cache, also called the WinSxS folder, 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 application 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 from the application-local folder will result in an error message indicating that this is an unsupported way of loading a Visual C++ library.
This change to the deployment model of Visual C++ libraries prevents the problem of version conflicts between DLLs that occur when you add updates or configurations to a machine, and will allow 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 corresponding manifest files.
|
http://wenku.baidu.com/link?url=lpOCsvRlBW_93VypbKoG9_IdQNvg59XNy2idhYOJ6RS9ohgSwJ_AytTCYsb8tered89-Sz3KBD6fjGU7y0UkP3zaq7EmD38lODzjQsvQZXK
