VC++ 6.0 中如何使用 CRT 調試功能來檢測內存泄漏 - 1

 VC++ 6.0 中如何使用 CRT 調試功能來檢測內存泄漏

做者：JerryZ

下載例子源代碼

　　最近看了周星星 Blog 中的一篇文章：「 VC++6.0中內存泄漏檢測 」，受益不淺，便運行其例子代碼想看看 Output 窗口中的輸出結果，惋惜怎麼弄其輸出都不是預期的東西，鬱悶了半天，便到水壇裏找到周星星，請求他指點1、二，然而未果。沒有辦法，最後我一頭栽進 MSDN 庫狂搜了一把，功夫不負有心人，我搜出不少有關這方面的資料，沒過多久我便基本上就找到了答案......
首先，檢測內存泄漏的基本工具是調試器和 CRT 調試堆函數。爲了使用調試堆函數，必須在要檢測內存泄漏和調試的程序中添加下面的語句：

#define _CRTDBG_MAP_ALLOC  #include<stdlib.h>  #include<crtdbg.h>   #include "debug_new.h" 

　　MSDN 如是說：「必須保證上面聲明的順序，若是改變了順序，可能不能正常工做。」至於這是爲何，咱們不得而知。MS 的老大們常常這樣故弄玄虛。
針對非 MFC 程序，再加上週星星的頭文件：debug_new.h，固然若是不加這一句，也能檢測出內存泄漏，可是你沒法肯定在哪一個源程序文件中發生泄漏。Output 輸出只告訴你在 crtsdb.h 中的某個地方有內存泄漏。我測試時 REG_DEBUG_NEW 沒有起做用。加不加這個宏均可以檢測出發生內存分配泄漏的文件。
其次，一旦添加了上面的聲明，你就能夠經過在程序中加入下面的代碼來報告內存泄漏信息了：

      _CrtDumpMemoryLeaks(); 

　　這就這麼簡單。我在周星星的例子代碼中加入這些機關後，在 VC++ 調試會話（按 F5 調試運行） Output 窗口的 Debug 頁便看到了預期的內存泄漏 dump。該 dump 形式以下：

Detected memory leaks!  Dumping objects ->  c:\Program Files\...\include\crtdbg.h(552) : {45} normal block at 0x00441BA0, 2 bytes long.  Data: <AB> 41 42  c:\Program Files\...\include\crtdbg.h(552) : {44} normal block at 0x00441BD0, 33 bytes long.  Data: < C > 00 43 00 CD CD CD CD CD CD CD CD CD CD CD CD CD  c:\Program Files\...\include\crtdbg.h(552) : {43} normal block at 0x00441C20, 40 bytes long.  Data: < C > E8 01 43 00 16 00 00 00 00 00 00 00 00 00 00 00  Object dump complete. 

更具體的細節請參考本文附帶的源代碼文件。

下面是我看過 MSDN 資料後，針對「如何使用 CRT 調試功能來檢測內存泄漏？」的問題進行了一番編譯和整理，但願對你們有用。若是你的英文很棒，那就不用往下看了，建議直接去讀 MSDN 庫中的技術原文。
C/C++ 編程語言的最強大功能之一即是其動態分配和釋放內存，可是中國有句古話：「最大的長處也可能成爲最大的弱點」，那麼 C/C++ 應用程序正好印證了這句話。在 C/C++ 應用程序開發過程當中，動態分配的內存處理不當是最多見的問題。其中，最難捉摸也最難檢測的錯誤之一就是內存泄漏，即未能正確釋放之前分配的內存的錯誤。偶爾發生的少許內存泄漏可能不會引發咱們的注意，但泄漏大量內存的程序或泄漏日益增多的程序可能會表現出各類 各樣的徵兆：從性能不良（而且逐漸下降）到內存徹底耗盡。更糟的是，泄漏的程序可能會用掉太多內存，致使另一個程序垮掉，而使用戶無從查找問題的真正根源。此外，即便無害的內存泄漏也可能殃及池魚。
幸運的是，Visual Studio 調試器和 C 運行時 (CRT) 庫爲咱們提供了檢測和識別內存泄漏的有效方法。下面請和我一塊兒分享收穫——如何使用 CRT 調試功能來檢測內存泄漏？

