Windbg 内核调试 Dump文件分析

来源：互联网发布：java中super关键字编辑：程序博客网时间：2024/05/21 17:59

类型
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 availableSymbol search path is: SRV*d:/temp/*http://msdl.microsoft.com/download/symbolsExecutable search path is:Windows Vista Kernel Version 6000 (Service Pack 1) UP Free x86 compatibleKernel base = 0x80400000 PsLoadedModuleList = 0x8046e8f0Debug session time: Thu May 28 16:12:29.031 2009 (GMT+8)System Uptime: not availableLoading 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 aninterrupt request level (IRQL) that is too high.   This is usuallycaused by drivers using improper addresses.If kernel debugger is available get stack backtrace.Arguments:Arg1: e1147008, memory referencedArg2: 0000001c, IRQLArg3: 00000000, value 0 = read operation, 1 = write operationArg4: fbe93403, address which referenced memoryDebugging Details:------------------READ_ADDRESS:   e1147008 Paged poolCURRENT_IRQL:   1cFAULTING_IP:myfault+403fbe93403 8b06             mov      eax,dword ptr [esi]DEFAULT_BUCKET_ID:   DRIVER_FAULTBUGCHECK_STR:   0xD1PROCESS_NAME:   NotMyfault.exeTRAP_FRAME:   f9357b80 --(trap fffffffff9357b80)ErrCode = 00000000eax=00000000 ebx=8111f330 ecx=000000d1 edx=0000001c esi=e1147008 edi=00000000eip=fbe93403 esp=f9357bf4 ebp=f9357c58 iopl=0          nv up ei pl zr na pe nccs=0008   ss=0010   ds=0023   es=0023   fs=0030   gs=0000              efl=00010246myfault+0x403:fbe93403 8b06             mov      eax,dword ptr [esi]   ds:0023:e1147008=????????Resetting default scopeLAST_CONTROL_TRANSFER:   from 804f880d to 80527da8STACK_TEXT:f9357734 804f880d 00000003 f9357a90 00000000 nt!RtlpBreakWithStatusInstructionf9357780 804f93fa 00000003 e1147008 fbe93403 nt!KiBugCheckDebugBreak+0x19f9357b60 80540853 0000000a e1147008 0000001c nt!KeBugCheck2+0x574f9357b60 fbe93403 0000000a e1147008 0000001c nt!KiTrap0E+0x233WARNING: Stack unwind information not available. Following frames may be wrong.f9357c58 805759d1 ffb5c3b0 8111f318 811d9130 myfault+0x403f9357d00 8056e33c 00000090 00000000 00000000 nt!IopXxxControlFile+0x5e7f9357d34 8053d808 00000090 00000000 00000000 nt!NtDeviceIoControlFile+0x2af9357d34 7c92eb94 00000090 00000000 00000000 nt!KiFastCallEntry+0xf80012f9f0 7c92d8ef 7c801671 00000090 00000000 ntdll!KiFastSystemCallRet0012f9f4 7c801671 00000090 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc0012fa54 004018c2 00000090 83360018 00000000 0x7c801671STACK_COMMAND:   kbFOLLOWUP_IP:myfault+403fbe93403 8b06             mov      eax,dword ptr [esi]SYMBOL_STACK_INDEX:   4FOLLOWUP_NAME:   MachineOwnerMODULE_NAME: myfaultIMAGE_NAME:   myfault.sysDEBUG_FLR_IMAGE_TIMESTAMP:   43774e1dSYMBOL_NAME:   myfault+403FAILURE_BUCKET_ID:   0xD1_myfault+403BUCKET_ID:   0xD1_myfault+403Followup: MachineOwner

一般是按照如下：停止码解释，陷阱帧寄存器信息，蓝屏属性(有些除零错误就在这里显示)，栈调用，错误指令位置(FOLLOWUP_IP)，出错源代码和汇编代码行，错误代码行，出错模块信息(包括负责人等信息)，来组织自动分析信息。
通过r命令，可以显示Crash时刻寄存器的状态和最后的命令状态。
通过d命令，可以显示当前内存的地址。在定位了错误代码行了之后，就可以进一步进行内核调试和系统调试了。

0 0