初識-WINDBG 分析DUMP

Dump 檔案分析很大程度上就是分析藍屏產生的原因。這種系統級的錯誤算是Windows提示錯誤中比較嚴重的一種(更嚴重的還有啟動黑屏等硬體或軟體相容性錯誤等等)。說它是比較嚴重，是因為畢竟Windows還提供了dump檔案給使用者分析，至少能比較容易的找到錯誤的原因。一般藍屏要麼是核心程式中的異常或違規，要麼是資料結構的損壞，也有boot或shutdown的時候核心出錯。有時候藍屏是一閃而過，緊接著是系統重啟；有時候是藍屏等待。總之藍屏的時候都提示了一些停止代碼和錯誤資訊，不過這些提示是不全面的，最多知道哪個模組出錯(比如驅動)。想瞭解進一步的資訊，或者通過搜尋引擎，最好的方式當然是dump檔案分析。當然，如果有更進一步研究的慾望，核心調試是更好的方法，不過這需要某些軟體支援和調試技巧。

類型
Dump檔案有三種：完整記憶體轉儲，核心記憶體轉儲，小記憶體轉儲。System Properties中的進階選項中可以看到這些設定。
完整記憶體轉儲太大，一般是實體記憶體大小或多一些，包括了使用者進程頁面，這種方式不實用，2GB的實體記憶體轉儲出來至少要2GB的磁碟空間(還有檔案頭資訊)。核心轉儲一般是200MB大小(實體記憶體小於4GB)，它只是包含了所有屬於核心模式的實體記憶體。小記憶體轉儲一般是64KB(64位上是 128KB)，這兩種方式是更常用的。
小記憶體轉儲在/Windows /Minidump下產生了一個叫Mini日期+序號.dmp的檔案，這個珍貴的資源就是系統Crash時刻的狀態，只不過小記憶體轉儲只記錄的有限的資訊，而且在你分析時，如果windbg沒有設定符號伺服器的路徑(關於符號伺服器，請參考Windbg核心調試之二: 常用命令)，那麼你的當前系統必須和發生藍屏的系統的Ntoskrnl.exe版本相同，否則就有找不到符號的問題產生。
啟動windbg，用 Open Crash Dump開啟dump檔案，或者直接拖動檔案到windbg中，windbg顯示如下資訊：
Loading Dump File [C:/dbg/Mini052809-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*d:/temp/*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows Vista Kernel Version 6000 (Service Pack 1) UP Free x86 compatible
Kernel base = 0x80400000 PsLoadedModuleList = 0x8046e8f0
Debug session time: Thu May 28 16:12:29.031 2009 (GMT+8)
System Uptime: not available
Loading Kernel Symbols...............................................................
Loading unloaded module list.....................................................................

Loading UserSymbols
******************************************************************************** ** Bugcheck Analysis ** ********************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 7F, {0, 0, 0, 0}

大致上提示了Crash系統的版本，載入符號的過程，如果找不到符號檔案，還會提示Unable to load image。如下錯誤就是找不到ntoskrnl.exe的符號檔案：

Unable to load image /SystemRoot/system32/ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe

命令
通過lm命令查看模組列表。另外，如果出現Unable to load image，說明沒有找到這個檔案，這個時候需要查看是否載入了正確的符號檔案。設定符號伺服器路徑(.symfix命令)是很有必要的，因為調試機器和 Crash機器的環境很可能不一致。
運行命令kb，顯示調用棧的資訊。如果有正確的符號設定，可以看到調用的函數名。如果你在調試自己驅動程式的藍屏問題，請確保設定正確該驅動程式的符號路徑，不然就會出現Stack unwind information not available的問題。加入正確的符號檔案(pdb)後，可以用命令!reload重新載入符號檔案。
通過!thread 和!process，可以顯示當前進程和線程。或者通過dt nt!_KTHREAD 地址和dt nt!_EPROCESS地址來查看線程和進程結構。

Windbg 提供了自動分析dump檔案的機制。通過命令!analyze –v，windbg可以自動做分析，顯示如下資訊：
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: e1147008, memory referenced
Arg2: 0000001c, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: fbe93403, address which referenced memory

Debugging Details:
------------------
READ_ADDRESS: e1147008 Paged pool
CURRENT_IRQL: 1c
FAULTING_IP:
myfault+403
fbe93403 8b06 mov eax,dword ptr [esi]

DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xD1
PROCESS_NAME: NotMyfault.exe

TRAP_FRAME: f9357b80 --(trap fffffffff9357b80)
ErrCode = 00000000
eax=00000000 ebx=8111f330 ecx=000000d1 edx=0000001c esi=e1147008 edi=00000000
eip=fbe93403 esp=f9357bf4 ebp=f9357c58 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
myfault+0x403:
fbe93403 8b06 mov eax,dword ptr [esi] ds:0023:e1147008=????????
Resetting default scope

LAST_CONTROL_TRANSFER: from 804f880d to 80527da8

STACK_TEXT:
f9357734 804f880d 00000003 f9357a90 00000000 nt!RtlpBreakWithStatusInstruction
f9357780 804f93fa 00000003 e1147008 fbe93403 nt!KiBugCheckDebugBreak+0x19
f9357b60 80540853 0000000a e1147008 0000001c nt!KeBugCheck2+0x574
f9357b60 fbe93403 0000000a e1147008 0000001c nt!KiTrap0E+0x233
WARNING: Stack unwind information not available. Following frames may be wrong.
f9357c58 805759d1 ffb5c3b0 8111f318 811d9130 myfault+0x403
f9357d00 8056e33c 00000090 00000000 00000000 nt!IopXxxControlFile+0x5e7
f9357d34 8053d808 00000090 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
f9357d34 7c92eb94 00000090 00000000 00000000 nt!KiFastCallEntry+0xf8
0012f9f0 7c92d8ef 7c801671 00000090 00000000 ntdll!KiFastSystemCallRet
0012f9f4 7c801671 00000090 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc
0012fa54 004018c2 00000090 83360018 00000000 0x7c801671

STACK_COMMAND: kb

FOLLOWUP_IP:
myfault+403
fbe93403 8b06 mov eax,dword ptr [esi]

SYMBOL_STACK_INDEX: 4
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: myfault
IMAGE_NAME: myfault.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 43774e1d
SYMBOL_NAME: myfault+403
FAILURE_BUCKET_ID: 0xD1_myfault+403
BUCKET_ID: 0xD1_myfault+403
Followup: MachineOwner

一般是按照如下：停止碼解釋，陷阱幀寄存器資訊，藍屏屬性(有些除零錯誤就在這裡顯示)，棧調用，錯誤指令位置(FOLLOWUP_IP)，出錯原始碼和彙編程式碼，錯誤碼行，出錯模組資訊(包括負責人等資訊)，來組織自動分析資訊。

通過r命令，可以顯示Crash時刻寄存器的狀態和最後的命令狀態。

通過d命令，可以顯示當前記憶體的地址。在定位了錯誤碼行了之後，就可以進一步進行核心調試和系統調試了。

 

轉自： http://www.horseb.net/html/6155/6155.html