1. 如何啓用內存泄漏檢測機制？
   • 使用 _CrtSetDbgFlag
   • 設置 CRT 報告模式
2. 解釋內存塊類型
3. 如何在內存分配序號處設置斷點？
4. 如何比較內存狀態？
5. 結論

如何啓用內存泄漏檢測機制？

　　VC++ IDE 的默認狀態是沒有啓用內存泄漏檢測機制的，也就是說即便某段代碼有內存泄漏，調試會話的 Output 窗口的 Debug 頁不會輸出有關內存泄漏信息。你必須設定兩個最基本的機關來啓用內存泄漏檢測機制。

一是使用調試堆函數：

#define _CRTDBG_MAP_ALLOC  #include<stdlib.h>  #include<crtdbg.h> 

注意：#include 語句的順序。若是更改此順序，所使用的函數可能沒法正確工做。

經過包含 crtdbg.h 頭文件，能夠將 malloc 和 free 函數映射到其「調試」版本 _malloc_dbg 和 _free_dbg，這些函數會跟蹤內存分配和釋放。此映射只在調試（Debug）版本（也就是要定義 _DEBUG）中有效。發行版本（Release）使用普通的 malloc 和 free 函數。
#define 語句將 CRT 堆函數的基礎版本映射到對應的「調試」版本。該語句不是必須的，但若是沒有該語句，那麼有關內存泄漏的信息會不全。

二是在須要檢測內存泄漏的地方添加下面這條語句來輸出內存泄漏信息：

_CrtDumpMemoryLeaks();

　　當在調試器下運行程序時，_CrtDumpMemoryLeaks 將在 Output 窗口的 Debug 頁中顯示內存泄漏信息。好比：

Detected memory leaks! Dumping objects -> C:\Temp\memleak\memleak.cpp(15) : {45} normal block at 0x00441BA0, 2 bytes long. Data: <AB> 41 42  c:\program files\microsoft visual studio\vc98\include\crtdbg.h(552) : {44} normal block at 0x00441BD0, 33 bytes long. Data: < C > 00 43 00 CD CD CD CD CD CD CD CD CD CD CD CD CD  c:\program files\microsoft visual studio\vc98\include\crtdbg.h(552) : {43} normal block at 0x00441C20, 40 bytes long. Data: < C > 08 02 43 00 16 00 00 00 00 00 00 00 00 00 00 00  Object dump complete.

若是不使用 #define _CRTDBG_MAP_ALLOC 語句，內存泄漏的輸出是這樣的：

Detected memory leaks! Dumping objects -> {45} normal block at 0x00441BA0, 2 bytes long. Data: <AB> 41 42  {44} normal block at 0x00441BD0, 33 bytes long. Data: < C > 00 43 00 CD CD CD CD CD CD CD CD CD CD CD CD CD  {43} normal block at 0x00441C20, 40 bytes long. Data: < C > C0 01 43 00 16 00 00 00 00 00 00 00 00 00 00 00  Object dump complete.

　　根據這段輸出信息，你沒法知道在哪一個源程序文件裏發生了內存泄漏。下面咱們來研究一下輸出信息的格式。第一行和第二行沒有什麼可說的，從第三行開始：

xx}：花括弧內的數字是內存分配序號，本文例子中是 {45}，{44}，{43}； block：內存塊的類型，經常使用的有三種：normal（普通）、client（客戶端）或 CRT（運行時）；本文例子中是：normal block；  用十六進制格式表示的內存位置，如：at 0x00441BA0 等； 以字節爲單位表示的內存塊的大小，如：32 bytes long；  前 16 字節的內容（也是用十六進制格式表示），如：Data: <AB> 41 42 等；

　　仔細觀察不難發現，若是定義了 _CRTDBG_MAP_ALLOC ，那麼在內存分配序號前面還會顯示在其中分配泄漏內存的文件名，以及文件名後括號中的數字表示發生泄漏的代碼行號，好比：

C:\Temp\memleak\memleak.cpp(15) 

　　雙擊 Output 窗口中此文件名所在的輸出行，即可跳到源程序文件分配該內存的代碼行（也能夠選中該行，而後按 F4，效果同樣） ，這樣一來咱們就很容易定位內存泄漏是在哪裏發生的了，所以，_CRTDBG_MAP_ALLOC 的做用顯而易見。

