煎饼 发表于 2008-11-26 10:52:26

Windbg核心调试之dump分析

文章标题：Windbg核心调试之dump分析<BR>我的邮箱：Lvg2008@gmail.com<BR>调试环境：winxp&nbsp;sp2+windbg&nbsp;ver:6.6.0007.5+vmware&nbsp;5.5.2<BR>一．Dump文件的产生，意义和类型<BR>&nbsp;&nbsp;&nbsp;&nbsp;当系统发生错误是，最常见的就是蓝屏（Blue&nbsp;screen），这时就会在系统目录下产生一个Dump文件，如MEMORY.DMP&nbsp;。这个文件的主要意义在于分析系统错误发生的原因，以作出解决的方法。<BR>&nbsp;&nbsp;&nbsp;它可分为三种类型：<BR>&nbsp;&nbsp;&nbsp;1.完全内存转储。这个文件比较大，和物理内存相当，包含了程序崩溃前系统及用户模式下的所有信息。<BR>&nbsp;&nbsp;&nbsp;2.核心内存转储。这个文件大小约物理内存的三分之一，主要包含崩溃前系统内核的运行情况。一般为了分析内核错误，就选用这种文件。<BR>&nbsp;&nbsp;&nbsp;3.小内存转储。这个文件小，只有64k，刚好一个页面文件大小。它包含了相对比较少的信息，主要可用于微软的在线分析。<BR>&nbsp;&nbsp;&nbsp;以上三种形式的文件可以在我的电脑――〉鼠标右键――〉属性――〉高级――〉故障及恢复中设置。如下图：<BR>
<P align=center><IMG onmouseover="this.style.cursor='pointer';" title=/Hacker/UploadFiles_7054/200801/200812151413461.jpg style="CURSOR: pointer" onclick="window.open('/Hacker/UploadFiles_7054/200801/200812151413461.jpg');" alt=/Hacker/UploadFiles_7054/200801/200812151413461.jpg src="http://www.syue.cn/Hacker/UploadFiles_7054/200801/200812151413461.jpg" onload="if(this.width>screen.width*0.6) {this.width=screen.width*0.6;this.alt='此图已经缩小，点击察看原图。';}" border=0></P>
<P>&nbsp;</P>
<P><BR>二。Dump文件的强迫产生</P>
<P><BR>&nbsp;&nbsp;&nbsp;由于我们也不知道何时会产生一个系统错误，从而得到dump文件，所以当练习分析时，可认为强迫产生一个。一般有以下两个办法。<BR>&nbsp;&nbsp;&nbsp;1.双机联调。这里的双机可以是物理上的两台电脑，也可以是用虚拟机模拟。我想这里的大多数人应该选择后者，为啥？还不是money的问题~_^。当用windbg把被调试机联上以后，就可以用.crash命令产生一个蓝屏，当然之前要在被调试机里把dump产生的路径和类型设定好。还有另外一张办法，是通过修改注册表后，用键盘产生dump，但这种方法哪有第一种来的快，所以就不说了，感兴趣的可以查查windbg帮助文档看看。<BR>&nbsp;&nbsp;&nbsp;2.单机驱动产生。这种方法，不必用双机联调，在本机上就可以办到。由于驱动深入到了内核，它的要求非常苛刻，一个简单的除零操作就可引发蓝屏。但是驱动的编写与普通win32&nbsp;api是有很大不同的，为了减轻负担，我直接运用一个现成的程序，是《Microsoft&nbsp;Windows&nbsp;Internals》作者写的Notmyfault（见附件）。它由Notmyfault.exe和Myfault.sys两部分组成。正如名字一样，引发蓝屏的不是Notmyfault.exe而是由他加载到内核中的Myfault.sys。如图:<BR></P>
<P align=center><IMG onmouseover="this.style.cursor='pointer';" title=/Hacker/UploadFiles_7054/200801/200812151413415.jpg style="CURSOR: pointer" onclick="window.open('/Hacker/UploadFiles_7054/200801/200812151413415.jpg');" alt=/Hacker/UploadFiles_7054/200801/200812151413415.jpg src="http://www.syue.cn/Hacker/UploadFiles_7054/200801/200812151413415.jpg" onload="if(this.width>screen.width*0.6) {this.width=screen.width*0.6;this.alt='此图已经缩小，点击察看原图。';}" border=0></P>
<P>&nbsp;<BR>&nbsp;&nbsp;&nbsp;我在这里两种方法都同时用了，先在虚拟机里执行Notmyfault，接着windbg立刻检测到了系统崩溃，并输出相关信息。&nbsp;</P>
<P><BR>三。Dump文件的分析<BR>&nbsp;&nbsp;&nbsp;&nbsp;当按上面的方法运行后，windbg输出了以下内容：<BR>***&nbsp;Fatal&nbsp;System&nbsp;Error:&nbsp;0x000000d1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(0xE1147008,0x0000001C,0x00000000,0xFBE93403)<BR><BR>&nbsp;&nbsp;Break&nbsp;instruction&nbsp;exception&nbsp;-&nbsp;code&nbsp;80000003&nbsp;(first&nbsp;chance)<BR><BR>&nbsp;&nbsp;A&nbsp;fatal&nbsp;system&nbsp;error&nbsp;has&nbsp;occurred.<BR>&nbsp;&nbsp;Debugger&nbsp;entered&nbsp;on&nbsp;first&nbsp;try;&nbsp;Bugcheck&nbsp;callbacks&nbsp;have&nbsp;not&nbsp;been&nbsp;&nbsp;&nbsp;invoked.<BR><BR>&nbsp;&nbsp;A&nbsp;fatal&nbsp;system&nbsp;error&nbsp;has&nbsp;occurred.<BR><BR>*******************************************************************************<BR>*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</P>
<P>nbsp;&nbsp;&nbsp;&nbsp;*<BR>*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Bugcheck&nbsp;Analysis&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*<BR>*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*<BR>*******************************************************************************<BR><BR>Use&nbsp;!analyze&nbsp;-v&nbsp;to&nbsp;get&nbsp;detailed&nbsp;debugging&nbsp;information.<BR><BR>2.BugCheck&nbsp;D1,&nbsp;{e1147008,&nbsp;1c,&nbsp;0,&nbsp;fbe93403}<BR><BR>***&nbsp;ERROR:&nbsp;Module&nbsp;load&nbsp;completed&nbsp;but&nbsp;symbols&nbsp;could&nbsp;not&nbsp;be&nbsp;loaded&nbsp;for&nbsp;myfault.sys<BR>3.Probably&nbsp;caused&nbsp;by&nbsp;:&nbsp;myfault.sys&nbsp;(&nbsp;myfault+403&nbsp;)<BR><BR>Followup:&nbsp;MachineOwner<BR>---------<BR>nt!RtlpBreakWithStatusInstruction:<BR>80527da8&nbsp;cc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3<BR>Kd:&gt;&nbsp;&nbsp;<BR><BR>上面这一段，有用的信息，如1和2两段，说明的是一个问题，都指明了BugCheck是D1，并给了四个参数，这里的D1可以在windbg文档的Bug&nbsp;Check&nbsp;Code&nbsp;Reference中查出其具体含义，也可用!analyze&nbsp;?show&nbsp;D1命令查出。3说明引起的原因是myfault.sys模块。<BR>接着在kd后输入!analyze&nbsp;?v命令，这个命令是详细列出dump文件的信息。<BR><BR>windbg输出如下：<BR>kd&gt;&nbsp;!analyze&nbsp;-v<BR>*******************************************************************************<BR>*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*<BR>*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Bugcheck&nbsp;Analysis&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*<BR>*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*<BR>*******************************************************************************<BR><BR>DRIVER_IRQL_NOT_LESS_OR_EQUAL&nbsp;(d1)&nbsp;&nbsp;//指明Bugcheck&nbsp;D1,我们已看见过了<BR>An&nbsp;attempt&amp;nbsp;was&nbsp;made&nbsp;to&nbsp;access&nbsp;a&nbsp;pageable&nbsp;(or&nbsp;completely&nbsp;invalid)&nbsp;address&nbsp;at&nbsp;an<BR>interrupt&nbsp;request&nbsp;level&nbsp;(IRQL)&nbsp;that&nbsp;is&nbsp;too&nbsp;high.&nbsp;&nbsp;This&nbsp;is&nbsp;usually<BR>caused&nbsp;by&nbsp;drivers&nbsp;using&nbsp;improper&nbsp;addresses.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//解释了错误的原因<BR>If&nbsp;kernel&nbsp;debugger&nbsp;is&nbsp;available&nbsp;get&nbsp;stack&nbsp;backtrace.<BR>Arguments:<BR>Arg1:&nbsp;e1147008,&nbsp;memory&nbsp;referenced<BR>Arg2:&nbsp;0000001c,&nbsp;IRQL<BR>Arg3:&nbsp;00000000,&nbsp;value&nbsp;0&nbsp;=&nbsp;read&nbsp;operation,&nbsp;1&nbsp;=&nbsp;write&nbsp;operation<BR>Arg4:&nbsp;fbe93403,&nbsp;address&nbsp;which&nbsp;referenced&nbsp;memory<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//给出了相应的四个参数，第二列是代号，第三列是解释<BR>Debugging&nbsp;Details:<BR>------------------<BR>READ_ADDRESS:&nbsp;&nbsp;e1147008&nbsp;Paged&nbsp;pool&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//上面的Arg1.<BR><BR>CURRENT_IRQL:&nbsp;&nbsp;1c&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//上面的Arg2<BR><BR>FAULTING_IP:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//指出发生错误时所执行的指令<BR>myfault+403<BR>fbe93403&nbsp;8b06&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mov&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;eax,dword&nbsp;ptr&nbsp;<BR><BR>DEFAULT_BUCKET_ID:&nbsp;&nbsp;DRIVER_FAULT&nbsp;&nbsp;&nbsp;//指出错误类型，是驱动错误<BR><BR>BUGCHECK_STR:&nbsp;&nbsp;0xD1&nbsp;&nbsp;&nbsp;//bugcheck索引，可查windbg文档，也可!analyze&nbsp;?show&nbsp;D1<BR><BR>PROCESS_NAME:&nbsp;&nbsp;NotMyfault.exe&nbsp;&nbsp;//错误所属进程<BR><BR>TRAP_FRAME:&nbsp;&nbsp;f9357b80&nbsp;--(trap&nbsp;fffffffff9357b80)//错误时各寄存器的内容<BR>ErrCode&nbsp;=&nbsp;00000000<BR>eax=00000000&nbsp;ebx=8111f330&nbsp;ecx=000000d1&nbsp;edx=0000001c&nbsp;esi=e1147008&nbsp;edi=00000000<BR>eip=fbe93403&nbsp;esp=f9357bf4&nbsp;ebp=f9357c58&nbsp;iopl=0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;nv&nbsp;up&nbsp;ei&nbsp;pl&nbsp;zr&nbsp;na&nbsp;pe&nbsp;nc<BR>cs=0008&nbsp;&nbsp;ss=0010&nbsp;&nbsp;ds=0023&nbsp;&nbsp;es=0023&nbsp;&nbsp;fs=0030&nbsp;&nbsp;gs=0000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;efl=00010246<BR>myfault+0x403:<BR>fbe93403&nbsp;8b06&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mov&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;eax,dword&nbsp;ptr&nbsp;&nbsp;&nbsp;ds:0023:e1147008=????????<BR>Resetting&nbsp;default&nbsp;scope<BR><BR>LAST_CONTROL_TRANSFER:&nbsp;&nbsp;from&nbsp;804f880d&nbsp;to&nbsp;80527da8<BR><BR>STACK_TEXT:&nbsp;//反映了错误前堆栈中函数调用情况，最下面的0x7c801671处函数调用ntdll中的ZwDeviceIoControlFile，接着调用了ntdll中的KiFastSystemCallRet，再接着调用了nt（这里的nt指Ntoskrnl）中的KiFastCallEntry，一直到myfault+0x403，发生异常。<BR>f9357734&nbsp;804f880d&nbsp;00000003&nbsp;f9357a90&nbsp;00000000&nbsp;nt!RtlpBreakWithStatusInstruction<BR>f9357780&nbsp;804f93fa&nbsp;00000003&nbsp;e1147008&nbsp;fbe93403&nbsp;nt!KiBugCheckDebugBreak+0x19<BR>f9357b60&nbsp;80540853&nbsp;0000000a&nbsp;e1147008&nbsp;0000001c&nbsp;nt!KeBugCheck2+0x574<BR>f9357b60&nbsp;fbe93403&nbsp;0000000a&nbsp;e1147008&nbsp;0000001c&nbsp;nt!KiTrap0E+0x233<BR>WARNING:&nbsp;Stack&nbsp;unwind&nbsp;information&nbsp;not&nbsp;available.&nbsp;Following&nbsp;frames&nbsp;may&nbsp;be&nbsp;wrong.<BR>f9357c58&nbsp;805759d1&nbsp;ffb5c3b0&nbsp;8111f318&nbsp;811d9130&nbsp;myfault+0x403<BR>f9357d00&nbsp;8056e33c&nbsp;00000090&nbsp;00000000&nbsp;00000000&nbsp;nt!IopXxxControlFile+0x5e7<BR>f9357d34&nbsp;8053d808&nbsp;00000090&nbsp;00000000&nbsp;00000000&nbsp;nt!NtDeviceIoControlFile+0x2a<BR>f9357d34&nbsp;7c92eb94&nbsp;00000090&nbsp;00000000&nbsp;00000000&nbsp;nt!KiFastCallEntry+0xf8<BR>0012f9f0&nbsp;7c92d8ef&nbsp;7c801671&nbsp;00000090&nbsp;00000000&nbsp;ntdll!KiFastSystemCallRet<BR>0012f9f4&nbsp;7c801671&nbsp;00000090&nbsp;00000000&nbsp;00000000&nbsp;ntdll!ZwDeviceIoControlFile+0xc<BR>0012fa54&nbsp;004018c2&nbsp;00000090&nbsp;83360018&nbsp;00000000&nbsp;0x7c801671<BR><BR><BR>STACK_COMMAND:&nbsp;&nbsp;kb<BR><BR>FOLLOWUP_IP:&nbsp;//反汇编了发生错误指令的代码<BR>myfault+403<BR>fbe93403&nbsp;8b06&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mov&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;eax,dword&nbsp;ptr&nbsp;<BR><BR>SYMBOL_STACK_INDEX:&nbsp;&nbsp;4<BR>FOLLOWUP_NAME:&nbsp;&nbsp;MachineOwner<BR>MODULE_NAME:&nbsp;myfault<BR>IMAGE_NAME:&nbsp;&nbsp;myfault.sys<BR>DEBUG_FLR_IMAGE_TIMESTAMP:&nbsp;&nbsp;43774e1d<BR>SYMBOL_NAME:&nbsp;&nbsp;myfault+403<BR>FAILURE_BUCKET_ID:&nbsp;&nbsp;0xD1_myfault+403<BR>BUCKET_ID:&nbsp;&nbsp;0xD1_myfault+403<BR>Followup:&nbsp;MachineOwner<BR>//以上几段看名字就知道了，是以上信息的重复没有多大价值。</P>
<P><BR>四。总结<BR>&nbsp;&nbsp;&nbsp;&nbsp;通过以上的分析，知道了蓝屏的原因是Bugcheck&nbsp;D1引起的，是由于驱动程序读操作了过高的IRQL引起的。也知道了这个引发蓝屏的驱动程序是myfault.sys，属于notmyfaulf.exe的进程。还知道了蓝屏前bug程序myfault.sys的调用情况等多个有用信息，接着就可以在myfault.sys源程序中进行bug修改了。&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</P>
页: [1]
查看完整版本: Windbg核心调试之dump分析