WINDBG分析DMP方法

阿新 • • 發佈：2018-11-12

分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow

也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！

上次發了2100藍屏抓DMP分析案例這個帖子後，好多人想學怎麼分析DMP，那我也是剛剛學的，簡單的說下。
http://bbs.icafe8.com/forum.php?mod=viewthread&tid=399075&fromuid=30123

1：先下載附件WinDbg，解壓出來後，直接執行裡面的windbg.exe。（或者可以自已去網上下的）

WinDbg.part11.rar (465.13 KB, 下載次數: 84)

WinDbg.part10.rar (1.39 MB, 下載次數: 97)

WinDbg.part09.rar (1.39 MB, 下載次數: 80)

WinDbg.part08.rar (1.39 MB, 下載次數: 86)

WinDbg.part07.rar

(1.39 MB, 下載次數: 79)

WinDbg.part06.rar (1.39 MB, 下載次數: 98)

WinDbg.part05.rar (1.39 MB, 下載次數: 86)

WinDbg.part04.rar (1.39 MB, 下載次數: 94)

WinDbg.part03.rar (1.39 MB, 下載次數: 82)

WinDbg.part02.rar (1.39 MB, 下載次數: 93)

WinDbg.part01.rar (1.39 MB, 下載次數: 82)
2：第一次開啟介面操作如下圖：

3：然後會出現如下圖的，另外把SRV*e:\symbols* http://msdl.microsoft.com/download/symbols
複製進去。
http://msdl.microsoft.com/download/symbols 為微軟符號表伺服器地址

然後點OK，然後關閉windbg一次。不然這個設定不會被儲存下來。
然後下次需要看DUP的時候，開啟windbg.exe，直接可以把抓來的DMP檔案拖到開啟的介面裡面就可以分析了。
4：自動分析命令 !analyze -v
以網咖抓到的一個F4藍屏為例

上圖比較迷惑的地方

從這個棧回溯看，會以為是vdiskbus+0xda6c引起的藍屏。
實際上這裡是無盤實現的抓DUMP的機制，這裡可以看作是對系統函式KebugCheckEx的展開。這個是這樣理解，KebugCheckEx呼叫地址 0x89fb41ca,地址0x89fb41ca會呼叫vdiskbus+0xda6c,也就是無盤的DMP機制。所以看到這樣的棧回溯，說明並不是vdiskbus引起藍屏，只是呼叫到了無盤的DMP機制。
從另一個角度來說，呼叫KebugCheckEx就是藍屏，KebugCheckEx呼叫的不是引起藍屏的。所以要向前推，看誰在呼叫KebugCheckEx。
這個例項中看到殺程序的函式ZwTerminateProcess原型為：
ZwTerminateProcess(IN HANDLE ProcessHandle OPTIONAL,IN NTSTATUS ExitStatus)；
看堆疊中第一個引數:

為0xffffffff即-1，表示殺掉了自己。然後用命令!process 看下當前程序是誰。

這樣從棧資訊，看到是csrss.exe程序出現了異常，會導致程序自殺。而引起F4藍屏。具體是哪裡引起的，因為小DMP沒有使用者態資訊。得不到進一步的問題確認（有可能有人注入csrss引起等原因）。
其實自動分析已經把結果列出來了，實際上不需要我們做上面的分析。

F4藍屏的第二個引數，就是被殺掉的程序的程序物件。自動分析已經指出為csrss程序。做上述人工分析，是想說明人工怎麼定位問題。
5：常用命令：
檢視棧的命令：k,kb,kn,kd,kl
檢視記憶體的命令：db,dw,dd,da,du
用一個網咖抓到的DMP為EA藍屏的做為例子。

自動分析的棧來看，是看門狗驅動呼叫的藍屏函式kebugcheckex。這個棧來看沒有什麼用。從自動分析對EA藍屏的解釋來看是裝置驅動變為閒置狀態，一定時間內，沒有喂狗訊號。看門狗會呼叫dbgBreakPoint，而不是kebugCheckex。不過我們還是在kebugCheckex拿到了一些藍屏的資訊。
EA藍屏的第一個引數指向一個執行緒物件，用命令.thread 切換到對應執行緒，然後用kb檢視執行緒棧，就可以確定哪裡出了問題。