使用 _CrtSetDbgFlag

若是程序只有一個出口，那麼調用 _CrtDumpMemoryLeaks 的位置是很容易選擇的。可是，若是程序可能會在多個地方退出該怎麼辦呢？在每個可能的出口處調用 _CrtDumpMemoryLeaks 確定是不可取的，那麼這時能夠在程序開始處包含下面的調用：

_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

　　這條語句不管程序在什麼地方退出都會自動調用 _CrtDumpMemoryLeaks。注意：這裏必須同時設置兩個位域標誌：_CRTDBG_ALLOC_MEM_DF 和 _CRTDBG_LEAK_CHECK_DF。

設置 CRT 報告模式

默認狀況下，_CrtDumpMemoryLeaks 將內存泄漏信息 dump 到 Output 窗口的 Debug 頁， 若是你想將這個輸出定向到別的地方，可使用 _CrtSetReportMode 進行重置。若是你使用某個庫，它可能將輸出定向到另外一位置。此時，只要使用如下語句將輸出位置設回 Output 窗口便可：

_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_DEBUG );

有關使用 _CrtSetReportMode 的詳細信息，請參考 MSDN 庫關於 _CrtSetReportMode 的描述。

解釋內存塊類型

前面已經說過，內存泄漏報告中把每一塊泄漏的內存分爲 normal（普通塊）、client（客戶端塊）和 CRT 塊。事實上，須要留心和注意的也就是 normal 和 client，即普通塊和客戶端塊。

• normal block（普通塊）：這是由你的程序分配的內存。
• client block（客戶塊）：這是一種特殊類型的內存塊，專門用於 MFC 程序中須要析構函數的對象。MFC new 操做符視具體狀況既能夠爲所建立的對象創建普通塊，也能夠爲之創建客戶塊。
• CRT block（CRT 塊）：是由 C RunTime Library 供本身使用而分配的內存塊。由 CRT 庫本身來管理這些內存的分配與釋放，咱們通常不會在內存泄漏報告中發現 CRT 內存泄漏，除非程序發生了嚴重的錯誤（例如 CRT 庫崩潰）。

除了上述的類型外，還有下面這兩種類型的內存塊，它們不會出如今內存泄漏報告中：

• free block（空閒塊）：已經被釋放(free)的內存塊。
• Ignore block（忽略塊）：這是程序員顯式聲明過不要在內存泄漏報告中出現的內存塊。

如何在內存分配序號處設置斷點？

　　在內存泄漏報告中，的文件名和行號可告訴分配泄漏的內存的代碼位置，但僅僅依賴這些信息來了解完整的泄漏緣由是不夠的。由於一個程序在運行時，一段分配內存的代碼可能會被調用不少次，只要有一次調用後沒有釋放內存就會致使內存泄漏。爲了肯定是哪些內存沒有被釋放，不只要知道泄漏的內存是在哪裏分配的，還要知道泄漏產生的條件。這時內存分配序號就顯得特別有用——這個序號就是文件名和行號以後的花括弧裏的那個數字。
例如，在本文例子代碼的輸出信息中，「45」是內存分配序號，意思是泄漏的內存是你程序中分配的第四十五個內存塊：

Detected memory leaks! Dumping objects -> C:\Temp\memleak\memleak.cpp(15) : {45} normal block at 0x00441BA0, 2 bytes long. Data: <AB> 41 42  ...... Object dump complete. 

　　CRT 庫對程序運行期間分配的全部內存塊進行計數，包括由 CRT 庫本身分配的內存和其它庫（如 MFC）分配的內存。所以，分配序號爲 N 的對象即爲程序中分配的第 N 個對象，但不必定是代碼分配的第 N 個對象。（大多數狀況下並不是如此。）
這樣的話，你即可以利用分配序號在分配內存的位置設置一個斷點。方法是在程序起始附近設置一個位置斷點。當程序在該點中斷時，能夠從 QuickWatch（快速監視）對話框或 Watch（監視）窗口設置一個內存分配斷點：

例如，在 Watch 窗口中，在 Name 欄鍵入下面的表達式：

_crtBreakAlloc

若是要使用 CRT 庫的多線程 DLL 版本（/MD 選項），那麼必須包含上下文操做符，像這樣：

