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

類(lèi)型
Dump文件有三種：完整內(nèi)存轉(zhuǎn)儲(chǔ)，內(nèi)核內(nèi)存轉(zhuǎn)儲(chǔ)，小內(nèi)存轉(zhuǎn)儲(chǔ)。System Properties中的高級(jí)選項(xiàng)中可以看到這些設(shè)置。
完整內(nèi)存轉(zhuǎn)儲(chǔ)太大，一般是物理內(nèi)存大小或多一些，包括了用戶(hù)進(jìn)程頁(yè)面，這種方式不實(shí)用，2GB的物理內(nèi)存轉(zhuǎn)儲(chǔ)出來(lái)至少要2GB的磁盤(pán)空間(還有文件頭信息)。內(nèi)核轉(zhuǎn)儲(chǔ)一般是200MB大小(物理內(nèi)存小于4GB)，它只是包含了所有屬于內(nèi)核模式的物理內(nèi)存。小內(nèi)存轉(zhuǎn)儲(chǔ)一般是64KB(64位上是 128KB)，這兩種方式是更常用的。
小內(nèi)存轉(zhuǎn)儲(chǔ)在\Windows\Minidump下生成了一個(gè)叫Mini日期+序列號(hào).dmp的文件，這個(gè)珍貴的資源就是系統(tǒng)Crash時(shí)刻的狀態(tài)，只不過(guò)小內(nèi)存轉(zhuǎn)儲(chǔ)只記錄的有限的信息，而且在你分析時(shí)，如果windbg沒(méi)有設(shè)置符號(hào)服務(wù)器的路徑(關(guān)于符號(hào)服務(wù)器，請(qǐng)參考Windbg內(nèi)核調(diào)試之二: 常用命令)，那么你的當(dāng)前系統(tǒng)必須和發(fā)生藍(lán)屏的系統(tǒng)的Ntoskrnl.exe版本相同，否則就有找不到符號(hào)的問(wèn)題產(chǎn)生。
啟動(dòng)windbg，用Open Crash Dump打開(kāi)dump文件，或者直接拖動(dòng)文件到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)的版本，加載符號(hào)的過(guò)程，如果找不到符號(hào)文件，還會(huì)提示Unable to load image。如下錯(cuò)誤就是找不到ntoskrnl.exe的符號(hào)文件：

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?

命令
通過(guò)lm命令查看模塊列表。另外，如果出現(xiàn)Unable to load image，說(shuō)明沒(méi)有找到這個(gè)文件，這個(gè)時(shí)候需要查看是否加載了正確的符號(hào)文件。設(shè)置符號(hào)服務(wù)器路徑(.symfix命令)是很有必要的，因?yàn)檎{(diào)試機(jī)器和Crash機(jī)器的環(huán)境很可能不一致。
運(yùn)行命令kb，顯示調(diào)用棧的信息。如果有正確的符號(hào)設(shè)置，可以看到調(diào)用的函數(shù)名。如果你在調(diào)試自己驅(qū)動(dòng)程序的藍(lán)屏問(wèn)題，請(qǐng)確保設(shè)置正確該驅(qū)動(dòng)程序的符號(hào)路徑，不然就會(huì)出現(xiàn)Stack unwind information not available的問(wèn)題。加入正確的符號(hào)文件(pdb)后，可以用命令!reload重新加載符號(hào)文件。
通過(guò)!thread和!process，可以顯示當(dāng)前進(jìn)程和線(xiàn)程?；蛘咄ㄟ^(guò)dt nt!_KTHREAD 地址和dt nt!_EPROCESS地址來(lái)查看線(xiàn)程和進(jìn)程結(jié)構(gòu)。

Windbg提供了自動(dòng)分析dump文件的機(jī)制。通過(guò)命令!analyze –v，windbg可以自動(dòng)做分析，顯示如下信息：

---

*******************************************************************************
*??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????*
*?????????????????????????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)屏屬性(有些除零錯(cuò)誤就在這里顯示)，棧調(diào)用，錯(cuò)誤指令位置(FOLLOWUP_IP)，出錯(cuò)源代碼和匯編代碼行，錯(cuò)誤代碼行，出錯(cuò)模塊信息(包括負(fù)責(zé)人等信息)，來(lái)組織自動(dòng)分析信息。

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

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

總結(jié)

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

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