最近碰巧讀了Ivan Shcherbakov寫的一篇文章，《11個強大的Visual Studio調試小技巧》。這篇文章只介紹了一些有關Visual Studio的基本調試技巧，但是還有其他一些同樣有用的技巧。我整理了一些Visual Studio（至少在VS 2008下）原生開發的調試技巧。（如果你是工作在托管代碼下，調試器會有更多的特性，在CodePRoject中有介紹它們的文章），下面是我的整理的一些技巧：
在處理被調用之前，異常發生時可以 啟動調試器進行中斷,可以讓你在異常發生后立即調試程序。操作調用棧便于你去查找異常發生的根本原因。
Vistual Studio允許你去指定想要中斷的異常類型或者特殊異常。選擇菜單Debug>Exceptions彈出對話框，你可以指定原生的（或者托管的）異常，除了調試器自帶的一些默認異常，你還可以添加自己的自定義異常。
下面是一個std::exception 異常拋出時調試器中斷的例子。
更多閱讀：
Watch窗口或QuickWatch對話框提供一些特定的（調試器可識別的）變量，被稱為偽變量。文檔包含以下：
不管怎么樣，關于最后一個錯誤的偽變量是非常有用的：
更多閱讀：偽變量
有時候，在調試符號越界后，你還想查看對象的值，這個時候，watch窗口中的變量是被禁用的，不能再查看（也不能更新），盡管對象仍然存在。你如果知道對象的地址，可以繼續充分地觀察它。你可以將地址轉換為該對象類型的指針，放在watch窗中。
下面的例子中，當單步跳出do_foo()之后，_foo不能再被訪問。但是，將它的地址轉換為foo*后，就可以繼續觀察這個對象。
如果你在操作一個很大的數組(我們假設至少有幾百個元素吧,但是可能更少),在Watch窗口中展開數組,查找一些特定范圍內的元素很麻煩,因為你要不停地滾動.如果數組是分配在堆上的話,你甚至不能在watch窗口中展開數組元素.對此，有一個解決辦法。你可以使用(array+ <offset>),<count> 去查看從<offset>位置開始的特定范圍的<count>元素（當然，這兒的數組是你的實際對象）。如果想查看整個數組，可以簡單使用array,<count>.
如果你的數組是在堆上，你可以在watch窗口中將它展開，但是要查看某個特定范圍的值，用法稍有不同：((T*) array + <offset>),<count>(注意這種用法對于堆上的多維數組也有效)。但是這種情況下，T是指數組元素的類型。
如果你在用MFC，并使用其中的’array’容器，像 CArray, CDWordArray,CStringArray等等。你當然可以使用同樣的過濾方法。除此之外，你必須查看array的m_pData成員，它是保存數據的真實緩存。
很多時候，你在調試代碼時可能會進入到你想跳過的函數，像構造函數，賦值操作或者其他的。其中最困擾我的是CString構造函數。下面是一個例子，當你準備單步執行take_a_string()函數時，首先進入到CString的構造函數。
void take_a_string(CString const &text){}void test_string(){ take_a_string(_T("sample"));}
幸運的是可以告訴調試器去跳過哪些方法，類或者整個命名空間。實現它的方法也已經改變了,回到使用VS6的日子，通常是通過autoexp.dat文件來指定的。Vistual Studio 2002改成了使用注冊表設置。想要跳過一些函數，你需要在注冊表里添加一些值（詳情如下）：
為了避免進入任何CString方法，我添加了下面的規則：
有了這個，即使你強制進入上例中的take_a_string()，調試器也會跳過CString的構造函數。
更多閱讀：
你可能很少需要將調試器附加到程序中，但你不能在Attach窗口這樣做（可能因為中斷發生太快而沒有捕獲到），你也不能一開始就在調試器中啟動程序。你可以在程序中產生中斷給調試器一個機會通過調用內部的_degbugbreak()來附加。
void break_for_debugging(){ __debugbreak();}實際上還有其他的方法來完成,例如觸發中斷3,但這僅僅適用于x86平臺（C++64位不再支持ASM）。另外還有DebugBreak()函數，但它的使用不怎么簡便，所以這里推薦使用內部方法。
__asm int 3;
程序運行內部方法時會停止運行，這時你就有機會將調試器附加到該進程。
更多閱讀：
通過調用DebugOutputString可以在調試器的output窗口顯示一段特定的文本。如果沒有附加的調試器，該函數什么也不做。
更多閱讀：
內存泄漏是在原生開發中的一個很重要的問題，要檢測內存泄漏是一個很嚴峻的挑戰，尤其是在大型項目中。Vistual Studio可以提供檢測內存泄漏的報告，還有其他的一些應用程序（免費的或商業的）也可以幫助你檢測內存泄漏.有些情況下，在一些內存分配最終會導致泄漏時,可以使用調試器去中斷。但是你必須找到可再現的分配編號（盡管沒那么容易）。如果能做到這一點，執行程序時調試器才會中斷。
我們來看下面的代碼，分配了8個字節，卻一直沒釋放分配的內存。Visual Studio提供了造成內存泄漏的對象的報告，多運行幾次，會發現一直是同一個分配編號（341）。
void leak_some_memory(){ char* buffer = new char[8];}Dumping objects ->d:/marius/vc++/debuggingdemos/debuggingdemos.cpp(103) : {341} normal block at 0x00F71F38, 8 bytes long. Data: < > CD CD CD CD CD CD CD CD Object dump complete.在一個特定的（可復現的）位置中斷的步驟如下：
遵循這些步驟， 在上個例子中，使用分配的編號（341）就可以識別內存泄漏的起因。
調試和發布是兩個不同的目的。調試配置是用于開發的，而發布配置，顧名思義，是用來作為程序的最終版本，因為它必須嚴格遵循發布的質量要求，該配置包含優化部分和調試版本的中斷調試的設置。而且，有時候，要像調試調試版本一樣去調試發行版。要做到這一點，你需要在配置里做一些改變。但是這種情況下，你就不再是在調試發行版，而是調試和發行的混合版。
你還應該做一些事兒，以下是必須要做的：
如圖所示：
更多閱讀：怎樣調試發行版
另一個重要的調試就是遠程調試，這是一個更大的話題，多次被提到，這里我只做一下簡單的概括：
1) 本地的PDB文件必須可用（在遠程機器的相同路徑下放置一個對應的模塊）。
2) 遠程機器上的托管PDB文化必須可用。
遠程調試監控下載：
原文鏈接： Marius Bancila 翻譯： 伯樂在線 - JingerJoe
本文鏈接： http://m.survivalescaperooms.com/oooweb/p/10-more-visual-studio-debugging-tips.html
新聞熱點
疑難解答
