1.如何在Release狀態下進行調試
Project->Setting=>ProjectSetting對話框，選擇Release狀態。C/C++標籤中的Category選General，Optimizations選Disable(Debug)，Debut info選Program Database。在Link標籤中選Generatedebu複選框。
注：只是一個介乎Debug和Release的中間狀態，所有的ASSERT、VERIFY都不起作用，函數調用方式已經是真正的調用，而不查表，但是這種狀態下QuickWatch、調用隊列跟蹤功能仍然有效，和Debug版一樣。
（因爲Release和Debug的成員變量初始值並不相同。如BOOL類型兩個版本的初始值分別爲FALSE和TRUE這個時候，兩個版本的運行結果就會不一樣，這也是很多人會碰到Debug版本能夠正確運行，而Release版本不能正確運行的原因）
×××××××××××××××××××××××××××××××××××××××××××
調試Release版本應用程序
如果在您的開發過程中遇到了常見的錯誤，或許您的Release版本不能正常運行而Debug版本運行無誤，那麼我推薦您閱讀本文：因爲並非如您想象的那樣，Release版本可以保證您的應用程序可以象Debug版本一樣運行。
如果您在開發階段完成之後或者在開發進行一段時間之內從來沒有進行過Release版本測試，然而當您測試的時候卻發現問題，那麼請看我們的調試規則1:
規則1: 經常性對開發軟件進行Debug和Release版本的常規測試.
測試Release版本的時間間隔越長，排除問題的難度越大，至少對Release版本進行每週1次的測試，可以使您在緊湊的開發週期內節省潛在的排故時間.
不要隨意刪除Release版本需要的代碼
這點看起來似乎再明顯不過，但卻是開發人員無意中經常犯的錯誤，原因在於編譯器編譯Release版本時候會主動排除在代碼中存在的宏，例如ASSERT和TRACE在Release版本會自動排除，這樣導致的問題是您在這些宏當中運行的代碼也被隨之刪除，這是非常危險的事情J,例如：
ASSERT(m_ImageList.Create(MAKEINTRESOURCE(IDB_IMAGES), 16, 1, RGB(255,255,255)));
這樣的代碼在Debug模式不會出錯，圖像列表也自動創建了，然而在Release版本呢？後繼使用m_ImageList對象只會造成程序的Crash!，因此ASSERT宏中儘量使用邏輯運算符作爲驗證。
規則 2: 不要將代碼放置在僅在某種編譯選項中執行的地方，對於使用_DEBUG等編譯選項宏內部的代碼必須不影響整個程序的使用.
規則 3: 不要使用規則2作爲評判標準來刪除ASSERT宏，ASSERT宏是個有用的工具，但容易使用錯誤.
使Debug編譯模式接近Release模式
如果您的Release版本存在的問題是由代碼被編譯器自動排除造成的，那麼通過這個方法您的問題可能會重現.
一些問題的產生可能是由於不同編譯選項之間預定義符號造成的，因此您可以更改編譯模式下的預定義符號，從而使您的Debug模式接近Release模式，觀察錯誤是否產生，更改編譯預定義符號方法如下:
Alt-F7打開項目設置，在C++/C 頁面，選擇"General"類別，更改"_DEBUG"符號爲"NDEBUG".
在C++/C 頁面, 選擇"Preprocessor"類別，添加預定義符號"_DEBUG"到"Undefined Symbols"欄.
使用"Rebuild All"重新編譯
如果通過上面設置，您在Release編譯模式下面的問題在Debug模式下重現，那麼請您依據以下步驟對您的代碼進行修改:
查找ASSERT排除其中的所有重要執行語句，或者將ASSERT修改爲VERIFY.
檢查"#ifdef _DEBUG" 內所有代碼，排除Release模式使用的代碼.
查找TRACE 排除其中的所有重要執行語句. TRACE和ASSERT一樣，僅在Debug模式下編譯.
如果通過上面修改更正了您在Debug模式下的問題，那麼您可以重新編譯Release模式，非常有可能您可以解決先前存在的問題！.
錯誤的假定造成編譯模式錯誤
您是否經常性的假定您的變量或者對象被初試化成某個指定的值(可能0)？您是否假定你所有關聯到的資源在應用程序中都存在？這些也是Debug和Release模式下不同問題產生的原因.
規則 4: 除非您在代碼中對變量進行初始化，否則不能作出如上假定. 包括全局變量，自動變量，申請對象和new對象.
這種情況還常常發生在內存順序的問題，記得原來使用結構體的時候爲了使用方便，比較兩個結構體對象使用memcmp，在Debug版本工作正常，而Release版本計算出錯誤的解，看來的確不能進行錯誤的假定！
規則 5: 確保刪除資源的所有引用都被刪除，例如resource.h中的定義.
軟件開發中，不同編譯版本對變量和內存的初始化是不同的. 如果您假定變量初始化爲0,那麼在Win9x系統的Release模式下，會出現異常現象。因此對所有變量，內存顯式清0是較爲安全的做法.
如果您引用了已經被刪除的資源，您的Debug版本可以正常工作，但是Release版本可能會crash.
您是否相信編譯器?
編譯器警告級別和編譯噪音有着相當大的關係.
通過提高編譯器警告級別可增加程序隱藏問題暴露的機會.通常設置警告級別在"Level 3"或者 "Level 4".編譯並解決所有警告，這是發佈Release版本應用程序的一個很好的建議.這能暴露會使您的應用程序出現問題的很多初始化問題和其它潛在的錯誤.
規則 6: 開始項目之前先將編譯警告級別設置在"Level 3" 或者 "Level 4" ，登記代碼之前確保消滅所有警告！.
總結報告
編譯模式下的調試
曾經不止一次的聽到一些VC開發者說Release模式下面不能進行調試，幸運的是：通過相應設置，可以在Release模式進行調試，因此那只不過是一個以訛傳訛的荒謬說法而已.
規則 7: 當前面所有的方法都無效的時候，在Release模式下面進行調試.
Release模式可以進行調試，第一步是打開符號表:
Alt-F7打開項目設置，在C++/C 頁面，選擇"General"類，修改Debug Info setting 爲 "Program Database".
在"Link" 頁面，選擇"Generate Debug Info".
"Rebuild All"
這些設置將允許您在Release模式下保留符號表，您也可以同時考慮以下設置:
調試Release版本應用程序，您可以關閉優化選項.
如果在Release模式下面不能設置斷點，添加指令"__asm {int 3}" 可以是您的應用程序在改行停止(確定在發佈應用程序時候排除這些代碼).
在Release模式進行調試的幾個限制.
最大的問題在於您不能跟蹤到MFC函數內部，原因在於Release版本的MFC動態鏈接庫不包含調試信息和符號表.
同上，想要調試調用的dll，您必須給它們全部加上調試信息和符號表.
編譯器生成了錯誤的代碼?
或許有的時候您會發現VC++編譯器生成了’問題代碼’，然而坦率的講，人們通常抱怨的太早.您可以在Release模式下面關閉優化選項來進行測試.
如果這個操作解決了您的問題，或許您的編碼習慣存在問題. 信不信由你, 極其可能在您的編碼中存在模棱兩可的求解或者看起來似乎正確，某些條件下也是正確的情況. 舉個例子，下面的代碼在Debug模式似乎一切’正常’，而在Release模式下面卻會出錯！
#include <stdio.h>
int* func1()
{
int retval = 5;
return &retval;
}
int main(int argc, char* argv[])
{
printf("%d\n", *func1());
return 0;
}
我相信大多數程序員尤其是初學者容易遇到此類情況的.
規則 8: 如果關閉Release模式的優化選項可以使您的應用程序運行正常，而打開優化選項則出現問題的化，原因多半在於您的不良編碼習慣造成的. 這意味着必須仔細檢查您的代碼，清理出那些錯誤的假設，懸空指針等等. 等同的這告訴您，在Debug模式和關閉優化選項的Release模式下您的應用程序工作正常全是因爲系統隱含的運氣，您必須着手更正存在隱患的代碼，否則在日後可能會造成巨大的損失.
規則 9: 如果您已經徹底檢查了您的代碼，並且沒有發現問題，那麼您最好逐個打開優化選項將產生錯誤的原因限制在某個範圍之內.
BTW- 以上問題代碼由C++編譯器自動檢出. 如果您已經遵循 規則 6 您或許在前面環節中已經解決了這些問題.
憑我的開發經驗，編譯器極少會產生錯誤的代碼（當然要注意接口程序邊界對齊的問題）.通常在使用模板類時候VC6編譯器或許會產生斷言ASSERT錯誤，這種情況您只需更新補丁即可解決.
最後的思考
在日常編碼中只需稍微增加一點嚴格的檢測，便能有效的避免新的Debug -v- Release模式問題的產生，以下是我的一些經驗.
1. 取出(check out)需要修改的代碼.
2. 修改代碼，排除所有警告，編譯Debug和Release版本.
3. 詳細測試新代碼，即單步調試新代碼段之後進入工作代碼，確保代碼無誤.
4. 更正所有問題.
5. 確認無誤之後將新代碼登記入庫(check in).
6. 對登記入庫的代碼進行全新的編譯，確保新登記代碼與其它代碼融合.
7. 重新詳細測試代碼.
8. 更正新問題(或許可以發現登記入庫代碼存在的問題)
嚴格按照以上步驟，您在設計開發過程中即可解決大量問題，避免在最後發佈應用程序時候產生新的難以定位的問題.
後記
本文是在我的開發歷程中遇到Release版本應用程序發佈，產生錯誤的時候苦苦求索得到的一些經驗，原文來自於codeproject，經過本人潤色，改寫成爲適合國內開發者的文章，希望能對大家有用，謝謝！
×××××××××××××××××××××××××××××××××××××××××××
2. Release和Debug有什麼不同
Release版稱爲發行版，Debug版稱爲調試版。
Debug中可以單步執行、跟蹤等功能，但生成的可執行文件比較大，代碼運行速度較慢。Release版運行速度較快，可執行文件較小，但在其編譯條件下無法執行調試功能。
Release的exe文件鏈接的是標準的MFC DLL(Use MFC in a shared or static dll)。這些DLL在安裝Windows的時候，已經配置，所以這些程序能夠在沒有安裝Visual C++ 6.0的機器上運行。而Debug版本的exe鏈接了調試版本的MFC DLL文件，在沒有安裝Visual C++6.0的機器上不能運行，因爲缺相應的DLL，除非選擇use static dll when link。
3. ASSERT和VERIFY有什麼區別
ASSERT裏面的內容在Release版本中不編譯，VERIFY裏面的內容仍然翻譯，但不再判斷真假。所以後者更安全一點。
例如ASSERT(file.Open(strFileName))。
一旦到了Release版本中，這一行就忽略了，file根本就不Open()了，而且沒有任何出錯的信息。如果用VERIFY()就不會有這個問題。
4.Workspace和Project之間是什麼樣的關係
每個Workspace可以包括幾個project，但只有一個處於Active狀態，各個project之間可以有依賴關係，在project的Setting..中可以設定，比如那個Active狀態的project可以依賴於其他的提供其函數調用的靜態庫。
5. 如何在非MFC程序中使用ClassWizard
在工程目錄下新建一個空的.RC文件，然後加入到工程中就可以了。
6.如何設置斷點
按F9在當前光標處增加一個斷點和取消一個斷點。
另外，在編輯狀態下，按Ctrl+B組合鍵，彈出斷點設置對話框。然後單擊【Condition…】按鈕彈出設置斷點條件的對話框進行設置。
7.在編輯狀態下發現成員變量或函數不能顯示提示是如何打開顯示功能
這似乎是目前這個Visual C++ 6.0版本的一個bug，可按如下步驟使其正常，如再出現，可如法炮製：
(1)關閉Project
(2)刪除“工程名.ncb”文件
(3)重新打開工程
8.如何將一個通過ClassWizard生成的類徹底刪除
首先在工作區的FileView中選中該類的.h和.cpp文件，按delete刪除，然後在文件管理器中將這兩個文件刪除，再運行ClassWizard，這時出現是否移走該類的提示，選擇remove就可以了。
9. 如何將在workspace中消失的類找出來
打開該類對應的頭文件，然後將其類名隨便改一下，這個時候工作區就會出現新的類，再將這個類改回原來的名字就可以了。
10. 如何清除所有的斷點
菜單【Edit】->【Breakpoints…】，打開“Breakpoints”對話框，單擊【Remove All】按鈕即可。快捷鍵是“Ctrl + Shift + F8”。
11. 如何再ClassWizard中選擇未列出的信息
打開“ClassWizard”對話框，然後切換到“Class Info”頁面。改變“Message filter”，如選擇“Window”，“Message”頁面就會出現Window的信息。
12. 如何檢測程序中的括號是否匹配把光標移動到需要檢測的括號前面，按快捷鍵“Ctrl + ]”。如果括號匹配正確，光標就跳到匹配的括號處，否則光標不移動，並且機箱喇叭還會發出一聲警告。
13. 如何查看一個宏(或變量、函數)的定義
把光標移動到要查看的一個宏上，就比如說最常見的DECLARE_MAP_MESSAGE上按一下F12(或右鍵菜單中的相關菜單)，如果沒有建立瀏覽文件，就會出現提示對話框，按【確定】按鈕，然後就會跳到該宏(或變量、函數)定義的地方。
14. 如何添加Lib文件到當前工程單擊菜單【Project】->【Settings…】彈出“Project Setting”對話框，切換到“Link”標籤頁，在“Object/library modules”處輸入Lib文件名稱，不同的Lib之間用空格格開。
15. 如何快速刪除項目下的Debug文件夾中臨時文件
在工作區的FileView視圖中選中對應的項目，單擊右鍵彈出菜單，選擇【Clean(selection only)】菜單即可。
16. 如何快速生成一個現有工程除了工程名外完全相同的新工程
在新建工程的“New”對話框中選擇“Custom Appwizard”項，輸入新工程的名字，單擊【OK】按鈕。出現“Custom AppWizard”項，輸入新工程的名字，單擊【OK】按鈕。出現“Custom AppWizard-Step 1 of 2”對話框，選擇“An existing Project”項，單擊【Next】按鈕。出現“Custom AppWizard-Step 2 of 2”對話框，選擇現有工程的工程文件名，最後單擊【Finish】按鈕。編譯後就生成一個與現有工程相同但可以重新取名的工程AppWizard。
現在就可以項用MFC AppWizard一樣用這個定製的嚮導。如果不想用了，可以在Visual C++ 6.0安裝目錄下Common\MSDev98\Template目錄中刪除該Wizard對應的.awx和.pdb文件。
17. 如何解決Visual C++ 6.0不正確連接的問題
情景：明明改動了一個文件，卻要把整個項目全部重新編譯鏈接一次。剛剛鏈接好，一運行，又提示重新編譯鏈接一次。
這是因爲出現了未來文件(修改時間和創建時間比系統時間晚)的緣故。可以這樣處理：找到工程文件夾下的debug目錄，將創建和修改時間都比系統時間的文件全部刪除，然後再從新“Rebuild All”一次。
18. 引起LNK2001的常見錯誤都有哪些 遇到的LNK2001錯誤主要爲：unresolved external symbol “symbol”
如果鏈接程序不能在所有的庫和目標文件內找到所引用的函數、變量或標籤，將產生此錯誤信息。一般來說，發生錯誤的原因有兩個：一是所引用的函數、變量不存在，拼寫不正確或者使用錯誤;其次可能使用了不同版本的鏈接庫。以下是可能產生LNK2001錯誤的原因：
<1>由於編碼錯誤導致的LNK2001錯誤
(1)不相匹配的程序代碼或模塊定義(.DEF)文件導致LNK2001。例如，如果在C++源文件了內聲明瞭一變量“var1”，卻試圖在另一個文件內以變量“var1”訪問改變量。
(2)如果使用的內聯函數是在.cpp文件內定義的，而不是在頭文件內定義將導致LNK2001錯誤。
(3)調用函數時如果所用的參數類型和頭函數聲明時的類型不符將會產生LNK2001錯誤。
(4)試圖從基類的構造函數或析構函數中調用虛擬函數時將會導致LNK2001錯誤。
(5)要注意函數和變量的可公用性，只有全局變量、函數是可公用的。靜態函數和靜態變量具有相同的使用範圍限制。當試圖從文件外部方位任何沒有在該文件內聲明的靜態變量時將導致編譯錯誤或LNK2001錯誤。
<2>由於編譯和聯機的設置而造成的LNK2001錯誤
(1)如果編譯時使用的是/NOD(/NODERAULTLIB)選項，程序所需要的運行庫和MFC時將得到又編譯器寫入目標文件模塊，但除非在文件中明確包含這些庫名，否則這些庫不會被鏈接進工程文件。這種情況下使用/NOD將導致LNK2001錯誤
(2)如果沒有爲wWinMainCRTStartup設定程序入口，在使用Unicode和MFC時將出現“unresolved external on _WinMain@16”的LNK2001錯誤信息。
(3)使用/MD選項編譯時，既然所有的運行庫都被保留在動態鏈接庫之內，源文件中對“func”的引用，在目標文件裏即對“__imp__func”的引用。如果試圖使用靜態庫LIBC.LIB或LIBCMT.LIB進行鏈接，將在__imp__func上發生LNK2001錯誤。如果不使用/MD選項編譯，在使用MSVCxx.LIB鏈接時也會發生LNK2001錯誤。
(4)使用/ML選項編譯時，如用LIBCMT.LIB鏈接會在_errno上發生LNK2001錯誤。
(5)當編譯調試版的應用程序時，如果採用發行版模態庫進行鏈接也會產生LNK2001錯誤;同樣，使用調試版模態庫鏈接發行版應用程序時也會產生相同的錯誤。
(6)不同版本的庫和編譯器的混合使用也能產生問題，因爲新版的庫裏可能包含早先的版本沒有的符號和說明。
(7)在不同的模塊中使用內聯和非內聯的編譯選項能夠導致LNK2001錯誤。如果創建C++庫時打開了函數內聯(/Ob1或/Ob2)，但是在描述該函數的相應頭文件裏卻關閉了函數內聯(沒有inline關鍵字)，只是將得到錯誤信息。爲避免該問題的發生，應該在相應的頭文件中用inline關鍵字標誌爲內聯函數。
(8)不正確的/SUBSYSTEM或ENTRY設置也能導致LNK2001錯誤。
19. 如何調試一個沒有源碼的exe文件調用的dll
在Visual C++ 6.0中，進入“Project Setting”對話框然後選擇Debug標籤頁。通常Visual Studio默認“executable for debug session”爲可執行文件名，但可以將他改成任何你想要的程序。甚至可以指定不同的工作目錄以及傳遞參數到你的程序。這個技術常用來調試Dlls、名字空間擴展、COM對象和其他從某些EXE以及從第三方的EXE中調用的plug-in程序。
20. Visual C++ 6.0工程中的項目文件都表示什麼
.opt：工程關於開發環境的參數文件。如工具條位置等信息。
.aps(AppStudio File)資源輔助文件，二進制格式，一般不用去管它。
.clw：ClassWizard信息文件，實際上是INI文件格式，有興趣可以研究一下。有時候ClassWizard出了問題，手工修改CLW文件可以解決。如果此文件不存在的話，每次用ClassWizard的時候回提示是否重建。
.dsp(DevelopStudio Project)：項目文件，文本格式，不過不熟悉的不要手工修改。
.dsw(DevelopStudio Workspace)：是工作區文件，其他特點和.dsp差不多。
.plg：是編譯信息文件，編譯時的error和warning信息文件(實際上是一個html文件)，一般用處不大。在單擊菜單【Tool】->【Option】彈出的對話框裏面有個選項可以控制這個文件的生成。
.hpj(Help Project)：是生成幫助文件的工程，用microsoft Help Compiler可以處理。
.mdp(Microsoft DevStudio Project)：是舊版本的項目文件，如果要打開此文件的話，會提示你是否轉換成新的.dsp格式。
.bsc：是用於瀏覽項目信息的，如果用Source Brower的話就必須有這個文件。如果不用這個功能的話，可以在Project Options裏面去掉Generate Browse Info File，這樣可以加快編譯速度。
.map是執行文件的映象信息記錄文件，除非對系統底層，這個文件一般用不着。
.pch(Pre-Compiled File)：是與編譯文件，可以加快編譯速度，但是文件非常大。
.pdb(Program Database)：記錄了程序有關的一些數據和調試信息，在調試的時候可能有用。
.exp：只有在編譯DLL的時候纔會生成，記錄了DLL文件的一些信息，一般也沒有用。
.ncb：無編譯瀏覽文件(no compile browser)。當自動完成功能出問題時可以刪除此文件。編譯工程後會自動生成。
