[zz]VC2005-應用程序正常初始化失敗-0xc0150002

　最近幾天被這個問題困惑了許久。 不由感嘆微軟的東東真是越作越爛了，也終於明白了時隔12年你們仍然死守VC6的緣由。。 

　　用VC2005編譯的程序，編譯時沒有任何錯誤，可是運行時就是提示「應用程序正常初始化失敗」！！ 查找了各方面資料，作了各類嘗試，網上說什麼的都有：有讓安裝vc2005 sp1補丁的；有讓安裝vcredist_x86.exe的; 有讓把CRT庫的dll直接拷貝到程序目錄的; 有讓清理註冊表的;有讓裝.NetFramework新版本的;有讓查manifest的;

　　結果我嘗試了半天,幾乎都是浪費時間。上面最後一條說的還算正確，只是做者把事情描述得太繁瑣了。。如今把處理的方法說一下，免得你們再走彎路：

　　1. VC200三、VC200五、VC2008及其後續版本，對底層最基本的CRT、MFC、ATL庫都進行了重構，爲了不不一樣版本的庫引發衝突，重構後的庫文件通常放在 C:\\windows\WinSxS 文件夾中,並用特定的文件夾\文件名稱進行標識；

　　2. 與VC6不一樣, VC200三、VC200五、VC2008及其後續版本，引入了manifest清單的概念，即應用程序編譯後會同時生成對應的.manifest文件,並將該.manifest文件做爲資源編譯到dll或者exe中去。.manifest文件其實是一個XML格式的文本文件，裏面記錄了dll或exe中要引用的CRT、MFC、ATL庫的版本和名稱。VC6編譯的應用程序對CRT、MFC、ATL的dll都是直接調用，而VC200三、VC200五、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環境的機器下後，有時候會出現程序沒法執行的錯誤，其提示是：應用程序配置不正確，程序沒法啓動，從新安裝應用程序可能解決問題。 實際上，重裝是解決不了問題的，解決的一種方法是查看*exe.intermediate.manifest文件，好比文件的內容是： <?xml version='1.0' encoding='UTF-8' standalone='yes'?> <assembly xmlns='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' />     </dependentAssembly> </dependency> <dependency>     <dependentAssembly>       <assemblyIdentity type='win32' name='Microsoft.VC80.MFC' version='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />     </dependentAssembly> </dependency> <dependency>     <dependentAssembly>       <assemblyIdentity type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />     </dependentAssembly> </dependency> </assembly>        須要注意這個文件中的3個關鍵詞：Microsoft.VC80.CRT，Microsoft.VC80.MFC和Microsoft.VC80.DebugCRT。尋找到...."Program Files"Microsoft Visual Studio 8"VC"redist文件夾下面，找到這些名稱的子文件夾，拷貝它們下面全部的文件到但願發佈的EXE文件下面，一塊兒打包。這些文件也就是mfc80.dll，msvcr80.dll，msvcp80.dll和Microsoft.VC80.CRT.manifest等。此錯誤發生的緣由是在目標機器上須要這些文件的支持。 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. Note: On versions of Windows that do not support deployment of shared side-by-side assemblies, such as Windows 98 and Windows 2000 Server, the Visual C++ libraries are 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 to dependent DLLs. On these operating systems, when an 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 Windows XP, Windows Server 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 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. Assembly Name DLLs included in the assembly Visual C++ Library Microsoft.VC90.ATL atl90.dll Active Template Library Microsoft.VC90.CRT msvcr90.dll msvcp90.dll msvcm90.dll C Runtime Library, release DLLs Microsoft.VC90.DebugCRT msvcr90d.dll msvcp90d.dll msvcm90d.dll C Runtime Library, debug DLLs Microsoft.VC90.MFC mfc90.dll mfcm90.dll mfc90u.dll mfcm90u.dll Microsoft Foundation Classes, release DLLs Microsoft.VC90.DebugMFC mfc90d.dll mfcm90d.dll mfc90ud.dll mfcm90ud.dll Microsoft Foundation Classes, debug DLLs Microsoft.VC90.MFCLOC mfc90chs.dll mfc90deu.dll mfc90esp.dll mfc90ita.dll mfc90kor.dll mfc90cht.dll mfc90enu.dll mfc90fra.dll mfc90jpn.dll Microsoft Foundation Classes, localized resources Microsoft.VC90.OpenMP vcomp.dll OpenMP Library, release DLLs Microsoft.VC90.DebugOpenMP Vcompd.dll OpenMP Library, debug DLLs

 http://wenku.baidu.com/link?url=lpOCsvRlBW_93VypbKoG9_IdQNvg59XNy2idhYOJ6RS9ohgSwJ_AytTCYsb8tered89-Sz3KBD6fjGU7y0UkP3zaq7EmD38lODzjQsvQZXK