VC++程式調試

      當程式的運作結果與程式員預想的不一樣，如當機，計算值不正确，出現記憶體通路沖突等，就需要進行調試

      因為程式調試是一項十分耗時的工作，很難估計出将要花費多長時間，是以在調試前，一定要做好充分準備，盡量避免做無用功：

1.     構造好的測試步驟，讓程式出錯有規律性或出錯的機率越大越好

2.    被調試程式及相關庫是最符合要求的版本

3.    工程臨時檔案如.ncb被删除

4.    整個工程被重新編譯

5.    應用程式的連結路經與調試路徑保持一緻

6.    單體測試全部通過

1 記憶體莫名其妙的失效

原因：記憶體指針被多處引用，被多處釋放

2 多線程條件下當機

原因：線程中由于用了SendMessage而造成死鎖，可人為加入消息循環

3 多線程條件下記憶體通路沖突

原因：記憶體被多個線程同時使用，可加入線程同步機制（用消息隊列，信号燈等）

4 記憶體通路沖突

原因：記憶體越界（如字元串拷貝，記憶體拷貝）

5 視窗消息的次序問題

原因：如視窗未初始化就開始用

1 對代碼的了解越深，對代碼出錯位置的确定越精确，必要時應畫出相關代碼的類圖和時序圖

2 從IDE調用堆棧判斷出錯位置和原因

3 從Win32 API或MFC類庫函數的傳回錯誤碼判斷出錯原因，傳回錯誤碼的含義可以從MSDN或源代碼中找到，還可以通過VC工具Error lookup找到

4 在代碼中加入帶編号的TRACE語句或MessageBox(release版)，逐漸縮小調試範圍

5 對于當機現象或偶發現象，可通過逐漸注釋掉代碼的方法确定當機的位置和原因

6 如果當機現象或偶發現象是新出現的，可以通過比較目前版本和上一版本的差異來确定位置和原因

ASSERT（ASSERT_VALID）宏僅在程式的“Debug”版本中捕捉程式錯誤。該宏在“Release”版本中不生成任何代碼。

以下的例子隻能在debug中顯示，

a) TRACE

CString csTest ＝ “test”；

TRACE（“CString is ％s/n”，csTest）；

b) ATLTRACE

c) AfxDump

AfxDump要求被dump的對象從CObject類繼承，并且實作了Dump的方法。

CTime time = CTime::GetCurrentTime();

#ifdef _DEBUG

afxDump << time << “/n”;

#endif

比如在下面的代碼中，當nRet == 0 時就認為程式出錯。但是如何定位此時i的值為幾呢。

1)    将光标定位在要調試的語句前面

2)    CTRL+B， 在Break at處選擇 行号

3)    選擇Condition

在[Enter the expression…] 輸入 nRet == 0；點選OK。運作程式，在彈出報錯對話框後點選retry，程式執行将停在斷點處。 這是可以看到循環變量的數值比如i此時等于9。表明I == 9的時候出的錯誤。

在CTRL+B，在[Enter the number of times…]輸入7，程式将在循環變量i = 8 時停下來。就可以進入出錯的函數進行調試了。

見：

VCDebugSample/src/DebugMain/DebugMainDlg.cpp-----

void CDebugMainDlg::OnButtonSetBkpt()

void CDebugMainDlg::OnButtonDataBkpt()

