Dump 文件分析很大程度上就是分析藍(lán)屏產(chǎn)生的原因。這種系統(tǒng)級的錯誤算是Windows提示錯誤中比較嚴(yán)重的一種(更嚴(yán)重的還有啟動黑屏等硬件或軟件兼容性錯誤等等)。說它是比較嚴(yán)重，是因為畢竟Windows還提供了dump文件給用戶分析，至少能比較容易的找到錯誤的原因。一般藍(lán)屏要么是內(nèi)核程序中的異常或違規(guī)，要么是數(shù)據(jù)結(jié)構(gòu)的損壞，也有boot或shutdown的時候內(nèi)核出錯。有時候藍(lán)屏是一閃而過，緊接著是系統(tǒng)重啟；有時候是藍(lán)屏等待。總之藍(lán)屏的時候都提示了一些停止代碼和錯誤信息，不過這些提示是不全面的，最多知道哪個模塊出錯(比如驅(qū)動)。想了解進(jìn)一步的信息，或者通過搜索引擎，最好的方式當(dāng)然是dump文件分析。當(dāng)然，如果有更進(jìn)一步研究的欲望，內(nèi)核調(diào)試是更好的方法，不過這需要某些軟件支持和調(diào)試技巧。

類型
Dump文件有三種：完整內(nèi)存轉(zhuǎn)儲，內(nèi)核內(nèi)存轉(zhuǎn)儲，小內(nèi)存轉(zhuǎn)儲。System Properties中的高級選項中可以看到這些設(shè)置。
完整內(nèi)存轉(zhuǎn)儲太大，一般是物理內(nèi)存大小或多一些，包括了用戶進(jìn)程頁面，這種方式不實用，2GB的物理內(nèi)存轉(zhuǎn)儲出來至少要2GB的磁盤空間(還有文件頭信息)。內(nèi)核轉(zhuǎn)儲一般是200MB大小(物理內(nèi)存小于4GB)，它只是包含了所有屬于內(nèi)核模式的物理內(nèi)存。小內(nèi)存轉(zhuǎn)儲一般是64KB(64位上是 128KB)，這兩種方式是更常用的。
小內(nèi)存轉(zhuǎn)儲在\Windows\Minidump下生成了一個叫Mini日期+序列號.dmp的文件，這個珍貴的資源就是系統(tǒng)Crash時刻的狀態(tài)，只不過小內(nèi)存轉(zhuǎn)儲只記錄的有限的信息，而且在你分析時，如果windbg沒有設(shè)置符號服務(wù)器的路徑(關(guān)于符號服務(wù)器，請參考Windbg內(nèi)核調(diào)試之二: 常用命令)，那么你的當(dāng)前系統(tǒng)必須和發(fā)生藍(lán)屏的系統(tǒng)的Ntoskrnl.exe版本相同，否則就有找不到符號的問題產(chǎn)生。
啟動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系統(tǒng)的版本，加載符號的過程，如果找不到符號文件，還會提示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命令查看模塊列表。另外，如果出現(xiàn)Unable to load image，說明沒有找到這個文件，這個時候需要查看是否加載了正確的符號文件。設(shè)置符號服務(wù)器路徑(.symfix命令)是很有必要的，因為調(diào)試機器和Crash機器的環(huán)境很可能不一致。
運行命令kb，顯示調(diào)用棧的信息。如果有正確的符號設(shè)置，可以看到調(diào)用的函數(shù)名。如果你在調(diào)試自己驅(qū)動程序的藍(lán)屏問題，請確保設(shè)置正確該驅(qū)動程序的符號路徑，不然就會出現(xiàn)Stack unwind information not available的問題。加入正確的符號文件(pdb)后，可以用命令!reload重新加載符號文件。
通過!thread和!process，可以顯示當(dāng)前進(jìn)程和線程。或者通過dt nt!_KTHREAD 地址和dt nt!_EPROCESS地址來查看線程和進(jìn)程結(jié)構(gòu)。

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

---

一般是按照如下：停止碼解釋，陷阱幀寄存器信息，藍(lán)屏屬性(有些除零錯誤就在這里顯示)，棧調(diào)用，錯誤指令位置(FOLLOWUP_IP)，出錯源代碼和匯編代碼行，錯誤代碼行，出錯模塊信息(包括負(fù)責(zé)人等信息)，來組織自動分析信息。

通過r命令，可以顯示Crash時刻寄存器的狀態(tài)和最后的命令狀態(tài)。

通過d命令，可以顯示當(dāng)前內(nèi)存的地址。在定位了錯誤代碼行了之后，就可以進(jìn)一步進(jìn)行內(nèi)核調(diào)試和系統(tǒng)調(diào)試了。

總結(jié)

以上是生活随笔為你收集整理的Windbg内核调试之四: Dump文件分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。