http://blog.sina.com.cn/s/blog_48f93b530100fsln.html
在Windows平臺下用C++開發(fā)應(yīng)用程序，最不想見到的情況恐怕就是程序崩潰，而要想解決引起問題的bug，最困難的應(yīng)該就是調(diào)試release版本了。因?yàn)閞elease版本來就少了很多調(diào)試信息，更何況一般都是發(fā)布出去由用戶使用，crash的現(xiàn)場很難保留和重現(xiàn)。本文將給出幾個解決方案，完成對release版應(yīng)用程序crash錯誤的調(diào)試。（本文只討論Windows平臺MSVC環(huán)境下的調(diào)試，對于其他平臺和開發(fā)環(huán)境沒有關(guān)注，請大家自己借鑒和嘗試。）
方案一：崩潰地址 + MAP文件
這種方案只能對VC7以前的版本開發(fā)的程序使用。
1、崩潰地址
所謂崩潰地址就是引起程序崩潰的內(nèi)存地址，在WinXP下應(yīng)用程序crash的對話框如下圖：
上面第2張圖中畫紅線的值為crash的代碼偏移地址，第3張圖為即crash絕對地址；一般引起crash的原因多為內(nèi)存操作錯誤，我們用這兩個地址和MAP文件就能定位出錯的代碼行。
2、MAP文件
MAP文件是記錄應(yīng)用程序信息的文件（文本文件），里面大概包含了程序的全局符號、源碼模塊名、源碼文件和行號等信息，而這些信息能夠幫助我們定位出錯的代碼行。
怎樣生成MAP文件呢？以VC6為例，在 Project Settings -> C/C++ -> Debug info中，選擇 Line Numbers Only ；在 Project Settings -> Link 中，選擇 Generate mapfile項(xiàng)，并在Project Options 里面輸入 /MAPINFO:LINES 和 /MAPINFO:EXPORTS，重新編譯程序就會生成.map文件。
以上設(shè)置對應(yīng)的編譯鏈接選項(xiàng)分別分：
/Zi — 表示生成pdb調(diào)試信息；
/MAP[:filename] — 表示生成map文件名；
/MAPINFO:EXPORTS — 表示生成的map文件中加入exported functions（生成DLL文件時）；
/MAPINFO:LINES — 表示生成的map文件中加入代碼行信息。
由于/MAPINFO:LINES選項(xiàng)在VC8以后的版本中不再支持，因此通過MAP文件中的信息和crash地址定位出錯代碼行就比較困難了，所以這種方案只能在VC7及以前的版本中使用。
一個MAP文件片段示例如下：
圖中Rva+Base列的地址為該行函數(shù)對應(yīng)的函數(shù)絕對地址，Address列中冒號后面的地址為函數(shù)相對偏移地址。
3、定位crash代碼
有了上面的介紹，定位crash代碼就很簡單了。用下面的公式來進(jìn)行定位：
崩潰行偏移 = 崩潰地址 - 崩潰函數(shù)絕對地址 + 函數(shù)相對偏移
我們首先根據(jù)崩潰地址（絕對地址），按照找到第2張圖中Rva+Base列的地址找到發(fā)生崩潰的函數(shù)（即崩潰地址大于該函數(shù)行的Rva+Base地址且小于下個函數(shù)的地址），然后找到該行對應(yīng)的函數(shù)相對偏移地址，帶入公式中，就得到了崩潰行偏移，該值表示崩潰行的代碼相對于代碼所在函數(shù)的偏移量。用該值去與第3張圖中對應(yīng)函數(shù)冒號后面的偏移量去比較，最接近的值前面的那個十進(jìn)制數(shù)即為代碼所在函數(shù)中的行號。
ok，到此我們已經(jīng)成功找到了崩潰的代碼行，只不過這種方法還是比較費(fèi)力，并且限制比較多，我們看看下面的方案。
上篇給出的方案一還要補(bǔ)充幾句。通過“crash地址 + MAP文件”來定位出錯代碼位置雖然需要經(jīng)過比較復(fù)雜的地址計(jì)算，但卻是最簡單實(shí)現(xiàn)的方式。如果僅僅想通過崩潰地址定位出錯的函數(shù)，就更加方便了。我在網(wǎng)上找到一個解析MAP文件的小工具，可以非常清晰的列出每個函數(shù)的地址，并且可以將分析表格導(dǎo)出為Excel文件。工具下載地址：http://e.ys168.com/?tinyfun，工具目錄下VCMapper.exe。
另外上篇主要參考兩篇文章：
http://www.vckbase.com/document/viewdoc/?id=908
http://www.vckbase.com/document/viewdoc/?id=1473
方案二：崩潰地址 + MAP文件 + COD文件
由于VC8以后的版本都不再支持MAP文件中產(chǎn)生代碼行信息，因此我們尋找另一種定位方式：COD文件。
1、COD文件
COD文件是一個包含了匯編碼、二進(jìn)制機(jī)器碼和源代碼對應(yīng)信息的文件，每一個cpp都對應(yīng)一個COD文件。通過這個文件，我們可以非常方便地進(jìn)行定位。
在VC6中生成COD文件的設(shè)置方式為：Project Settings -> C/C++，在 Category 中選 Listing Files，在 Listing file type 組合框中選 Assembly，Machine code，and source。在VC8中生成COD文件的設(shè)置方式為：Project Properties -> C/C++ -> Output Files -> Assembler Output 項(xiàng)，選擇 Assembly，Machine code，and Source(/Facs)。
2、定位崩潰行
下面通過舉例進(jìn)行說明。現(xiàn)在我有一個基于對話框的MFC應(yīng)用程序CrashTest，在CCrashTestDlg::OnInitDialog函數(shù)中寫入導(dǎo)致crash的代碼語句（第99行），源文件如下：
根據(jù)崩潰地址（0x004012A3）以及MAP文件（定位片段圖片如下），定位crash函數(shù)為OnInitDialog；并且我們可以很容易地計(jì)算出崩潰地址相對于崩潰函數(shù)的偏移量為 0x004012A3 - 0x004011E0 = 0xC3。
再來看看CrashTestDlg.cod文件，我們根據(jù)文件中源碼信息找到OnInitDialog函數(shù)信息片段：
可以看到圖片中第一行為OnInitDialog函數(shù)匯編代碼的起始行；找到“int * p = NULL;”這一句源碼，其前面的98表示這行代碼在源文件中的行號，下面的000c1表示相對于函數(shù)開始位置的偏移量，后面的“33 c0”為機(jī)器碼，“xor eax，eax”為匯編碼。那么我們根據(jù)前面算出來的偏移量0xC3，找到對應(yīng)出錯的語句為99行：“*p = 5;”。
總結(jié)一下定位步驟：
1) 根據(jù)公式 崩潰語句在函數(shù)中偏移地址 = 崩潰地址 - 崩潰函數(shù)地址 計(jì)算出偏移量X；
2) 根據(jù)公式 崩潰語句在COD文件中地址 = 崩潰函數(shù)在COD文件中地址 + X 計(jì)算出地址Y。其中崩潰函數(shù)在COD文件中地址為COD文件中函數(shù)起始括號“{”后面表明的地址，一般情況下為0x0000；
3) 根據(jù)Y在COD文件中找到對應(yīng)代碼行。
ok，方案二介紹完了。這種方法最大的好處是沒有VC開發(fā)環(huán)境版本限制，而且COD文件里面包含的信息更加豐富，不但可以幫助我們定位crash，還能幫我們分析很多東西。當(dāng)然，這也導(dǎo)致編譯生成了很多信息文件。
根據(jù)前面兩篇博文，我們要定位崩潰行代碼，必須要自己根據(jù)相關(guān)信息文件進(jìn)行計(jì)算。如果需要處理的量比較大，恐怕會很費(fèi)力氣。有沒有更簡單快速的辦法呢？
最直接的想法就是寫一個小工具，根據(jù)規(guī)則和信息進(jìn)行自動定位，不過開發(fā)起來也是要費(fèi)一番功夫的。令人開心的是，我們可以找到類似的工具，而且是開源免費(fèi)的！程序員的世界也許很多時候都是這么單純而樂于分享！
方案三：崩潰地址 + PDB文件 + CrashFinder
CrashFinder是一個開源工具，作者是John Robbin，大家可以去他的blog上去找關(guān)于CrashFinder的信息。我們這里以CrashFinder2.5版本為例介紹，相關(guān)文章鏈接為：http://www.wintellect.com/CS/blogs/jrobbins/archive/2006/04/19/crashfinder-returns.aspx
1、PDB文件
PDB（Program Database）文件中包含了exe程序所有的調(diào)試相關(guān)信息，具體可以查閱MSDN。當(dāng)編譯選項(xiàng)設(shè)置為/Zi，鏈接選項(xiàng)設(shè)置為/DEBUG，/OPT:REF時，就會生成工程的.pdb文件。具體到VC2005中，就是 Project Propertise -> C/C++ -> General -> Debug Information Format 項(xiàng)設(shè)置為 Program Database（/Zi），Linker -> Debugging -> Generate Debug Info 項(xiàng)設(shè)置為 Yes（/Debug），Linker -> Optimization -> References 項(xiàng)設(shè)置為 Eliminate Unreferenced Data（/OPT:REF）。
只要設(shè)置以上選項(xiàng)，release版本也能生成PDB文件。當(dāng)然，對應(yīng)的應(yīng)用程序也會稍大。
2、CrashFinder
CrashFinder能夠運(yùn)行需要兩個條件：一是系統(tǒng)必須要有dbghelp.dll文件；二是PDB文件必須與exe文件在一個路徑下。對于dbghelp.dll，一般在系統(tǒng)system32路徑下都有，如果沒有下載一個放到這個目錄下就可以了。
先看一下CrashFinder的界面。
用起來也非常簡單。首先選擇File->New或點(diǎn)擊工具欄新建按鈕，選擇要調(diào)試的exe文件打開，會發(fā)現(xiàn)exe及所依賴的dll文件信息都已經(jīng)加載進(jìn)來。在下半部分的編輯框中輸入崩潰地址（16進(jìn)制），點(diǎn)右邊的“Find”按鈕，就會在下面顯示崩潰的源文件路徑、名稱以及崩潰所在行號了，如下圖所示。
用CrashFinder進(jìn)行crash定位真的非常方便。但是我在使用過程中發(fā)現(xiàn)了一個bug，每次啟動程序后，直接新建的話加載進(jìn)來的exe模塊都顯示叉，提示找不到debug symbols。但是用打開按鈕隨便打開一個文件失敗后，再新建就能成功。猜測可能是直接新建，定位PDB文件時的路徑不對引起的。有源碼，但是懶的看了呵呵，大家感興趣可以試一下。
好了，方案三就介紹到這里，后面還有更加強(qiáng)大的方案 : )
前面幾個方案都是直接定位crash的代碼位置，但是在比較大型的程序中，只知道這個信息還是遠(yuǎn)遠(yuǎn)不夠的，我們希望知道更多關(guān)于調(diào)用函數(shù)順序及變量值等信息，也就是crash時調(diào)用堆棧信息。
方案四：SetUnhandledExceptionFilter + StackWalker
這個方案需要自己動手往工程里添加代碼了。要實(shí)現(xiàn)上面的想法，需要做兩件事情：1、需要在crash時有機(jī)會對程序堆棧進(jìn)行處理；2、對堆棧信息進(jìn)行收集。
1、SetUnhandleExceptionFilter函數(shù)
Windows平臺下的C++程序異常通常可分為兩種：結(jié)構(gòu)化異常（Structured Exception，可以理解為與操作系統(tǒng)相關(guān)的異常）和C++異常。對于結(jié)構(gòu)化異常處理（SEH），可以找到很多資料，在此不細(xì)說。對于crash錯誤，一般由未被正常捕獲的異常引起，Windows操作系統(tǒng)提供了一個API函數(shù)可以在程序crash之前有機(jī)會處理這些異常，就是SetUnhandleExceptionFilter函數(shù)。（C++也有一個類似函數(shù)set_terminate可以處理未被捕獲的C++異常。）
SetUnhandleExceptionFilter函數(shù)聲明如下：
LPTOP_LEVEL_EXCEPTION_FILTER WINAPI SetUnhandledExceptionFilter(
__in LPTOP_LEVEL_EXCEPTION_FILTER lpTopLevelExceptionFilter
);
其中 LPTOP_LEVEL_EXCEPTION_FILTER 定義如下：
typedef LONG (WINAPI *PTOP_LEVEL_EXCEPTION_FILTER)(
__in struct _EXCEPTION_POINTERS *ExceptionInfo
);
typedef PTOP_LEVEL_EXCEPTION_FILTER LPTOP_LEVEL_EXCEPTION_FILTER;
簡單來說，SetUnhandleExceptionFilter允許我們設(shè)置一個自己的函數(shù)作為全局SEH過濾函數(shù)，當(dāng)程序crash前會調(diào)用我們的函數(shù)進(jìn)行處理。我們可以利用的是 _EXCEPTION_POINTERS 結(jié)構(gòu)類型的變量ExceptionInfo，它包含了對異常的描述以及發(fā)生異常的線程狀態(tài)，過濾函數(shù)可以通過返回不同的值來讓系統(tǒng)繼續(xù)運(yùn)行或退出應(yīng)用程序。
關(guān)于 SetUnhandleExceptionFilter 函數(shù)的具體用法和示例請參考MSDN。
2、StackWalker
現(xiàn)在我們已經(jīng)有機(jī)會可以在crash之前對程序狀態(tài)信息進(jìn)行處理了，只需要生成并保存堆棧信息就大功告成了。Windows的dbghelp.dll庫提供了一個函數(shù)可以得到當(dāng)前堆棧信息：StackWalk64（在Win2K以前版本中為StackWalk）。該函數(shù)聲明如下：
BOOL WINAPI StackWalk64(
__in DWORD MachineType,
__in HANDLE hProcess,
__in HANDLE hThread,
__in_out LPSTACKFRAME64 StackFrame,
__in_out PVOID ContextRecord,
__in PREAD_PROCESS_MEMORY_ROUTINE64 ReadMemoryRoutine,
__in PFUNCTION_TABLE_ACCESS_ROUTINE64 FunctionTableAccessRoutine,
__in PGET_MODULE_BASE_ROUTINE64 GetModuleBaseRoutine,
__in PTRANSLATE_ADDRESS_ROUTINE64 TranslateAddress
);
該函數(shù)的具體用法可以參考MSDN。在這里推薦一個牛人寫好的StackWalker，可以直接拿來用，開源的。StackWalker提供了一個基類，給出了幾個簡單的接口，可以方便地生成堆棧信息，并且支持一系列VC版本，非常好用。我們可以自己寫一個子類，并重載虛函數(shù)OnOutput，就可以將堆棧信息輸出為特定格式了。StackWalker的地址為：http://www.codeproject.com/KB/threads/StackWalker.aspx。
不過對于Release版本來說，StackWalk64函數(shù)獲得的堆棧信息有可能不完整。如果異常是由MFC的模塊拋出，那么獲得的堆棧可能缺少前面調(diào)用模塊信息。另外，StackWalk64需要最新的dbghelp.dll文件支持才能工作；要正確輸出crash的函數(shù)名和行號，需要要pdb文件支持。以上不足有可能影響輸出信息的完整性和效果，而對于發(fā)布在外的程序，要帶上pdb文件幾乎不可能，因此這個方案還是有缺憾的，比較適用于本地的release版本調(diào)試。
下一篇我們將介紹一個更加完善的解決方案
當(dāng)我們把自己的release版本程序發(fā)布出去以后，一般都是在用戶的機(jī)器上運(yùn)行。這種情況下，對于第四種方案，因?yàn)樾枰猵db文件才能夠正確生成堆棧調(diào)用的函數(shù)行號及代碼行號，因此方案四只適用于本地release版的調(diào)試，否則只能生成不完整的堆棧信息。對于前三種方案，其實(shí)只需要用戶告知崩潰地址，然后在本地查找crash地址就可以了，但是定位crash的過程非常不方便，如果crash的情況比較多，前三種方案都不合適。而且，前三種方案均不能生成堆棧調(diào)用信息，對于debug的作用有限。
下面我們就來看一個更加完善的解決方案。
方案五：SetUnhandledExceptionFilter + Minidump
SetUnhandleExceptionFilter函數(shù)我們已經(jīng)介紹過了，本方案的思路還是要利用我們自己的異常處理函數(shù)，來生成minidump文件。
1、Minidump概念
minidump（小存儲器轉(zhuǎn)儲）可以理解為一個dump文件，里面記錄了能夠幫助調(diào)試crash的最小有用信息。實(shí)際上，如果你在 系統(tǒng)屬性 -> 高級 -> 啟動和故障恢復(fù) -> 設(shè)置 -> 寫入調(diào)試信息 中選擇“小內(nèi)存轉(zhuǎn)儲(64 KB)”的話，當(dāng)系統(tǒng)意外停止時都會在C:\Windows\Minidump\路徑下生成一個.dmp后綴的文件，這個文件就是minidump文件，只不過這個是內(nèi)核態(tài)的minidump。
我們要生成的是用戶態(tài)的minidump，文件中包含了程序運(yùn)行的模塊信息、線程信息、堆棧調(diào)用信息等。而且為了符合其mini的特性，dump文件是壓縮過的。
2、生成minidump文件
生成minidump文件的API函數(shù)是MiniDumpWriteDump，該函數(shù)需要dbghelp.lib支持，其原型如下:
BOOL WINAPI MiniDumpWriteDump(
__in HANDLE hProcess,
__in DWORD ProcessId,
__in HANDLE hFile,
__in MINIDUMP_TYPE DumpType,
__in PMINIDUMP_EXCEPTION_INFORMATION ExceptionParam,
__in PMINIDUMP_USER_STREAM_INFORMATION UserStreamParam,
__in PMINIDUMP_CALLBACK_INFORMATION CallbackParam
);
在我們的異常處理函數(shù)中加入以下代碼：
HANDLE hFile = ::CreateFile( _T("E:\\dumpfile.dmp"), GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
if( hFile != INVALID_HANDLE_VALUE)
{
MINIDUMP_EXCEPTION_INFORMATION einfo;
einfo.ThreadId = ::GetCurrentThreadId();
einfo.ExceptionPointers = pExInfo;
einfo.ClientPointers = FALSE;
::MiniDumpWriteDump(::GetCurrentProcess(), ::GetCurrentProcessId(), hFile, MiniDumpNormal, &einfo, NULL, NULL);
::CloseHandle(hFile);
}
其中，pExInfo變量為異常處理函數(shù)PEXCEPTION_POINTERS類型的參數(shù)。具體請參考MSDN。
3、調(diào)試minidump
調(diào)試dump文件首先需要pdb文件，因此我們build程序時需要設(shè)置 Debug Infomation Format 為 “Program Database（/Zi）”。其次，我們還要確保所用的dump文件與源代碼、exe、pdb文件版本是一致的，這要求我們必須維護(hù)好程序版本信息。
調(diào)試minidump最方便的環(huán)境就是VS了，我們只要將.dmp、.exe、.pdb文件放在一個路徑下，保證源代碼文件的路徑與編譯時的路徑一致就可以了，剩下的就是VS幫我們完成。雙擊.dmp文件或者在文件打開工程中選擇“dump files”，加載dump文件，然后按F5運(yùn)行就能直接恢復(fù)crash時的現(xiàn)場了，你可以定位crash的代碼，可以查看調(diào)用堆棧，可以查看線程和模塊信息...一切都跟你設(shè)置斷點(diǎn)調(diào)試一樣，太強(qiáng)大了！看個截圖吧。
需要注意的是，對于release版的程序來說，很多代碼是經(jīng)過編譯器優(yōu)化過的，因此定位的時候可能會有所偏差，大家可以考慮設(shè)置選項(xiàng)去掉代碼優(yōu)化。
其他可以調(diào)試minidump的工具還有WinDbg等，大家可以查閱相關(guān)資料。
本文主要參考了這篇文章：http://vicchina.51.net/research/other/seh/minidumps/intro.htm。
下一篇，我們將給出一個調(diào)試release發(fā)布程序的完美解決方案，適合用戶量較大的應(yīng)用發(fā)布程序的調(diào)試。
上一篇我們已經(jīng)給出了方案，能夠非常方便的通過dump文件對crash錯誤進(jìn)行調(diào)試和定位；從整個流程上看還差最后一步，即怎樣拿到crash時產(chǎn)生的dump文件。如果可以讓用戶把文件發(fā)送過來自然不錯，但對于類似免費(fèi)共享軟件等在互聯(lián)網(wǎng)上發(fā)布的程序呢？我們的用戶是不確定的，而且用戶量有可能非常大，即使我們能想辦法聯(lián)系到用戶，總不能挨個去收集crash信息吧。
我們需要一種方案，能夠提供crash信息匯報功能。
我們可以架設(shè)一臺服務(wù)器專門進(jìn)行信息收集，只要客戶端在crash時正確匯報即可，但是相應(yīng)的維護(hù)成本和開發(fā)難度也不可忽視。有沒有更簡單的方法呢？還記得我的博文“為程序添加自動發(fā)送Email功能”嗎？這就是簡單有效的方法！
方案六：minidump + email
我們只需要在異常處理時，先生成minidump信息文件，再用email方式將文件發(fā)送到指定郵箱就行了。剩下的就是我們每天查看郵箱，提取dump文件進(jìn)行調(diào)試了。
1、Email功能
首先我們來看一下email發(fā)送都需要哪些相關(guān)信息。
a、發(fā)送端郵箱帳戶；
b、接收端郵箱帳戶；
c、email標(biāo)題，一般應(yīng)有軟件名稱及版本信息；
d、email正文，一般應(yīng)有簡單的crash信息提示，以區(qū)別不同原因造成的crash；
e、email附件，當(dāng)然就是我們的dump文件了，還可以加上軟件生成的log文件等。
當(dāng)然，對于標(biāo)題應(yīng)該盡量多加一些信息區(qū)別引起crash的原因，比如將crash的地址信息加到標(biāo)題中；因?yàn)楫?dāng)每天有成百上千的crash匯報上來，重復(fù)的crash占大多數(shù)，把時間都花在區(qū)分它們身上有點(diǎn)太浪費(fèi)。由此看來，前面方案中提到的StackWalker還是有些用處的，我們可以用它來生成一些crash的文字描述信息，寫到標(biāo)題或正文中去。
dump文件的大小是否適合作為郵件的附件呢？實(shí)際上minidump產(chǎn)生的文件一般在幾K到幾十K之間，作為email的附件沒有任何問題。
關(guān)于發(fā)送email相關(guān)技術(shù)細(xì)節(jié)，已經(jīng)在“為程序添加自動發(fā)送Email功能”文中介紹了，大家可以參考。其實(shí)，對接受郵箱中郵件的處理還是很費(fèi)時費(fèi)力的，大家可以考慮寫一些腳本將處理流程自動化，提高效率。
2、google breakpad
google breakpad是一個開源的跨平臺crash report系統(tǒng)，光從開源和跨平臺這兩個特點(diǎn)上來看，它就足以稱的上是一個完善而有效的工具了。其實(shí)，breakpad在整個crash report層次上給出了一個系統(tǒng)級的解決方案，也就是說它幾乎能適應(yīng)各種軟件、各種平臺的應(yīng)用要求。
breakpad的整體思路跟上面介紹的方案是相似的，只不過最后提交dump文件的方式更加完善。大家有興趣可以去它的官方網(wǎng)址查閱相關(guān)資料：http://code.google.com/p/google-breakpad/。
ok，關(guān)于調(diào)試release發(fā)布程序的crash錯誤系列文章就寫完了。這幾篇文章給出的方案由簡單到復(fù)雜，由簡陋到完善，對crash調(diào)試有了一個比較全面的總結(jié)。當(dāng)然，其中涉及到的概念和技術(shù)還很多，需要我們?nèi)ゲ粩鄬W(xué)習(xí)和領(lǐng)悟，也希望大家能夠互相交流。