本文講述了 minidumps 是怎樣工作的、當你的程序崩潰的時候應該如何生成它們、以及如何在 Visual Studio .NET 中將它們重新讀入。

原文作者：Andy Pennell
中文翻譯：Victor
原文鏈接：http://www.codeproject.com/debug/postmortemdebug_standalone1.asp

如果你的程序在客戶的機器上崩潰了，那么你現在可以使用 minidumps 和 Microsoft Visual Studio .NET 調試器在事后進行調試。本文講述了 minidumps 是怎樣工作的、當你的程序崩潰的時候應該如何生成它們、以及如何在 Visual Studio .NET 中將它們重新讀入。微軟的錯誤報告程序之所以能夠改進 Windows 操作系統和諸如 Visual Studio .NET 這樣的應用程序的穩定性，其關鍵就在于 minidumps。本文也講述了如何使用 Microsoft 符號服務器自動地為系統組件查找符號。你在閱讀本文前應該已經熟悉 Win32 和 C++ 編程了。

• 什么是 Minidump？
• 創建一個 Minidump
• 與 Build 相關的問題
• 使用 MiniDumpWriteDump 寫一個 Minidump
• 使用 Visual Studio .NET 讀入一個 Minidump
• 微軟是如何使用 Minidumps 的
• 進一步改進
• 總結
• 附：版權及免責聲明

一個 minidump 就是一個文件，它包括了崩潰的應用程序中最重要的部分。它在用戶的機器上生成，然后用戶就可以將其提交給開發人員。開發人員可以裝入這個 dump，以便查找崩潰的原因，并發布一個補丁。

從早期的 Windows NT 開始，Dr.Watson 程序就能夠生成以 .dmp 為擴展名的崩潰 dump 文件。但是它們卻沒有想像中那樣有用，因為有兩個問題：

Minidumps 在設計時就使用了幾個方法用來解決上述問題：

• 只有幾個區域被保存下來，而不是整個進程空間。保存諸如 Kernel32.dll 這樣的模塊簡直毫無意義；只要給出了版本號，就可以很容易地從一張 Windows CD 上拿到這個文件。默認情況下，程序的內存堆是不保存的；不需要調試一個崩潰比率高得令人乍舌的崩潰點。當然，如果你想的話，還是可以把堆保存下來的。
• Minidump 生成代碼可以得到精確、完整的模塊信息，包括它們的名字、路徑、版本信息和內部時間戳。
• Minidump 生成代碼還可以得到線程列表，包括它們的上下文（也就是寄存器集合）和堆棧中的內容。
• 整個文件是壓縮的，進一步減小了大小。在 Windows XP 上，一個 Notepad 的 minidump 大概在 6K 左右，比上面提到的同一進程的崩潰 dump 小了將近 300 倍。

注意：Windows XP 在計算機停止響應后也會生成一種內核態的 minidumps，但是本文討論的是更常見的用戶態 minidumps。

有三種方法可以創建一個 minidump：

• 在你自己的應用程序中添加代碼，在遇到一個未捕獲的異常時寫 minidump。
• 在 Visual Studio .NET 的集成開發環境中調試程序，單擊“調試”菜單上的“將轉儲另存為”。
• 什么也不做。

方法一將在下文中詳細討論。

方法二僅適用于一個已經裝了調試器的工作站，很有可能只在開發團隊內才有用（例如：在另一個開發者或者測試人員的機器上）。如果你使用 Visual Studio .NET 對崩潰進行調試，那么你就可以這么做了。你可以保存一個 Minidump 或者一個包含堆的 Minidump。你不需要任何符號或者 PDB 文件就可以保存一個 dump 文件；但是在將它們重新讀入時你需要。

方法三只在 Windows XP 下有效，如果程序遇到了一個未捕獲的異常，并且沒有啟動 JIT 調試器，系統就會自動創建一個 minidump。然后，這個 minidump 將直接提交給 Microsoft，你就沒有機會查找崩潰的原因了。

為了使你的程序在崩潰時創建 dumps，你必須配置你的生成選項使其生成完整的調試信息，特別是在生成最終版的時候。生成 PDB 文件之后，你必須將你要發布給用戶的每一個二進制文件及其對應的 PDB 文件進行歸檔；之后在調試那些用戶提交的 minidumps 時你將需要這些 PDB 文件。

此外，確保你的二進制文件中包含正確的版本信息。你所發布的每一個組件的每一個版本都應該有一個不同的版本號，以便你能夠與 minidump 對應起來。版本字段（二進制資源中的版本信息——譯者注）可以幫你匹配這兩者。但調試器本身并不使用版本信息，它是基于 PE 文件頭內包含的內部時間戳來匹配二進制文件的。

輸出時，為最終版生成調試信息會有一些小的影響。會生成一個 PDB 文件，在生成所使用的機器上占用一些空間，而且最終生成的二進制文件會增大幾百個字節以便在 PE 文件中記錄調試目錄下的 PDB 文件名。你不應該向用戶發布 PDB 文件；這會使你的程序更容易地被用戶反向工程。