{,,msvcrtd.dll}_crtBreakAlloc

　　如今按下回車鍵，調試器將計算該值並把結果放入 Value 欄。若是沒有在內存分配點設置任何斷點，該值將爲 –1。
用你想要在其位置中斷的內存分配的分配序號替換 Value 欄中的值。例如輸入 45。這樣就會在分配序號爲 45 的地方中斷。 
在所感興趣的內存分配處設置斷點後，能夠繼續調試。這時，運行程序時必定要當心，要保證內存塊分配的順序不會改變。當程序在指定的內存分配處中斷時，能夠查看 Call Stack（調用堆棧）窗口和其它調試器信息以肯定分配內存時的狀況。若是必要，能夠從該點繼續執行程序，以查看對象發生了什麼狀況，或許能夠肯定未正確釋放對象的緣由。
儘管一般在調試器中設置內存分配斷點更方便，但若是願意，也可在代碼中設置這些斷點。爲了在代碼中設置一個內存分配斷點，能夠增長這樣一行（對於第四十五個內存分配）：

_crtBreakAlloc = 45;

你還可使用有相同效果的 _CrtSetBreakAlloc 函數：

_CrtSetBreakAlloc(45);

如何比較內存狀態？

　　定位內存泄漏的另外一個方法就是在關鍵點獲取應用程序內存狀態的快照。CRT 庫提供了一個結構類型 _CrtMemState。你能夠用它來存儲內存狀態的快照：

_CrtMemState s1, s2, s3;

　　若要獲取給定點的內存狀態快照，能夠向 _CrtMemCheckpoint 函數傳遞一個 _CrtMemState 結構。該函數用當前內存狀態的快照填充此結構：

_CrtMemCheckpoint( &s1 );

　　經過向 _CrtMemDumpStatistics 函數傳遞 _CrtMemState 結構，能夠在任意地方 dump 該結構的內容：

_CrtMemDumpStatistics( &s1 );

該函數輸出以下格式的 dump 內存分配信息：

0 bytes in 0 Free Blocks. 75 bytes in 3 Normal Blocks. 5037 bytes in 41 CRT Blocks. 0 bytes in 0 Ignore Blocks. 0 bytes in 0 Client Blocks. Largest number used: 5308 bytes. Total allocations: 7559 bytes.

　　若要肯定某段代碼中是否發生了內存泄漏，能夠經過獲取該段代碼以前和以後的內存狀態快照，而後使用 _CrtMemDifference 比較這兩個狀態：

_CrtMemCheckpoint( &s1 );// 獲取第一個內存狀態快照  // 在這裏進行內存分配  _CrtMemCheckpoint( &s2 );// 獲取第二個內存狀態快照  // 比較兩個內存快照的差別 if ( _CrtMemDifference( &s3, &s1, &s2) )      _CrtMemDumpStatistics( &s3 );// dump 差別結果

　　顧名思義，_CrtMemDifference 比較兩個內存狀態（前兩個參數），生成這兩個狀態之間差別的結果（第三個參數）。在程序的開始和結尾放置 _CrtMemCheckpoint 調用，並使用 _CrtMemDifference 比較結果，是檢查內存泄漏的另外一種方法。若是檢測到泄漏，則可使用 _CrtMemCheckpoint 調用經過二進制搜索技術來分割程序和定位泄漏。

結論

儘管 VC ++ 具備一套專門調試 MFC 應用程序的機制，但本文上述討論的內存分配很簡單，沒有涉及到 MFC 對象，因此這些內容一樣也適用於 MFC 程序。在 MSDN 庫中能夠找到不少有關 VC++ 調試方面的資料，若是你能善用 MSDN 庫，相信用不了多少時間你就有可能成爲調試高手。

本人水平不高，謬誤在所不免，請你們拍磚，不要客氣。順祝你們聖誕快樂！

JerryZ 於 2004 年平安夜，

 

調試方法和技巧

做者：非凡

便於調試的代碼風格：

1. 不用全局變量
2. 全部變量都要初始化，成員變量在構造函數中初始化
3. 儘可能使用const
4. 詳盡的註釋

VC++編譯選項：

