VC200應(yīng)用程序正常初始化失敗-0xc0150002

1、最近幾天被這個(gè)問題困惑了許久。不禁感嘆微軟的東東真是越做越爛了，也終于明白了時(shí)隔12年大家仍然死守VC6的原因。用VC2005編譯的程序，編譯時(shí)沒有任何錯(cuò)誤，但是運(yùn)行時(shí)就是提示應(yīng)用程序正常初始化失敗”！查找了各方面資料，做了各種嘗試，網(wǎng)上說什么的都 有：有讓安裝vc2005 sp1補(bǔ)丁的；有讓安裝vcredist_x86.exe的；有讓把CRT庫 的dll直接拷貝到程序目錄的；有讓活理注冊(cè)表的；有讓裝.NetFramework新版本 的;有讓查manifest的；結(jié)果我嘗試了半天，幾乎都是浪費(fèi)時(shí)間。上面最后一條說的還算正確，只是 作者把事情描述得太繁瑣了?，F(xiàn)在把處理的方法說一下，省得大家再走彎

2、路：1. VC2003、VC2005、VC2008及其后續(xù)版本，對(duì)底層最基本的CRT、MFC、ATL庫都進(jìn)行了重構(gòu)，為了避免不同版本的庫引起沖突，重構(gòu)后的庫文件一般放在C:windowsWinSxS文件夾中，并用特定的文件夾文件名稱進(jìn)行標(biāo)識(shí)；2.與VC6不同,VC2003、VC2005、VC2008及其后續(xù)版本，引入了manifest活單的概念，即應(yīng)用程序編譯后會(huì)同時(shí)生成對(duì)應(yīng)的.manifest文件,并將該.manifest文件作為資源編譯到dll或者exe中去。.manifest文件實(shí)際上是一個(gè)XML格式 的文本文件，里面記錄了dll或exe中要引用的CRT、MFC、ATL庫的版本和名 稱。

3、VC6編譯的應(yīng)用程序?qū)RT、MFC、ATL的dll都是直接調(diào)用，而VC2003、VC2005、VC2008編譯的程序都是先查詢編譯到資源中的manifest中的記錄，然 后按照記錄提供的版本和名稱去搜尋對(duì)應(yīng)的CRT、MFC、ATL庫以及隨庫發(fā)布的.manifest文件，搜尋的路徑包括當(dāng)前目錄、C:windowsWinSxS等等，如果沒有找到對(duì)應(yīng)的庫文件，則提示應(yīng)用程序正常初始化失敗”；3.因此解決這個(gè)問題的辦法就是：（a）用文本編輯器打開exe或dll對(duì)應(yīng)的.manifest文件,查看它引用的CRT、MFC、ATL庫的版本；或者，用UltraEdit直接打開exe或者dll,從資源區(qū)中找到編

4、譯進(jìn)去的.manifest信息,找到它引用的CRT、MFC、ATL庫的版本；或者，運(yùn)行程序，當(dāng)程序彈出 應(yīng)用程序正常初始 化失敗”對(duì)話框時(shí)，在桌面上右鍵點(diǎn)擊 我的電腦”-管理”-事件查看器”-系 統(tǒng)”，雙擊查看其中的記錄，可以看到出錯(cuò)的原因是因?yàn)槿鄙倭四衬嘲姹镜腃RT、MFC、ATL庫，記錄下這個(gè)版本信息；（b）記錄到的庫的版本信息一般類似于“Microsoft.VC90.DebugCRT,之后到C:windowsWinSxS或者VC200X的安裝 文件夾中搜索包含這個(gè)字符申的文件夾和文件，將搜索到的dll和.manifest文件 都拷貝到應(yīng)用程序所在的文件夾中，其中,.manifest文件必