用來保存一個 minidump 的關鍵 API 是 MiniDumpWriteDump，它從 DbgHelp.dll 中導出，這是一個 Platform SDK 中可以再分發的 DLL。確保你使用的是 Windows XP 版本 5.1.2600；更早期的 beta 和 release candidate 版中的這個 API 有問題，并且 Windows 2000 中包含的 5.0.x 版中沒有導出這個函數。如果你有比 5.0 更早的版本，那么它一定是來自于 System Debugger package（包括 WinDbg 等工具），并且它是不可再分發的。

在調用這個 API 之前，你需要用 SetUnhandledExceptionFilter API 設置一個未捕獲異常的處理器（Unhandled Exception Handler，也就是 Top-level Exception Filter，最后一個異常過濾器——譯者注），以便能夠捕獲到崩潰點。這樣就可以使這個 Filter 函數在程序遇到未捕獲的異常的時候被調用。在某些未捕獲的異常中，比方說兩次堆棧溢出（double stack fault，即在處理 stack fault 的時候又發生了 stack fault——譯者注），操作系統會立即結束應用程序，既不會調用 filter、也不會啟動 JIT 調試器（據查，網上資料說如果發生了 triple fault，CPU 將會關閉，到時候除了 Reset 信號，就沒有什么能救得了這臺機器的了。所以可以認為 double fault 是非常嚴重的情況——譯者注）。

在你的 filter 函數中，你需要加載 DbgHelp.dll。這并不是調用 LoadLibrary 這么簡單；在 Windows 2000 系統中，你將會訪問到 System32 目錄下的那個不正確的版本。演示代碼試著從 EXE 文件所在的位置裝入這個庫。將正確版本的 DbgHelp.dll 放在 EXE 文件所在的目錄下；否則的話，代碼只好進行一次普通的 LoadLibrary 調用，這也就使得程序只能在 Windows XP 下工作。

裝入 DLL 后，它接著檢查導出函數名；如果正確的話，它會用合適的名字創建一個文件，比方說用程序名加 .dmp 后綴保存在臨時目錄中。這個文件句柄接著會傳遞給 API，并附上一些其它的信息，諸如進程 ID 和所需的 dump 文件類型等。例子中使用的是 MiniDumpNormal。也許你想使用 MiniDumpWithDataSegs 標志位，也就是相當于 Visual Studio 調試器中的“附帶堆信息的小型轉儲”選項，這顯然會使 dump 文件變得更大。

在 .dmp 文件創建完成后，程序會詢問用戶將其保存在什么位置。然后用戶就可以通過 e-mail 或者使用 FTP 將文件發送過來供你分析。

如果你想使用本文所提供的演示代碼的話，就在你的工程中加入 mdump.h 和 mdump.cpp 文件，并聲明一個全局的 MiniDumper 對象。這個對象的構造函數需要一個參數，也就是 minidump 文件的基礎文件名。為了能夠正常運行，你還需要把正確的 DbgHelp.dll 放在 EXE 所在的目錄下。

不能使用調試器調試寫 minidump 的那段代碼（在演示代碼中，也就是 Minidumper::TopLevelFilter）。如果進程附加了一個調試器，那么未捕獲異常的處理函數將永遠不會被調用（關于這一點，MSDN 中關于結構化異常處理的文檔說得很清楚：調試器有兩次機會處理一個異常，一次是在異常剛剛發生時，也就是 VC6 經常報出來的“First-chance exception”；還有一次是在執行了所有的 filter，發現沒有一個能夠處理之后，通知調試器發生了一個“Second-chance exception”，此時調試器會中斷程序并進入調試模式，因為絕大多數情況下這就屬于未捕獲的異常，是程序 BUG，在非調試環境下是要崩潰的——譯者注）。如果你遇到了問題需要調試的話，你需要使用 MessageBox 調試。

文章的這一部分使用了一個例子，在 Windows 2000 系統下手工創建了 Notepad 的一個 minidump，然后在 Windows XP 系統下調試。

啟動 Visual Studio .NET，單擊“文件”菜單上的“打開解決方案”，在“文件類型”下拉列表框中選擇“轉儲文件(*.dmp; *.mdmp)”（555~~~為什么我在 Visual Studio .NET 2003 中找不到這一項……不過還好，可以直接雙擊 .dmp 文件打開——譯者注），找到 minidump 文件，然后點擊“打開”創建一個缺省工程。

按 F5 在調試器中啟動這個 dump，這一步將為你開始調試提供一些信息。調試器將創建一個假的進程；在輸出窗口中顯示了很多模塊加載的消息。此時調試器僅僅是在重建崩潰時的進程狀態。在顯示了一條 EXE 不包含調試信息的警告消息之后，調試器停在了用戶崩潰的地方，諸如一個非法訪問什么的。這時候如果你查看調用棧窗口，你會發現缺少符號和很多有用的信息。

為了讀取一個 minidump，你通常需要相關的二進制拷貝。為了找到正確的二進制文件，打開模塊窗口。

