VC9編譯的程序在沒有裝過VC9（確切的說是.Net Framework3.5）的機器上運行時，如果提示“由於應用程序配置不正確，應用程序未能啟動。重新安裝應用程序可能會糾正這個問題。”這個錯誤，那 么就說明該程序動態鏈接了VC9的運行時庫，（如果還用到了MFC，那么可能動態鏈接了VC9的MFC庫，同理還有ATL庫），以及缺少對應的 manifest文件，程序在目標機器上沒有找到這些庫和配置文件，因此導致了這個錯誤。出現這種情況的VC9編譯器可能存在3個版本，接下來分別闡明：
1、沒有打過任何補丁的VS2008
該版本對應的CRT/MFC/ATL庫的版本號為9.0.21022.8，這個版本號在后面 會用到。這個版本的程序部署比較簡單，直接把VC安裝目錄下的redist目錄（C:\Program Files\Microsoft Visual Studio 9.0\VC\redist）中需要的庫以及對應的manifest文件拷貝到執行程序同目錄下，這樣程序到任何機器上都能夠正常運行了。
2、打過SP1補丁的VS2008
打過該補丁后，系統中存在着兩個版本的CRT/MFC/ATL庫，版本號分別為 9.0.21022.8和9.0.30729.1，這導致了manifest文件中記錄的版本號和實際庫的版本號不一致（程序要求它們的版本號一致才能運 行）。這個版本的程序部署需要兩個步驟，首先要使manifest文件中依賴項的版本號與實際庫的版本號一致，均為9.0.30729.1，方法是在工程 設置中增加一個宏定義_BIND_TO_CURRENT_VCLIBS_VERSION，該宏定義於C:\Program Files\Microsoft Visual Studio 9.0\VC\include\crtassem.h文件中，然后重新編譯程序。接下來還是將VC安裝目錄下的redist目錄（C:\Program Files\Microsoft Visual Studio 9.0\VC\redist）中需要的庫以及對應的manifest文件拷貝到執行程序同目錄下，然后修改manifest文件中依賴項的版本號為 9.0.21022.8，這樣使得程序誤以為該目錄下庫的版本號為9.0.21022.8（實際上是9.0.30729.1版本），這樣程序到任何機器上 都能夠正常運行了。
3、打過SP1補丁與SP1 ATL 安全更新 (KB973675)的VS2008
這是最新的更新。在SP1補丁之后，微軟又於近日發布了一個用於智能設備的 Microsoft Visual Studio 2008 Service Pack 1 ATL 安全更新 (KB973675)， 該補丁又將CRT/MFC/ATL庫的版本號升級，為9.0.30729.4148，這次升級比較好，manifest文件與庫的版本號一致了，不像 SP1一樣升級的不徹底。這樣只需要在工程設置中增加一個宏定義_BIND_TO_CURRENT_VCLIBS_VERSION，接下來重新編譯程序， 然后直接把VC安裝目錄下的redist目錄中需要的庫以及對應的manifest文件拷貝到執行程序同目錄下，這樣程序到任何機器上都能夠正常運行了。
順便提一下，如果不想在發布程序時帶上這些庫和manifest文件（如果沒有必要的話）， 那么可以采用靜態編譯CRT和MFC，然后把manifest文件添加到資源中，這樣編譯出的程序只要一個exe就可以在任何機器上直接運行了。
參考文章：
1、“應用程序配置不正確，程序無法啟動”的解決方法資料收集：
有的時候，你在Visual C++上面經過好幾個月的辛勤努力，終於將程序編寫完成並且測試完畢，然而當你試圖在客戶的發布機上運行剛寫好的程序時，有可能會碰到類似下面的錯誤，操 作系統告訴你“由於應用程序配置不正確，應用程序未能啟動。重新安裝應用程序可能會糾正這個問題”.
一般情況下，這個問題都是由於程序不能找到所需要的C運行庫（CRT）而引起的。
在Windows XP SP2以后，Windows引入了Side-by-Side執行的概念，這個概念本來是.NET提出來的，但是Windows后來將這個概念集成到操作系 統層面上來了。大家都應該知道Dll Hell的問題，為了解決Dll Hell的問題，Side-By-Side提出不同版本的dll文件可以同時 存在於同一個系統里面，而且依賴於不同版本dll的應用程序在運行的時候可以使用到它當初被編譯生成的dll。前面的話，有點繞，舉個例子：
1. 假定你編寫了一個C++程序A，是使用MFC 8.0（這個版本是隨着Visual Studio 2005）發布的。
2. 之后你的機器升級了Visual Studio的版本，從2005升級到2008，2008的MFC庫是9.0版本的，這個時候你的操作系統里面安裝了兩個版本的MFC，分別是8.0和 9.0。
3. 你在Visual Studio 2008編寫了另外一個C++程序B，B依賴與MFC 9.0。
4. 如果你運行程序A的話，操作系統會將MFC 8.0加載到A的進程里面。
5. 如果你這時同時運行程序B，操作系統會將MFC 9.0加載到B的進程里面。這就是Side-by-side的執行概念。
操作系統之所以能夠這樣做，是因為它在加載程序A和B之前，除了查看PE格式里面A和B所依 賴的Dll信息，都會查看A和B的manifest文件。Manifest文件保存了Windows可執行文件（包括exe和dll文件）要運行起來的環 境設置信息，文件名一般是可執行文件的文件全名加上.manifest。例如notepad.exe的manifest文件就應該是 notepad.exe.manifest。例外有的程序將manifest文件直接嵌入到可執行文件的資源里面了，這也就是為什么有的時候你看不到程序 的manifest文件的原因。通常來說，一個manifest文件的內容如下（test.exe.manifest文件）：
<?xml version='1.0' encoding='UTF-8' standalone='yes'?> <assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> <security> <requestedPrivileges> <requestedExecutionLevel level='asInvoker' uiAccess='false' /> </requestedPrivileges> </security> </trustInfo> <dependency> <dependentAssembly> <assemblyIdentity type='win32' name='Microsoft.VC90.DebugCRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /> </dependentAssembly> </dependency> </assembly> |
上面的例子里面，就說明這個程序依賴於CRT 9.0，而且是調試版的，CPU架構是32位的CPU。對於將manifest文件嵌入到資源文件的程序我們也有辦法看到manifest的信息。
1. 一種是使用mt.exe（Visual Studio自帶的manifest處理程序）：
mt -inputresource:test.exe;#1 /out:test.manifest
2. 另外一種是使用dumpbin程序將整個exe的內容打印到一個文件，然后用文本編輯器打開，搜索Assem字符串樣式就能找到manifest信息：
解決方案
知道了程序依賴於具體哪一個dll以后，你可以將所依賴的dll拷貝到程序的安裝文件夾里 面，以CRT庫綁定失敗為例，介紹解決步驟：
1.從上例中我們知道程序依賴的Microsoft.VC90.DebugCRT庫，版本號 是9.0.21022.8，需要32位機器版本的CRT。這個依賴項一般是因為你的程序是調試版，所以Visual Studio在編譯的時候，將調試版的CRT加入程序的依賴項。
2.從Visual Studio的安裝文件夾里面將D:"Program Files"Microsoft Visual Studio 9.0"VC"redist"Debug_NonRedist"x86中的Microsoft.VC90.DebugCRT整個文件夾拷貝到應用程序所在 的文件夾里面，注意：
a)如果你的程序依賴的是32位的CRT，則要拷貝x86文件夾里面的 Microsoft.VC90.DebugCRT文件夾，如果是先x64程序，則要拷貝x64文件夾里面。
b)你需要確定Microsoft.VC90.DebugCRT文件夾里面的 Microsoft.VC90.DebugCRT.manifest文件里面保存的版本信息而你程序依賴的版本信息匹 配，Microsoft.VC90.DebugCRT.manifest里面的版本信息大版本號一定要一致，小版本號一定要等於或者大於你程序依賴的 CRT的小版本號。比如上例中，我們的程序是依賴於CRT 9.0.21022.8，而我們的Microsoft.VC90.DebugCRT.manifest的版本是9.0.30729.1，這樣是可以的；而 8.0.30729.1就會有問題。如果大版本號一樣，小版本號不一致的話，一個比較簡單的方案就是修改程序的manifest文件，使其互相匹配就可以 了。
3.如果你的程序不是依賴調試版本的CRT，而是release版本的CRT，直接去微軟的 官方網站下載一個crt redist包安裝上就可以了。
附:解決方案參考：
方案一:
方法一：
在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和你的程序捆綁安裝
我逐一測試下來,直到第三個方法才成功.第二個方法不知道在哪里修改編譯選項所以放棄了,第四個方法不喜歡,這跟直接安裝.net framework 2.0 有什么區別嗎?還不如直接安裝.net framework 2.0 呢.
方案二:
最早出現這個錯誤我和許多人認為的一樣
認為是缺乏DLL庫文件導致.但是在測試機復制了DLL甚至安裝了.net framework 2.0以后
都無法解決問題,最后確認不是由缺乏DLL所致
因為程序是純win32的應用程,非托管代碼,所以也無需.net framework
Visual C++2003/2005默認的MFC程序是使用動態MFC庫(Use MFC in a Shared DLL)來鏈接的
而動態MFC庫使用 的是Multi-threaded DLL (/MD)
由於XP對於PE文件格式監測更加嚴格.
就會導致部分使用多線程DLL的可執 行文件在調用的時候出錯
修改項目屬性的編譯開關
Project->Property->configuration Properties->C/C++->Code Generation->Runtime Library
修改成 Multi-threaded (/MT)
修改了Runtime類型以后
需要將MFC的編譯類型也改成靜態庫
Project->Property->configuration Properties->General->Use of MFC
修改成Use MFC in a Static Library
一部分情況下在這步就能解決問題
另外一部分情況會遇見如下情況
編譯器報錯
CODE:
nafxcw.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator new[](unsigned int)" (??_U@YAPAXI@Z) already defined in libcpmt.lib(newaop.obj)
[Copy to clipboard]
產生這個問題的原因是庫依 賴關系
在Project->Property->configuration Properties->Linker->Command Line
加入編譯開關/verbose:lib可以顯示詳細的庫鏈接順 序
CODE:
------ Build started: Project: PerfMonDemo, Configuration: Release Win32 ------
Linking...
Searching libraries
Searching d:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\lib\pdh.lib:
Searching d:\Program Files\Microsoft Visual Studio 8\VC\lib\DelayImp.lib:
.................
Searching d:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib\nafxcw.lib:
Finished searching libraries
.\Release/PerfMonDemo.exe : fatal error LNK1169: one or more multiply defined symbols found
Build log was saved at "file://d:\Dev\Performance Monitor\Release\BuildLog.htm"
PerfMonDemo - 2 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
[Copy to clipboard]
我 們發現在libcpmt.lib聲明過的operator new在nafxcw.lib中再次定義
解決方法如下
Project->Property->configuration Properties->Linker->Input->Additional Dependencies
加入
nafxcw.lib
libcpmt.lib
Project->Property->configuration Properties->Linker->Input->Ignore Specific Library
加入
nafxcw.lib
libcpmt.lib
這樣鏈接程序就不會先按照默認順序來連接這兩個庫文件
而是在最后在加入對他們的引用.這樣就避免了 這個問題
下面是一張可能發生沖突的列表
若要使用此運行時庫 請忽略這些庫
單線程 (libc.lib) libcmt.lib、msvcrt.lib、libcd.lib、libcmtd.lib、msvcrtd.lib
多線程 (libcmt.lib) libc.lib、msvcrt.lib、libcd.lib、libcmtd.lib、msvcrtd.lib
使 用 DLL 的多線程 (msvcrt.lib) libc.lib、libcmt.lib、libcd.lib、libcmtd.lib、msvcrtd.lib
調試單線程 (libcd.lib) libc.lib、libcmt.lib、msvcrt.lib、libcmtd.lib、msvcrtd.lib
調 試多線程 (libcmtd.lib) libc.lib、libcmt.lib、msvcrt.lib、libcd.lib、msvcrtd.lib
使 用 DLL 的調試多線程 (msvcrtd.lib) libc.lib、libcmt.lib、msvcrt.lib、libcd.lib、libcmtd.lib
這里還有一篇
轉載於：http://blog.csdn.net/feng_enlove/article/details/5917903
vs2008發布c編寫的dll程序 初始化失敗-0xc0150002
用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庫版本與應用程序不匹配導致的，可以如法炮制進行解決；
（原文http://microblue.com.cn/it/8823.html）
把VS安裝目錄下的Microsoft Visual Studio 9.0/VC/redist/Debug_NonRedist/x86/Microsoft.VC90.DebugCRT下的
msvcm90d.dll
msvcp90d.dll
msvcr90d.dll
Microsoft.VC90.DebugCRT.manifest
這幾個文件復制到應用程序安裝后的根目錄下（注：我裝的是VS2008,如果是VS2005的話上面的90的地方全部換80），原因就是我的程序里依賴了VS里面的一些庫，所以不裝VS的機器上會找不到相應的dll。把這幾個dll發布時一起發布就好了。
但是這樣之后，出現了另一個問題，提示“應用程序正常初始化失敗”，無奈繼續求助百度GOOGLE兩位大神，一查發現自己中了大獎，號稱VS發布程序的兩大難題讓我一次全遇到了。
不斷翻啊翻，翻到http://bbs.17173.com/topics/4550/200907/21/1852512,1.html?time=1248186834這個網頁的時候，里面的第一種方法提醒了我，嘗試了下，還不行，突然想起，我用的是VS2008，他提供的是2005的下載地址，於是按照那個名字復制的2008的，下載安裝之，問題最終解決。
下載的軟件名字為Microsoft Visual C++ 2008 SP1 Redistributable Package (x86) 。
快速描述
Microsoft Visual C++ 2008 SP1 Redistributable Package (x86) 會為 Visual C++ 庫安裝必要的運行時組件，使用戶能夠在未安裝 Visual C++ 2008 SP1 的計算機上運行使用 Visual C++ SP1 開發的應用程序。
提供一個下載地址，微軟的官方下載，速度還可以：
http://www.microsoft.com/downloads/details.aspx?displaylang=zh-cn&FamilyID=a5c84275-3b97-4ab7-a40d-3802b2af5fc2
同時提供另一個對此問題講解比較透徹的網址：http://hi.baidu.com/kidcdf/blog/item/aad99901207fe1d2267fb5da.html
OK,這樣就可以把使用VS2008編寫的程序運行在未裝VS的機器上了。
最后再轉一篇
轉載於：http://hi.baidu.com/kidcdf/blog/item/aad99901207fe1d2267fb5da.html
再談VC2005 發布程序的兩大問題:"應用程序正常初始化失敗","應用程序配置不正確",攻略全
2008年01月31日 星期四 23:29
自己電腦上能用,到了其他電腦上就不能用了,是不是很頭痛,除了必要的DLL文件,還有些什么是必須一起打包發行的呢?
1."應用程序配置不正確"
參考:http://blog.csdn.net/Blue_Dream_/archive/2007/10/05/1811975.aspx
1.如果你的項目屬性是 MD 或 MDd,那就要把以下文件放入你的EXE目錄一起發布
開始-運行- X:\Program Files\Microsoft Visual Studio 8\VC\redist\Debug_NonRedist\x86\Microsoft.VC80.DebugCRT
2.如果你想靜態編譯進EXE,也就是 MT/MTd,那就參看這里:建議動態鏈接,這種不同開關的LIB也能一起工作了.
參考:http://blog.csdn.net/primer_programer/archive/2008/01/09/2031412.aspx
C Runtime Library：
|
開關
|
對應的庫
|
版本
|
|
/MD
|
MSVCRT.LIB
|
多線程DLL的Release版本
|
|
/MDd
|
MSVCRTD.LIB
|
多線程DLL的Debug版本
|
|
/MT
|
LIBCMT.LIB
|
多線程靜態鏈接的Release版本
|
|
/MTd
|
LIBCMTD.LIB
|
多線程靜態鏈接的Debug版本
|
|
/clr
|
MSVCMRT.LIB
|
托管代碼和非托管代碼混合
|
|
/clr:pure
|
MSVCURT.LIB
|
純托管代碼
|
C++ Standard Library：
|
開關
|
對應的庫
|
版本
|
|
/MD
|
MSVCPRT.LIB
|
多線程DLL的Release版本
|
|
/MDd
|
MSVCPRTD.LIB
|
多線程DLL的Debug版本
|
|
/MT
|
LIBCPMT.LIB
|
多線程靜態鏈接的Release版本
|
|
/MTd
|
LIBCPMTD.LIB
|
多線程靜態鏈接的Debug版本
|
在項目屬性-鏈接-輸入 中,輸入對應的庫,記住程序里還要還引用其他LIB,其他LIB也必須是相同的開關,比如都是 /MTD
2.應用程序正常初始化失敗:
1.今天這兩種情況都被我碰到了,這個比較好解決,在Microsoft Visual Studio 8文件夾內搜索
vcredist_x86.exe VC可再發行包,到目標機器上安裝一下,不用重啟,即可使用.
2.項目的文件被放在了fat/fat32分區上導致的, 解決方法是把它們都移動到ntfs分區上, 或者把“項目屬性|Manifest Tool|General|Use FAT32 Work-around”設為yes。
3.如果把相應的MFCDLL全COPY過去了,還不行怎么辦呢?
(1)用ultraedit,editplus打開你的EXE文件,搜索manifest,找到使用的DLL版本號,如version="8.0.50.XXX"
(2)DEBUG模式下報此錯的話, 把你電腦上的 c:\windows\winsxs\policies\x86_policy.8.0.Microsoft.VC80.DEBUGCRT.XXXXXXXXXXX
找到對應版本號的cat,和policy這兩個文件,再找到
c:\windows\winsxs\manifest\x86_Microsoft.VC80.DebugCRT_XXXX_8.0.50727.762_XXXXX.cat和x86_Microsoft.VC80.DebugCRT_XXXXXX_8.0.50727.762_XXXXX.manifest
復制到出問題的機子上的對應目錄就OK了
3.缺少SP1補丁,
GHOST了C盤后,發覺再運行OGRE的程序就不行了,:"應用程序正常初始化失敗",調試器輸出:
LDR: LdrpWalkImportDescriptor() failed to probe d:\program\project\BumperCar\BumperCar\Debug\exe\OgreMain_d.dll for its manifest, ntstatus 0xc0150002 ,想起來了,VC2005要裝SP1才兼容OGRE1.4X,這里放出補丁.
英文補丁 431M
http://download.microsoft.com/download/6/3/c/63c69e5d-74c9-48ea-b905-30ac3831f288/VS80sp1-KB926601-X86-ENU.exe
中文補丁
http://download.microsoft.com/download/8/0/7/8071514d-9370-45c3-8af1-4ff09a70e59d/VS80sp1-KB926604-X86-CHS.exe
|