1. 老是使用/W4警告級別
2. 在調試版本里老是使用/GZ編譯選項，用來發如今Release版本中才有的錯誤
3. 沒有警告的編譯：保證在編譯後沒有任何警告，可是在消除警告前要進行仔細檢查

調試方法：

一、使用 Assert（原則：儘可能簡單）
assert只在debug下生效，release下不會被編譯。

例子：

char* strcpy(char* dest,char* source) { 	assert(source!=0); 	assert(dest!=0); 	char* returnstring = dest; 	 	while((*dest++ = *source++)!= ‘\0’) 	{ 		; 	} 	return returnstring; }      

二、防護性的編程

例子：

char* strcpy(char* dest,char* source) { 	if(source == 0) 	{ 		assert(false); 		reutrn 0; 	}  	if(dest == 0) 	{ 		assert(false); 		return 0; 	} 	char* returnstring = dest; 	while((*dest++ = *source++)!= ‘\0’) 	{ 		; 	} 	return returnstring; }      

三、使用Trace

如下的例子只能在debug中顯示，

例子：

a)、TRACE

CString csTest ＝ 「test」； TRACE（「CString is ％s\n」，csTest）；

b)、ATLTRACE

c)、afxDump

CTime time = CTime::GetCurrentTime(); #ifdef _DEBUG afxDump << time << 「\n」; #endif

四、用GetLastError來檢測返回值，經過獲得錯誤代碼來分析錯誤緣由

五、把錯誤信息記錄到文件中

異常處理

程序設計時必定要考慮到異常如何處理，當錯誤發生後，不該簡單的報告錯誤並退出程序，應當儘量的想辦法恢復到出錯前的狀態或者讓程序從頭開始運行，而且對於某些錯誤，應該可以容錯，即容許錯誤的存在，可是程序仍是可以正常完成任務。

調試技巧

一、VC++中F5進行調試運行

a)、在output Debug窗口中能夠看到用TRACE打印的信息
b)、 Call Stack窗口中能看到程序的調用堆棧

二、當Debug版本運行時發生崩潰，選擇retry進行調試，經過看Call Stack分析出錯的位置及緣由
三、使用映射文件調試

a)、建立映射文件：Project settings中link項，選中Generate mapfile，輸出程序代碼地址：/MAPINFO: LINES，獲得引出序號：/MAPINFO: EXPORTS。
b)、程序發佈時，應該把全部模塊的映射文件都存檔。
c)、查看映射文件：見」 經過崩潰地址找出源代碼的出錯行」文件。

四、能夠調試的Release版本

Project settings中C++項的Debug Info選擇爲Program Database，Link項的Debug中選擇Debug Info和Microsoft format。

五、查看API的錯誤碼，在watch窗口輸入@err能夠查看或者@err,hr，其中」,hr」表示錯誤碼的說明。
六、Set Next Statement：該功能能夠直接跳轉到指定的代碼行執行，通常用來測試異常處理的代碼。
七、調試內存變量的變化：當內存發生變化時停下來。

常見錯誤

一、在函數返回的時候程序崩潰的緣由

a)、寫自動變量越界
b)、函數原型不匹配

二、MFC

a)、使用錯誤的函數原型處理用戶定義消息

正確的函數原型爲：

afx_msg LRESULT OnMyMessage(WPARAM wParam,LPARAM lParam);

三、謹慎使用TerminateThread：使用TerminateThread會形成資源泄漏，不到萬不得已，不要使用。

四、使用_beginthreadex，不要使用Create Thread來常見線程。

參考資料：
《Windows程序調試》

功能強大的vc6調試器


做者：yy2better

  要成爲一位優秀的軟件工程師，調試能力必不可缺。本文將較詳細介紹VC6調試器的主要用法。 
  windows平臺的調試器主要分爲兩大類： 
  1 用戶模式(user-mode)調試器：它們都基於win32 Debugging API，有使用方便的界面，主要用於調試用戶模式下的應用程序。這類調試器包括Visual C++調試器、WinDBG、BoundChecker、Borland C++ Builder調試器、NTSD等。 
  2 內核模式(kernel-mode)調試器：內核調試器位於CPU和操做系統之間，一旦啓動，操做系統也會停止運行，主要用於調試驅動程序或用戶模式調試器不易調試的程序。這類調試器包括WDEB38六、WinDBG和softice等。其中WinDBG和softice也能夠調試用戶模式代碼。 
  國外一位調試高手曾說，他70％調試時間是在用VC++，其他時間是使用WinDBG和softice。畢竟，調試用戶模式代碼，VC6調試器的效率是很是高的。所以，我將首先在本篇介紹VC6調試器的主要用法，其餘調試器的用法及一些調試技能在後續文章中闡述。 