圖 2 展示了 Notepad 的例子，并且說明了兩個情況。首先，二進制所在的路徑名前標上了一個星號，這表示這些是在用戶機器上的模塊路徑，但是在本地卻找不到對應的二進制文件。其次，在“Information”一列中全都寫著“No matching binary found”。找到對應的二進制文件的關鍵是注意“Version”字段和文件名。在這個例子中，大多數系統文件的版本號都是 2195，也就是 Windows 2000。雖然無法從這些信息上立即得知確切的 service pack (SP) 或者 quality fix engineering (QFE)，但這些信息可以從微軟的 DLL 幫助數據庫中查詢到：http://support.microsoft.com/servicedesks/fileversion/dllinfo.asp。

現在，你需要找到一張 Windows 操作系統的 CD 或者已經安裝了正確版本的機器，然后將所需要的文件復制到一個目錄。通常情況下沒有必要把進程中每個模塊的二進制文件都找出來，但是找出那些在每個調用棧上的關鍵模塊是很重要的。這通常包括操作系統的二進制文件（例如 Kernel32.dll）和你自己的二進制模塊（在這個例子中就是 Notepad.exe）。

在你找到這些二進制文件、并把它們拷貝到一個本地目錄之后，單擊“調試”菜單中的“停止調試”命令。然后在解決方案資源管理器中，右鍵單擊工程圖標，在快捷菜單上單擊“屬性”，你將看到“調試”屬性頁。在“命令參數”中填入“MODPATH”，跟上一個等號，然后輸入二進制文件所在的位置，如果有多個位置，可以用分號分隔。在這個例子中，它是：

在設置好了路徑之后，按 F5 重新裝入 minidump，MODPATH 的值將通過命令行參數傳遞給調試器；在 Visual Studio .NET 的后續版本中應該會有更方便的方法設置這個參數，或許可以作為一個選項出現在屬性對話框中。

盡管找到二進制文件并不太可能改善調用棧窗口的情況，但是它卻能解決模塊窗口中的問題，如圖 3 所示：

它現在顯示的不再是“No matching binary found”，而是“Cannot find or open a required DBG file”（我怎么覺得這個地方的英文語法應該用“nor”而不是“or”……呵呵，不管它了，反正微軟程序中無傷大雅的語法錯誤已經不是第一次被發現了——譯者注）和“No symbols loaded”。前一條消息出現在那些使用 DBG 文件存儲調試信息的系統 DLL 上，后一條消息則出現在使用 PDB 文件的 DLL 上。找到對應的二進制文件并不能使你看到調用棧；你還需要找到它們對應的調試信息。

微軟使用 minidumps 改進其程序的歷史已經有一年多了（本文發布于 2002 年 3 月 7 日——譯者注）。Microsoft Internet Explorer 5.5 和 Microsoft Office XP 是第一批與新版的 Dr.Watson 同時發布的產品。這個新版的 Dr.Watson 可以在程序停止響應時捕獲程序中未處理的異常，創建一個 minidump，然后詢問用戶是否愿意將信息提交給微軟。

在服務器端，可以根據發生崩潰的組件和崩潰點對 minidumps 進行分析和歸類，這樣就可以使產品組得到程序的崩潰頻率、以及某個崩潰情況的發生頻率，小組也可以得到崩潰時的 minidumps 以便日后分析。在某些情況下，如果崩潰的原因已經完全查明，則用戶可以被引導到一個網頁，這個頁面上有已知的、可以暫時避免這種崩潰的方法，或者一個解決該問題的補丁。在 Internet Explorer 5.5 和 Office XP 發布后，有很多其他產品組已經開始使用類似的技術收集崩潰信息了。它同時也是 Windows XP 的一個標準部分。

本文中討論的例子主要是用來理解 minidumps 的，沒有涉及到如何從用戶機器上返回 dump 文件（在 CodeProject 還有一篇文章是專門講這個處理過程的，也就是著名的 BT 客戶端軟件 BitComet 所使用的崩潰信息報告程序 XCrashReport——譯者注）。在最簡單的情況下，可以提示用戶使用 e-mail 發送 minidump 文件。但是要注意，這可能會帶來隱私方面的問題，因為用戶數據也許就存儲在于堆棧中，對于一個包含完整堆信息的 minidump 來說，則一定會有用戶數據在其中，這一點要讓用戶清楚。微軟的 Data Collection Policy 中有一些額外的信息用來說明 minidumps 所包含的所有詳細內容，它位于：http://watson.microsoft.com/dw/1033/dcp.asp。

另外，如果在一個 Windows 服務中遇到了未處理的異常，那么為它創建 minidumps 將是另一個挑戰。你需要處理桌面訪問（例如，如果沒有人在使用控制臺，那么你就無法提示他們）以及安全上下文。

Minidumps 是一種新技術，它使得程序在用戶的機器上崩潰后也可以進行事后調試。向已有的程序中加入代碼、使其在遇到未捕獲的異常時自動創建 minidumps 也是一件很容易的事。Visual Studio .NET 可以很容易地載入它們，從而重現崩潰現場、使得開發人員可以調試程序。符號服務器可以很輕松地找到系統符號文件，幫助分析。