5、須重命名為“ Microsoft.VC90.DebugCRT.manifest這里以（Microsoft.VC90.DebugCRT為例），這樣應(yīng)用程序就可以正常運(yùn)行了；（c）注意：庫的.manifest文件和dll要一同拷貝到應(yīng)用程序根目錄去，因?yàn)閼?yīng)用程序會(huì)將編譯到內(nèi)部的manifest信息與外部的.manifest文件進(jìn)行對(duì)比，之后才會(huì)對(duì)庫的dll進(jìn)行調(diào)用。如果只拷貝庫的dll文 件是沒有用的；4.如果本機(jī)編譯和運(yùn)行程序都o(jì)k,但是將編譯好的程序拿到其它機(jī)器上確無法運(yùn)行， 則多半也是這個(gè)原因。 另外， 如果提示”應(yīng)用程序配置不正確”，大多也是 因?yàn)樯厦嫠f的CRT、MFC、ATL庫版本與應(yīng)

6、用程序不匹配導(dǎo)致的，可以如法 炮制進(jìn)行解決；在網(wǎng)上找出了這些方法:方法一：在類似C:Program FilesMicrosoft Visual Studio 8VCredistDebug_NonRedistx86Microsoft.VC80.DebugCRT下找到了下列文件：msvcm80d.dllmsvcp80d.dllmsvcr80d.dllMicrosoft.VC80.DebugCRT .manifest把這幾個(gè)文件拷貝到目標(biāo)機(jī)器上，與運(yùn)行程序同一文件夾或放到system32下，就可以正確運(yùn)行了。其他release版、MFC程序什么的都是拷redist下相應(yīng)文件夾下的文件就可以了，文件夾

7、后都有標(biāo)識(shí)！方法二：修改編譯選項(xiàng)，將/MD或/MDd改為/MT或/MTd，這樣就實(shí)現(xiàn)了對(duì)VC運(yùn)行時(shí)庫的靜態(tài)鏈 接，在運(yùn)行時(shí)就不再需要VC的dll了。方法三：工程屬性配置屬性常規(guī)一MFC的使用，選擇 在靜態(tài)庫中使用mfc”這樣生成的exe文件應(yīng)該就可以在其他機(jī)器上跑了。方法四：你的vc8安裝盤上找到再分發(fā)包vcredist_xxx.exe和你的程序捆綁安裝在大部分機(jī)上都可以運(yùn)行了，唯獨(dú)在我的測試機(jī)上還是報(bào)應(yīng)用程序配置錯(cuò)誤。剛開始懷疑是還缺少dll，在能跑的機(jī)上把windows/system32目錄下所有的msvc*.dll都復(fù)制到這臺(tái)機(jī)的運(yùn)行目錄，還是不行！極度郁悶x！后來實(shí)在沒轍了，就在VC環(huán)

8、境中打開了EXE來查看它內(nèi)嵌的manifest資源，無奈了看了一會(huì)，帶著心中對(duì)manifest的咒罵，突然發(fā)現(xiàn)這個(gè)manifest帶了兩個(gè)版本CRT的依賴：再打開Microsoft.VC80.CRT .manifest一看，是這樣：就是說，我們EXE的Manifest里多了一個(gè)版本依賴，那就把后面那個(gè)依賴刪除試試。 于是就把工程設(shè)置的生成manifest的選項(xiàng)去掉，手工改了一下manifest放到程序目錄下，發(fā)現(xiàn)果然可以運(yùn)行了！還有個(gè)問題沒有明白， 就是VC為什么在自傻腮anifest里帶了兩個(gè)依賴呢，上網(wǎng)再查了一下，發(fā)現(xiàn)在msdnonline上說8.0.50608.0這個(gè)版本是在XP下用的，