一 位置斷點（Location Breakpoint） 
  你們最經常使用的斷點是普通的位置斷點，在源程序的某一行按F9就設置了一個位置斷點。但對於不少問題，這種樸素的斷點做用有限。譬以下面這段代碼：

void CForDebugDlg::OnOK() 	 { 	for (int i = 0; i < 1000; i++)	//A 	{ 		int k = i * 10 - 2;	//B 		SendTo(k);		//C 		int tmp = DoSome(i);	//D 		int j = i / tmp;	//E 	} }             

  執行此函數，程序崩潰於E行，發現此時tmp爲0，假設tmp本不該該爲0，怎麼這個時候爲0呢？因此最好可以跟蹤這次循環時DoSome函數是如何運行的，但因爲是在循環體內，若是在E行設置斷點，可能須要按F5（GO）許屢次。這樣手要不停的按，很痛苦。使用VC6斷點修飾條件就能夠輕易解決此問題。步驟以下。 
  1 Ctrl+B打開斷點設置框，以下圖： 
 
Figure 1設置高級位置斷點 
  2 而後選擇D行所在的斷點，而後點擊condition按鈕，在彈出對話框的最下面一個編輯框中輸入一個很大數目，具體視應用而定，這裏1000就夠了。 
  3 按F5從新運行程序，程序中斷。Ctrl+B打開斷點框，發現此斷點後跟隨一串說明：...487 times remaining。意思是還剩下487次沒有執行，那就是說執行到513（1000－487）次時候出錯的。所以，咱們按步驟2所講，更改此斷點的skip次數,將1000改成513。 
  4 再次從新運行程序，程序執行了513次循環，而後自動停在斷點處。這時，咱們就能夠仔細查看DoSome是如何返回0的。這樣，你就避免了手指的痛苦，節省了時間。 
  再看位置斷點其餘修飾條件。如Figure 1所示，在「Enter the expression to be evaluated:」下面，能夠輸入一些條件，當這些條件知足時，斷點才啓動。譬如，剛纔的程序，咱們須要i爲100時程序停下來，咱們就能夠輸入在編輯框中輸入「i==100」。 
  另外，若是在此編輯框中若是隻輸入變量名稱，則變量發生改變時，斷點纔會啓動。這對檢測一個變量什麼時候被修改很方便，特別對一些大程序。 
  用好位置斷點的修飾條件，能夠大大方便解決某些問題。 

二 數據斷點（Data Breakpoint） 
  軟件調試過程當中，有時會發現一些數據會莫名其妙的被修改掉（如一些數組的越界寫致使覆蓋了另外的變量），找出何處代碼致使這塊內存被更改是一件棘手的事情（若是沒有調試器的幫助）。恰當運用數據斷點能夠快速幫你定位什麼時候何處這個數據被修改。譬以下面一段程序：

#include "stdafx.h" #include 
   
   
   
     int main(int argc, char* argv[]) { 	char szName1[10]; 	char szName2[4]; 	strcpy(szName1,"shenzhen");		 	printf("%s\n", szName1);		//A  	strcpy(szName2, "vckbase");		//B 	printf("%s\n", szName1); 	printf("%s\n", szName2);  	return 0; }       

  這段程序的輸出是

      	szName1: shenzhen 	szName1: ase 	szName2: vckbase      

szName1什麼時候被修改呢？由於沒有明顯的修改szName1代碼。咱們能夠首先在A行設置普通斷點，F5運行程序，程序停在A行。而後咱們再設置一個數據斷點。以下圖： 
 
Figure 2 數據斷點 
  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斷點不怎麼實用。基本上能夠用前面講述的斷點代替。 
總結    調試最重要的仍是你要思考，要猜想你的程序可能出錯的地方，而後運用你的調試器來證明你的猜想。而熟練使用上面這些技巧無疑會加快這個過程。最後，你們若是有關於調試方面的問題，我樂意參與探討。