{

            // TODO: Add your control notification handler code here

            char szName1[10];

            char szName2[4];

            strcpy(szName1,"shenzhen");                       //A

            CString str1;

            str1.Format("%s/n", szName1);

            TRACE(str1);

            strcpy(szName2, "vckbase");             //B

            CString str2;

            str2.Format("%s/n", szName2);

            TRACE(str2);

            str1.Format("%s/n", szName1);

            TRACE(str1);#include "stdafx.h"

 這段程式的輸出是

            sz1: shenzhe

      sz21: vckbase

      sz1: ase

szName1何時被修改呢？因為沒有明顯的修改szName1代碼。我們可以首先在A行設定普通斷點，F5運作程式，程式停在A行。然後我們再設定一個資料斷點。如下圖： 

F5繼續運作，程式停在B行，說明B處代碼修改了szName1。B處明明沒有修改szName1呀？但調試器指明是這一行，一般不會錯，是以還是靜下心來看看程式，哦，你發現了：szName2隻有4個位元組，而strcpy了7個位元組，是以覆寫了szName1。    資料斷點不隻是對變量改變有效，還可以設定變量是否等于某個值。譬如，你可以将Figure 2中紅圈處改為條件”szName2[0]==''''y''''“,那麼當szName2第一個字元為y時斷點就會啟動。    可以看出，資料斷點相對位置斷點一個很大的差別是不用明确指明在哪一行代碼設定斷點。

 1 在call stack視窗中設定斷點，選擇某個函數，按F9設定一個斷點。這樣可以從深層次的函數調用中迅速傳回到需要的函數。    2 Set Next StateMent指令（debug過程中，右鍵菜單中的指令）    此指令的作用是将程式的指令指針（EIP）指向不同的代碼行。譬如，你正在調試上面那段代碼，運作在A行，但你不願意運作B行和C行代碼，這時，你就可以在 D行，右鍵，然後“Set Next StateMent”。調試器就不會執行B、C行。隻要在同一函數内，此指令就可以随意跳前或跳後執行。靈活使用此功能可以大量節省調試時間。    3 watch視窗    watch視窗支援豐富的資料格式化功能。如輸入0x65,u，則在右欄顯示101。    實時顯示windows API調用的錯誤：在左欄輸入@err,hr。    在watch視窗中調用函數。提醒一下，調用完函數後馬上在watch視窗中清除它，否則，單步調試時每一步調試器都會調用此函數。    4 messages斷點不怎麼實用。基本上可以用前面講述的斷點代替。

DLL的測試與調試通常都要用到用戶端，在用戶端的調用DLL的API之前添加斷點，可以直接進入到DLL内部調試。

通常的原因是由于被加載的dll同時加載了其他dll或者元件，當這些dll或者元件不存在時loadLibrary不會成功。可以使用Visual studio tools-〉depends， 将要加載的dll拖入到depends中，從裡面可以找出那些dll或者元件不存在。

絕大多數失敗也是由于加載dll不成功造成的。這是因為在注冊dll内部的元件時，首先要加載此dll，如果加載失敗，也會導緻regsvr32失敗，也可以采用上面的辦法。

若要在 ATL 中跟蹤引用數，請在包括 atlbase.h 之前添加以下代碼行：

#define _ATL_DEBUG_INTERFACES

該語句導緻在每次調用 AddRef 或 Release 時，“輸出”視窗均顯示接口的目前引用數以及對應的類名和接口名稱。

可将斷點設定于：void CDebugMainDlg::OnButtonTraceRefcnt()

若要在 ATL 中調試 QueryInterface 調用，請在包括 atlcom.h 之前添加以下定義：

#define _ATL_DEBUG_QI

然後在調試時，在“輸出”視窗中查找在對象上查詢的每個接口的名稱。

可将斷點設定于：void CDebugMainDlg::OnButtonTraceQI()

當涉及到多個線程通信時，要注意在正确的位置設定斷點。

void CDebugMainDlg::OnButtonProcThd()

void CDebugMainDlg::OnButtonWinThd()

void CDebugMainDlg::OnButtonThdMsg()

在例子中首先啟動一個運作線程函數的線程（Thread1），啟動一個CWinThread類型的線程（Thread2），之後在OnButtonThdMsg函數中使用event通知Thread1，當 Thread1接收到event之後，使用ThreadMessage通知Thread2。實際上還有一個視窗的主線程，也就是 OnButtonThdMsg運作的線程，是以要想全程根中點選button之後的運作情況，就要在各個線程中的恰當位置設定好斷點。

在程式的調試狀态，選擇debug->Threads，可以檢視目前運作的線程，并可以讓某個線程挂起，繼續執行等。

Debug通常稱為調試版本，它包含調試資訊，并且不作任何優化，便于程式員調試程式。Release稱為釋出版本，它往往是進行了各種優化，使得程式在代碼大小和運作速度上都是最優的，以便使用者很好地使用。

Debug 和 Release 的真正秘密，在于一組編譯選項。下面列出了分别針對二者的選項（當然除此之外還有其他一些，如/Fd /Fo，但差別并不重要，通常他們也不會引起 Release 版錯誤，在此不讨論）

Debug 版本

參數

 含義

/MDd /MLd 或 /MTd

 使用 Debug runtime library (調試版本的運作時刻函數庫)

/Od

 關閉優化開關

/D

 "_DEBUG" 相當于 #define _DEBUG,打開編譯調試代碼開關 (主要針對assert函數)

/ZI

 建立 Edit and continue(編輯繼續)資料庫，這樣在調試過程中如果修改了源代碼不需重新編譯

/GZ

 可以幫助捕獲記憶體錯誤

Release 版本

/MD /ML 或 /MT

 使用釋出版本的運作時刻函數庫

/O1 或 /O2

 優化開關，使程式最小或最快

 "NDEBUG" 關閉條件編譯調試代碼開關 (即不編譯assert函數)

/GF

 合并重複的字元串，并将字元串常量放到隻讀記憶體， 防止被修改

實際上，Debug 和 Release 并沒有本質的界限，他們隻是一組編譯選項的集合，編譯器隻是按照預定的選項行動。事實上，我們甚至可以修改這些選項，進而得到優化過的調試版本或是帶跟蹤語句的釋出版本。

哪些情況下 Release 版會出錯

有了上面的介紹，我們再來逐個對照這些選項看看 Release 版錯誤是怎樣産生的

1、Runtime Library：連結哪種運作時刻函數庫通常隻對程式的性能産生影響。調試版本的 Runtime Library 包含了調試資訊，并采用了一些保護機制以幫助發現錯誤，是以性能不如釋出版本。編譯器提供的 Runtime Library 通常很穩定，不會造成 Release 版錯誤；倒是由于 Debug 的 Runtime Library 加強了對錯誤的檢測，如堆記憶體配置設定，有時會出現 Debug 有錯但 Release 正常的現象。應當指出的是，如果 Debug 有錯，即使 Release 正常，程式肯定是有 Bug 的，隻不過可能是 Release 版的某次運作沒有表現出來而已。

2、優化：這是造成錯誤的主要原因，因為關閉優化時源程式基本上是直接翻譯的，而打開優化後編譯器會作出一系列假設。這類錯誤主要有以下幾種：

1. 幀指針(Frame Pointer)省略（簡稱FPO）：在函數調用過程中，所有調用資訊（傳回位址、參數）以及自動變量都是放在棧中的。若函數的聲明與實作不同（參數、傳回值、調用方式），就會産生錯誤，但 Debug 方式下，棧的通路通過 EBP 寄存器儲存的位址實作，如果沒有發生數組越界之類的錯誤（或是越界“不多”），函數通常能正常執行；Release 方式下，優化會省略 EBP 棧基址指針，這樣通過一個全局指針通路棧就會造成傳回位址錯誤是程式崩潰。

C++ 的強類型特性能檢查出大多數這樣的錯誤，但如果用了強制類型轉換，就不行了。你可以在 Release 版本中強制加入/Oy-編譯選項來關掉幀指針省略，以确定是否此類錯誤。此類錯誤通常有：MFC 消息響應函數書寫錯誤。正确的應為：

afx_msg LRESULT OnMessageOwn

(WPARAM wparam, LPARAM lparam);

ON_MESSAGE 宏包含強制類型轉換。防止這種錯誤的方法之一是重定義 ON_MESSAGE 宏，把下列代碼加到 stdafx.h 中（在#include "afxwin.h"之後）,函數原形錯誤時編譯會報錯。

#undef ON_MESSAGE

#define ON_MESSAGE(message, memberFxn) /

message, 0, 0, 0, AfxSig_lwl, /

(AFX_PMSG)(AFX_PMSGW)

(static_cast< LRESULT (AFX_MSG_CALL /

CWnd::*)(WPARAM, LPARAM) > (&memberFxn)

},

2. volatile 型變量：volatile 告訴編譯器該變量可能被程式之外的未知方式修改（如系統、其他程序和線程）。優化程式為了使程式性能提高，常把一些變量放在寄存器中（類似于 register 關鍵字），而其他程序隻能對該變量所在的記憶體進行修改，而寄存器中的值沒變。

如果你的程式是多線程的，或者你發現某個變量的值與預期的不符而你确信已正确的設定了，則很可能遇到這樣的問題。這種錯誤有時會表現為程式在最快優化出錯而最小優化正常。把你認為可疑的變量加上volatile 試試。

3. 變量優化：優化程式會根據變量的使用情況優化變量。例如，函數中有一個未被使用的變量，在 Debug 版中它有可能掩蓋一個數組越界，而在 Release 版中，這個變量很可能被優化調，此時數組越界會破壞棧中有用的資料。當然，實際的情況會比這複雜得多。與此有關的錯誤有非法通路，包括數組越界、指針錯誤等。例如：

void fn(void)

 int i;

 i = 1;

 int a[4];

 {

    int j;

    j = 1;

 }

 a[-1] = 1;

 //當然錯誤不會這麼明顯，例如下标是變量

 a[4] = 1;

}

