想準備使用WindDbg來解決Windows 7系統崩潰，需要壹臺個人電腦滿足下列要求：
32位或64位Windows 7/Vista/XP或Windows Server 2008/2003
約25MB的硬盤空間(這不包括存儲轉儲文件或符號文件的空間)
正常的互聯網連接
微軟Internet Explorer 5.0或更高版本
WinDBG的最新版本是Windows SDK中的壹個選項。SDK下載文件名為winsdk web.exe，大小498KB，可以免費下載。(註意：安裝調試器後，可以刪除龐大的下載文件，從而騰出大量空間。)
內存轉儲(頁面文件必須在C：上，以便Windows保存內存轉儲文件)
安裝WinDbg
下載Windows SDK、運行安裝向導程序後，選擇Common Utilities(常用實用程序)下面的Debugging Tools for Windows(Windows調試工具)選項。
配置啟動和恢復
這壹步很煩人。因為不太容易找到啟動和恢復對話框;為了檢查系統已設定成在錯誤檢查期間采取合適的動作，包括要不要自動重新啟動、保存多少大小的轉儲文件，需要這個對話框。
找到啟動和恢復對話框：
1、選擇屏幕左下角的Start(開始)按鈕
2、選擇Control Panel(控制面板)
3、選擇System and Security(系統和安全)
4、從右邊欄的選項中選擇System(系統)
5、從左邊欄中選擇Advanced system settings(高級系統設置)，顯示SystemProperties(系統屬性)對話框
6、在系統屬性對話框中選擇Advanced(高級)選項卡
7、在啟動和恢復區中選擇Settings(設置)按鈕
看到如下所示的啟動和恢復對話框：
確保啟動和恢復設置是否正確
在System failure(系統故障)下
1、勾選Write an event to the system log(將事件寫入系統日誌)
2、勾選Automatically restart(自動重新啟動)
3、選擇Kernel memory dump(核心內存轉儲)
4、確保轉儲文件寫入%SystemRoot%\MEMORY.DMP
5、勾選Overwrite any existing file(覆蓋任何現有文件)，以節省硬盤空間
請註意：這將意味著妳的系統將既保存內核轉儲文件，又保存微型轉儲文件。然而，盡管妳有壹個微型轉儲用於每個事件，但保存的將是最近壹個內核轉儲。
配置WinDbg
啟動調試器：想啟動WinDbg，請依次選擇下列：
Start | All Programs | Debugging Tools for Windows| WinDbg
開始|所有程序| Windows調試工具|WinDbg
如果妳要隨時使用WindDbg，需要簡化這個程序的啟動：只要把它固定到Startup(啟動)菜單上，或者發送快捷方式到桌面上。
符號有多重要？
在妳想找到轉儲文件中的某個異常模塊、急於挽救局面之前，得確保調試器已準備就緒。最重要的是，妳得確信它會為妳在排除故障的那個操作系統的確切版本找到符號文件。
符號表是編譯後的產物。當某個程序被編譯後，源代碼從壹種高級語言轉換成了機器碼。與此同時，編譯器會創建壹個符號文件，帶有標識符列表、標識符在程序中的位置及其屬性。壹些標識符是全局和局部變量以及函數調用。程序不需要這些信息才能執行。因而，信息可以取出來存儲在另壹個文件中，減小了最終可執行文件的大小。
與較大的可執行文件相比，較小的可執行文件占用磁盤空間較少，加載到內存的速度較快。但凡事都有另壹面：某程序引起問題時，操作系統只知道出現問題的十六進制地址。妳需要比這更多的信息，才能確定哪個程序在使用該內存空間，它試圖在進行什麽操作。Windows符號表就能解答這個問題，而可以訪問針對特定系統內存的符號好比將地名加在地圖上。反過來，分析符號表錯誤的轉儲文件好比拿著壹張波士頓的地圖在舊金山找路。
配置WinDbg以定位符號
Windows有數量多得驚人的符號表文件。之所以這樣，是因為操作系統的每個版本，甚至壹次性版本，都會帶來壹個新文件。幸運的是，WinDbg可以為妳處理這件事，但必須為它配置正確的搜索路徑。要做到這壹點，就要啟動WinDbg，並依次選擇下列：
File | Symbol file path
文件|符號文件路徑
請註意：星號之間的地址表明妳想把符號存儲在何處，以便將來訪問。比如說，我把符號存儲在C：驅動器根目錄下壹個名為symbols的文件夾中，
打開內存轉儲時，WinDbg會查看可執行文件(.exe和.dll等文件)，並提取版本信息。然後它會請求微軟的符號服務器，該服務器包含該版本信息，並找到確切的符號表，從中獲取信息。它不會下載妳在排除故障的特定操作系統的所有符號，只會下載需要的符號。另外，妳可以選擇從微軟下載並存儲完整的符號文件。然而，對於妳在分析的操作系統的每個版本而言，這個文件的大小在600MB到800MB之間。相比之下，WinDbg下載的文件不到100MB，即可分析測試機上操作系統的好幾個版本。即使如今硬盤成本很低，節省的空間還是相當大。
關於轉儲文件
內存轉儲文件是壹份快照，表明了系統崩潰時內存裏面有什麽。雖然內存轉儲文件也許是妳可能需要查看的最乏味、最不直觀的東西，但操作系統崩潰時，它是妳最好的朋友。Windows創建了三種不同大小的內存轉儲：微型轉儲(minidump)、內核轉儲(kernel dump)和完全轉儲(full dump)。
1、小型轉儲或微型轉儲
Windows 7微型轉儲只有256K字節，不管從哪個標準來看都很小;然而，它們比Windows 2000/XP時候大了不少，那時候只有64K。微型轉儲之所以這麽小，原因之壹是，它們不含有故障出現時，內存中的任何二進制文件或可執行文件。不過，那些文件對調試器在之後進行分析來說至關重要。只要妳在創建轉儲文件的機器上調試，WinDbg就能在System Root文件夾中找到它們(除非轉儲文件創建後，二進制文件因系統更新而更改)。此外，調試器應該能夠通過SymServ來找到它們。如果配置得當，除了內核轉儲外(下文有描述)，Windows 7還會為每壹次崩潰事件創建和保存微型轉儲。
2、內核轉儲
內核轉儲大小大致相當於Windows 7的內核占用的內存。在我的筆記本電腦上，內核轉儲約344MB大小，壓縮後只有100MB多點。內核轉儲的壹個優點是，它含有二進制文件。默認情況下，我總是讓系統保存最近的內核轉儲。請記住：系統在保存內核轉儲時，也會保存微型轉儲。
3、完整轉儲或完全轉儲
完全內存轉儲大小相當於已安裝內存的數量。由於許多系統有數GB內存，這方面的存儲很快會成為問題，如果妳頻頻遇到崩潰，更是如此。我通常不建議保存完全內存轉儲，因為它們占用太多的空間，而且壹般也不需要。不過微軟的Vachon倒建議：“如果妳試圖調試壹個很復雜的問題，比如設備中多個服務之間的遠程過程調用(RPC)問題，又想看看這些服務在用戶模式下進行什麽操作，完全內存轉儲就大有幫助。”因此，要堅持保存內核轉儲，但要準備偶爾創建完全轉儲。
如果沒有內存轉儲可供使用，怎麽辦？
如果妳沒有內存轉儲可以查看，也不用擔心，可以讓系統崩潰!最簡單的方法(不必更改註冊表的設置)是，運行壹個名為NotMyFault的出色工具(這要感謝Mark Russinovich和SysInternals網站的團隊)。它提供了壹系列選項，可以加載行為異常的驅動程序(這需要管理員權限)。
但記住：NotMyFault會制造系統崩潰!所以要讓妳的系統準備好，確信讓需要訪問該系統的任何人註銷退出幾分鐘。凡是含有可能會丟失的信息的文件都要保存，並關閉應用程序。如果按上述方法配置了系統，它應該沒有問題。機器應該會崩潰，重新啟動，這樣就有了內核轉儲和微型轉儲可以查看。我用過好多次，毫無問題。
下載NotMyFault，迫使系統崩潰
1、從下列微軟網址下載NotMyFault工具，將文件提取到文件夾。
2、鼠標右擊NotMyFault.exe，或者在命令提示符下，鍵入NotMyFault。如果看到“You don't have permission to open this file”(妳沒有權限打開此文件)的信息，那麽再試壹次，但是鼠標右擊時，選擇“Run as Administrator”(以管理員身份運行)。
3、從菜單中選擇High IRQL fault (kernelmode))和Do Bug按鈕。這將生成壹個內存轉儲文件和“Stop D1”錯誤。
4、稍等壹下...妳的系統馬上會回來，會有微型轉儲和內核轉儲可以查看了。
加載轉儲文件
如果妳看到“妳沒有權限打開此文件”的信息，通過鼠標右擊WinDbg來進行重新啟動，選擇“以管理員身份運行”。
壹旦調試器運行，選擇菜單選項File | Open crash dump(文件|打開崩潰轉儲)，指向它，打開妳想要分析的內存轉儲。如果妳想讓它記住轉儲文件在哪裏，那麽看到Save information for workspace(為工作區保存信息)時，選擇Yes(確定)。
WinDbg會尋找Windows的這個確切版本的Windows符號文件。它引用符號文件路徑，訪問microsoft.com，並顯示結果。
註意：如果調試器似乎很忙，那可能是第壹次打開特定機器的轉儲文件，因而，WinDbg從SymServ下載符號。下次打開同壹臺機器的轉儲時，調試器似乎會快得多，因為符號文件已在本機上。
命令窗口會出現，崩潰分析顯示在該窗口上。左下角將是KD>提示符。提示符右邊是壹個單行窗口，妳可以在這裏輸入命令。
可能的錯誤信息
如果妳看到信息：
ERROR: Symbol file could not be found. Defaulted to export symbolsfor ntoskrnl.exe -
錯誤：符號文件找不到。默認情況下導出ntoskrnl.exe的符號-
通常是下列三種情況中有壹種出錯了：
路徑不正確;仔細檢查，確保之前輸入的符號文件路徑沒有拼寫錯誤或其他錯誤(如空白處)
連接失效，檢查互聯網連接，確保它在正常工作
防火墻禁止訪問符號文件，或者符號文件在檢索過程中已損壞
如果妳的路徑和連接沒問題，那麽問題可能出在防火墻上。如果防火墻壹開始阻止WinDbg下載符號表，這會導致符號文件損壞。如果對防火墻解禁，再次試圖下載符號文件仍不行，那麽表明符號文件已損壞。最快的解決辦法是關閉WinDbg，刪除symbols文件夾(最有可能設成c:\symbols)，並且對防火墻解禁。現在，重新打開WinDbg和轉儲文件。調試器會重新創建文件夾，並重新下載符號。
如果妳看到這個信息：
Kernel symbols are WRONG. Please fix symbols to do analysis.
內核符號錯誤。請改正符號，進行分析。
那麽，WinDbg無法檢索正確的符號，它會改而使用默認的符號表。但是這個警告信息表明，它無法生成正確的結果。請記住：符號表是在程序編譯時生成的，所以每個Windows版本、補丁和熱修復程序等都有符號表文件。返回到前壹個章節，確保妳設置的路徑正確、連接正常，而且沒有被阻止。
從頭到尾瀏覽WinDbg的輸出。妳可能會看到類似以下的錯誤信息，表明它可能找不到信息myfault.sys：
Unable to load image \?\C:\Windows\system32\drivers\myfault.sys,Win32 error 0n2
無法加載映像\?\C:\Windows\system32\drivers\myfault.sys, Win32 error 0n2
WARNING: Unable to verify timestamp for myfault.sys
警告：無法為myfault.sys驗證時間戳
ERROR: Module load completed but symbols could not be loaded formyfault.sys
錯誤：模塊加載已完成，但無法為myfault.sys加載符號
這意味著，調試器在尋找myfault.sys方面的信息。然而，由於它像第三方驅動程序(是的，它是由微軟開發，但肯定不是平常的微軟產品)，它沒有符號(微軟並不存儲所有第三方驅動程序)。可以忽視 該錯誤信息。供應商通常在交付驅動程序時不附帶符號文件，符號文件並不是妳所必要的;沒有符號文件，妳也能找到有問題的驅動程序。
當妳讓WinDbg打開轉儲文件後，它會自動進行基本的分析。甚至不用給調試器下達任何直接命令，它已報出了可疑對象，如下面屏幕所示。
命令
有數百個命令可以控制WinDbg;WinDbg是個功能很強大的工具。幸運的是，我們只需要壹個命令。為了讓探討更深入壹點，我們將多用兩個命令，總***有三個命令。它們是!analyze –v、lmv和lmvm。
!analyze –v以詳細模式分析!analyze –v顯示了系統崩潰時，描述系統狀態的信息，遇到的故障，以及誰是主要的可疑對象。
lmv顯示加載模塊的
詳細信息lmv顯示了壹系列驅動程序及路徑、版本和供應商信息。它常包含產品描述。lmv輸出結果可能要很長的時間。留意WinDbg界面的左下角，妳通常會看到kd>提示符。獲取信息時，它會顯示*BUSY*。只有kd>提示符返回後，妳才能使用另外的命令。
lmvm
[模塊名稱]顯示某加載模塊
(模塊名稱)的
詳細信息lmvm[模塊名稱]讓妳能夠告訴調試器只獲取那個特定模塊的信息。比如說：lmvm myfault.sys。
!analyze -v
在命令窗口底部的命令行上輸入!analyze -v(註意yynw命令與“-v”之間的空間)。V(詳細)這個參數選項符告訴WinDbg，妳想要所有的詳細信息。它給出的解釋結合了英語和編程術語，不過這是個良好的開頭。實際上，在許多情況下，妳可能不需要任何下壹步操作。如果妳明白了崩潰的原因，可能就搞定了。
下面這個例子是使用NotmyFault驅動程序來分析我們的崩潰。
如果使用!analyze –v，調試器輸出結果的壹個重要部分是堆棧文本。每次查看轉儲文件，總要關註堆棧最右邊，留意任何第三方驅動程序。在本例中，我們看到了myfault。請註意：事件由下往上按年月順序排列;系統執行每個新任務時，新任務會顯示在最上面，把以前的操作往下移。在這個很短的堆棧中，妳會看到myfault處於活躍狀態，然後出現頁面錯誤，系統聲明進行錯誤檢查，這正是系統停止(藍屏)的時候。請註意：部分數據已被清除，以便該內容能在壹個頁面上顯示，“truncated”註釋表明了這點。
用lmv來分析
下壹步是確認可疑對象的存在，並找到有關它的任何詳細信息。往命令行中輸入lvm，可顯示已加載的模塊;v指調試器以詳細模式輸出，顯示模塊的所有已知詳細信息。
如果運行命令lmv後，妳看到WinDbg的界面左下角出現*BUSY*(*忙碌*)信息，也不用擔心。這是由於它在收集系統發生故障時，加載模塊的詳細信息;收集過程可能需要幾分鐘。收集完畢後，妳會在原來顯示BUSY的地方看到kd>。
這裏有大量信息。找到所要關註的驅動程序得花點時間，所以可通過選擇Edit | Find(編輯|查找)來簡化這個過程，然後輸入可疑的驅動程序，這裏是myfault。妳看到的信息多少取決於驅動程序供應商。壹些供應商把很少的信息放在文件中，而微軟等另壹些供應商往往把全面的信息放在文件中。
用lmvm來分析
想直接找到某個特定模塊，壹個好方法就是使用lmvm命令。在這種情況下，輸入lmvm myfault，調試器將只返回針對該模塊的數據。
妳找到供應商的名稱後，進入其網站，檢查更新、知識庫文章及其他支持信息。要是沒有這些內容，或未能解決問題，請聯系供應商。對方可能會要妳把調試信息發過去(很容易把調試器的輸出結果拷貝到電子郵件或Word文檔裏面)，或者可能會要妳把內存轉儲發過去(先進行打包，既為了壓縮內存轉儲，又為了保護數據完整性)。
另外的三分之壹
幸運的是，妳壹打開轉儲文件就知道原因的機率大概有三分之二。但有時轉儲文件提供的信息具有誤導性，或者不夠全面。這時候，又該怎麽辦呢？
有時原因出在硬件上
如果妳老是遇到崩潰，又沒有明確或壹致的原因，可能出在內存問題上。下載免費測試工具Memtest86。這個簡單的診斷工具運行速度快、效果好。許多人輕視內存問題的可能性，因為內存問題僅占系統崩潰的壹小部分。然而，內存問題常常是害得妳壹直猜測的原因。
Windows是罪魁禍首嗎？
很抱歉，這不可能!雖然可能有人會覺得很意外，但事實上，操作系統很少出錯。如果ntoskrnl.exe(Windows核心)或win32.sys(主要負責Windows上GUI層的驅動程序)被列為是罪魁禍首——它們常常被這樣列為，也不要過於草率地下定論。下面這種可能性大得多：某個異常的第三方設備驅動程序調用了Windows組件，以執行壹項操作，然後傳送了壞的指令，比如告訴它寫入到根本不存在的內存。所以，盡管操作系統肯定會犯錯，但妳在怪罪微軟之前先排除掉其他的所有可能性。
冤枉驅動程序
妳經常會看到反病毒驅動程序被列為是崩潰的原因。比如說，使用!analyze -v後，調試器在“IMAGE_NAME”(映像名稱)這壹行報告反病毒軟件的驅動程序。原因可能確實出在反病毒驅動程序上，不過要牢記：這類驅動程序被冤枉的可能性更大。原因如下：反病毒代碼要工作，它必須監視所有的文件打開和關閉。為了做到這壹點，代碼處在操作系統的低層，而且在不斷工作。實際上，該代碼太忙碌了;崩潰發生時，它常常出現在活躍的函數調用堆棧上，哪怕明明不是它導致崩潰，也這樣。因為該堆棧上的任何第三方驅動程序立即成為可疑對象，所以反病毒驅動程序常常被列為崩潰的原因。不管是不是真的導致了問題，反病毒代碼都經常出現在堆棧上。
缺少供應商信息？
壹些驅動程序供應商並沒有花時間把足夠的信息附在模塊後面。所以，如果lmv起不到幫助，試著查看映像路徑上的子目錄(如果有映像路徑的話)。常常其中壹個子目錄就是供應商名稱或者名稱縮寫。另壹個辦法就是用谷歌搜索引擎搜壹下。輸入驅動程序名稱及/或文件夾名稱。除了別人發布的關於該驅動程序的信息外，妳可能還會找到相應的這家供應商。
總結
妳已經花了時間來準備對付下壹次藍屏死機，記住：在大多數情況下，妳打開轉儲文件後，立馬就能知道原因，整個過程用不了壹分鐘。如此輕而易舉地查明三分之二的嚴重故障的原因，真是讓人滿意——對妳的用戶們來說更是如此。