9、8.0.50727.762這個(gè)版本是在Vista下用的(http:/ defined _USE_RTM_VERSION#define _CRT_ASSEMBLY_VERSION8.0.50608.0 ”#else#define _C RT_ASSEMBLY_VERSIOl8.0.50727.762 ”#endif顯然默認(rèn)的版本是“8.0.50727.762”，除非定義了_USE_RTM_VERSION!那為什么我們的工程會(huì)生成兩個(gè)版本的依賴呢，明明這個(gè)地方是二選一的。一開始懷疑是工程設(shè)置引起的，我就把我們的工程拷出來，把里面的文件刪掉，再復(fù)制一些向?qū)傻奈募M(jìn)來，編譯一看，manifest里

10、只有一個(gè)8.0.50727.762,說明工程設(shè)置沒有問題！最后我懷疑是工程鏈接的那些庫的問題，因?yàn)橛行焓怯肰C6或者VC2003編譯的，但是有些庫沒有代碼，編不了，沒法嘗試了。assemblyIdentity type=win32 name=Microsoft.VC80.DebugCRTVC+解決”應(yīng)用程序配置不正確，程序無法啟動(dòng)2009-03-03 10:05在使用VC+200弭境下生成的程序，放置到未安裝VC環(huán)境的機(jī)器下后，有時(shí)候 會(huì)出現(xiàn)程序無法執(zhí)行的錯(cuò)誤，其提示是：應(yīng)用程序配置不正確，程序無法啟動(dòng)， 重新安裝應(yīng)用程序可能解決I可題。實(shí)際上，重裝是解決不了問題的，解決的一種方法是查看*e

11、ermediate.manifest文件，比如文件的內(nèi)容是：version=8.0.50727.762 processorArchitecture=x86 publicKeyToken=1fc8b3b9a1e18e3b /需要注意這個(gè)文件中的3個(gè)關(guān)鍵詞：Microsoft.VC80.CRT , Microsoft.VC80.MFC和Microsoft.VC80.DebugCRT。尋找到.Program FilesMicrosoft Visual Studio 8VCredist文件夾下面，找到這些名稱的子文件火，拷貝它們下面所有的文件到希望發(fā)布的EX或件下面，一起打包。這些文件也就

12、是mfc80.dll , msvcr80.dll , msvcp80.dll和Microsoft.VC80.CRT.manifest等。此錯(cuò)誤發(fā)生的原因是在目標(biāo)機(jī)器上需要這些 文件的支持。Visual C+ LibrariesVisual C+ Libraries as Shared Side-by-Side AssembliesIn Visual C+ 2005, the ATL, MFC,Standard C+, and CRTlibraries support the new deploymentmodel available on Windows XP, Windows Server

13、2003, and WindowsVista. The DLLs correspondingto all Visual C+libraries have been grouped into several shared side-by-side assemblies andare installed into the native assembly cache, also called the WinSxSfolder, under the operatingsystem root directory. Similarly, while building a C+ application us

14、ing Visual C+ 2005, bydefault the compiler and the linker generate a manifest file that describes runtime dependenciesof this application on Visual C+ libraries.Visual C+ libraries cannot be used by a C/C+ application without a manifest binding theapplication to these libraries. If a C/C+ applicatio

15、n that depends on a Visual C+librarydoes not use a manifest, then an attempt to load the Visual C+ library as a dependent DLLfrom the application-local folder will result in an error messageindicating that this is anunsupported way of loading a Visual C+ library.-Note:On versions of Windows that do

16、not support deployment of shared side-by-side assemblies, suchas Windows98 and Windows 2000 Server, the Visual C+ libraries are installed in the System32folder and WinSxS folder under the operating system root directory. This setup enables runningVisual C+ applications on these operating system vers

17、ions because they do not supportmanifest-based binding of applications toMicrosoft.VC90.DebugMFCdependent DLLs. On these operating systems, when an application is loaded, the correspondingmanifest file is ignored and the operating systems searches for dependent DLLs using pathsset in the current run

18、ning environment. However, on upgrading the operating system to a versionthat support manifest-based binding, such as WindowsXP, 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

19、+libraries prevents the problem of versionconflicts between DLLs that occur whenyou add updates or configurations to a machine, and willallow support of side-by-side installation of two different Visual C+ toolsets. It will alsoallow you to produce reliable, self-describing applications and componen

20、ts that will notconflict with existing components. For more information on the advantages of new deploymentmodel, please see Concepts of Isolated Applications and Side-by-side Assemblies . To learnabout how this may impact deployment of existing native C+ applications, please refer toRedistributing Visual C+ Files .Visual C+ libraries have been packaged in several shared side-by-side assemblies withcorresponding manifest files.Assembly NameMicrosoft.VC90.ATLMicrosoft.VC90.CRTMicrosoft.VC90.DebugC