j 雖然在數組越界時已出了作用域，但其空間并未收回，因而 i 和 j 就會掩蓋越界。而 Release 版由于 i、j 并未其很大作用可能會被優化掉，進而使棧被破壞。

3. DEBUG 與 NDEBUG ：當定義了 _DEBUG 時，assert() 函數會被編譯，而 NDEBUG 時不被編譯。此外，TRACE() 宏的編譯也受 _DEBUG 控制。

所有這些斷言都隻在 Debug版中才被編譯，而在 Release 版中被忽略。唯一的例外是 VERIFY()。事實上，這些宏都是調用了assert()函數，隻不過附加了一些與庫有關的調試代碼。如果你在這些宏中加入了任何程式代碼，而不隻是布爾表達式（例如指派、能改變變量值的函數調用等），那麼Release版都不會執行這些操作，進而造成錯誤。初學者很容易犯這類錯誤，查找的方法也很簡單，因為這些宏都已在上面列出，隻要利用 VC++ 的 Find in Files 功能在工程所有檔案中找到用這些宏的地方再一一檢查即可。另外，有些高手可能還會加入 #ifdef _DEBUG 之類的條件編譯，也要注意一下。

順便值得一提的是VERIFY() 宏，這個宏允許你将程式代碼放在布爾表達式裡。這個宏通常用來檢查 Windows API的傳回值。有些人可能為這個原因而濫用VERIFY()，事實上這是危險的，因為VERIFY()違反了斷言的思想，不能使程式代碼和調試代碼完全分離，最終可能會帶來很多麻煩。是以，專家們建議盡量少用這個宏。

4. /GZ 選項：這個選項會做以下這些事：

1. 初始化記憶體和變量。包括用 0xCC 初始化所有自動變量，0xCD ( Cleared Data ) 初始化堆中配置設定的記憶體（即動态配置設定的記憶體，例如 new ），0xDD ( Dead Data ) 填充已被釋放的堆記憶體（例如 delete ），0xFD( deFencde Data ) 初始化受保護的記憶體（debug 版在動态配置設定記憶體的前後加入保護記憶體以防止越界通路），其中括号中的詞是微軟建議的助記詞。這樣做的好處是這些值都很大，作為指針是不可能的（而且 32 位系統中指針很少是奇數值，在有些系統中奇數的指針會産生運作時錯誤），作為數值也很少遇到，而且這些值也很容易辨認，是以這很有利于在 Debug 版中發現 Release 版才會遇到的錯誤。要特别注意的是，很多人認為編譯器會用0來初始化變量，這是錯誤的（而且這樣很不利于查找錯誤）。

2. 通過函數指針調用函數時，會通過檢查棧指針驗證函數調用的比對性。（防止原形不比對）

3. 函數傳回前檢查棧指針，确認未被修改。（防止越界通路和原形不比對，與第二項合在一起可大緻模拟幀指針省略 FPO ）通常 /GZ 選項會造成 Debug 版出錯而 Release 版正常的現象，因為 Release 版中未初始化的變量是随機的，這有可能使指針指向一個有效位址而掩蓋了非法通路。除此之外，/Gm/GF等選項造成錯誤的情況比較少，而且他們的效果顯而易見，比較容易發現。

怎樣“調試” Release 版的程式

2. 在程式設計過程中就要時常注意測試 Release 版本，以免最後代碼太多，時間又很緊。

3. 在 Debug 版中使用 /W4 警告級别，這樣可以從編譯器獲得最大限度的錯誤資訊，比如 if( i =0 )就會引起 /W4 警告。不要忽略這些警告，通常這是你程式中的 Bug 引起的。但有時 /W4 會帶來很多備援資訊，如 未使用的函數參數 警告，而很多消息處理函數都會忽略某些參數。我們可以用:

#progma warning(disable: 4702)

//禁止

//...

#progma warning(default: 4702)

//重新允許來暫時禁止某個警告，或使用

#progma warning(push, 3)

//設定警告級别為 /W3

#progma warning(pop)

//重設為 /W4

來暫時改變警告級别，有時你可以隻在認為可疑的那一部分代碼使用 /W4。

      當程式在Release下出錯，而在debug下不出錯時，就需要用到release方式下的調試技術。在用release方式下的調試技術之前，對代碼進行如下檢查：

1 release方式下沒有代碼被注釋掉，如ASSERT(a=f()); TRACE(f());在release下是會被注釋掉的。

2 檢查所有的變量是否被初始化

3 檢查邊界錯誤，如以下代碼：

void func()

    {

     char buffer[10];

     int counter;

     lstrcpy(buffer, "abcdefghik"); // 11-byte copy, including NULL

     ...

release方式下的調試技術：

1 在VC IDE中選擇Project Settings (Alt-F2)， 在 "C++/C tab" 中設定 category為 "General"将Debug Info setting 改為"Program Database".

2 在"Link tab"中選中"Generate Debug Info" tab.

3 執行"Rebuild All"

注意：1 有時也需要禁止release方式下的優化選項

      2 如果有些代碼段無法設定斷點，可以加入如下代碼：

             __asm {int 3}；

         效果與Debug方式下的ASSERT(FALSE)類似

      當一個應用程式是被另一個應用程式啟動時，或者多個應用程式之間進行互動，就要用到多程序調試技術，方法是：

1 啟動任務管理器，選擇要調試的程序，點選滑鼠右鍵，選擇debug

2 啟動VC IDE,選擇下圖所示的菜單，在選擇相應的程序

注意：這裡有一個問題，可能我們想要設斷點的代碼在程序能夠調試前已經執行過，無法設斷點，解決辦法有兩個：

1 在設斷點的代碼加入代碼

   ASSERT(FALSE);

 程序運作時會出現下述對話框，選擇retry就可以進行調試

2 在設斷點的代碼加入代碼

   AfxMessageBox(“debug”);//debug是任意的

 程序運作時會出現對話框，此時attach改進成就可以進行調試

當多個程序同時處于調試狀态，我們就可以從各自的調試視窗看到TRACE資訊。

很多情況下如果不加條件的直接在MouseMove 響應函數内消息設定斷點，并不友善調試，比如當滑鼠在移動到某一區域内出錯的情況，就無法利用斷點跟蹤，這時候可以在程式中，多添加一些TRACE語句，來定位，對于Release版還有可以用log工具輸出到log檔案，如果沒有現成的log工具可以用，也可以自己編寫一個非常簡單的log工具。

PreTranslateMessage，HookMessage，與上面的情況類似。

Visual studio tools->Spy++->ctrl+F

将圓圈圖示拖動到目标視窗上，可以在下面看到有關視窗的一些資訊。

Caption：視窗的标題。

Class：類明。

Style：視窗風格：

Rect：視窗的位置和大小

在上面的視窗中選擇Properties radio button->OK，可以在下面的視窗中檢視各種資訊。

若在途中選擇Messages radio button->OK->ctrl+o,

上面的途中列出了所有可以看到的消息，若隻關心某一類消息，比如，滑鼠消息。

則點選Clear ALL，然後在右面隻選中Mouse check box.

單擊OK。

則所有有關滑鼠的消息，都可以顯示在輸出視窗上。如果隻想跟蹤WM_LBUTTONDOWN的消息，則在左側Messages to View框中，隻選中WM_LBUTTONDOWN.

如果想監視某一個空間，比如button，則可以将finder tool定位在那個button上。然後按照上面的步驟進行設定。

調試最重要的還是你要思考，要猜測你的程式可能出錯的地方，然後運用你的調試器來證明你的猜測。而熟練使用上面這些技巧無疑會加快這個過程。另外在調試過程中，不要局限于一種方法，将幾個方法結合在一起使用，可以加快錯誤定位的速度，以便較快的解決問題。