windows 蓝屏 DMP文件分析

 

windbg 更详细请看http://support.icafe8.com/technologynews/focus/932.html   在蓝屏瞬间，系统会形成一个存储器转储文件——死机瞬间的内存映像，通常是C：WINDOWSMinidmp 目录下的DMP文件，它就是我们要找的救星，分析它就能查找到问题所在。 “救星”帮忙，看清 DMP文件需要使用MS提供的WinDbg工具来分析：第一步：设置符号文件路径，点击”Files→Symbol File Path“，输入”SRV*DownstreamStore*http://msdl.microsoft.com/download/symbols“(微软提供的一个网络上的symbol服务器)。 第二步：打开minidump文件进行分析，点击”File→Open Crash Dump“，如打开C：WINDOWSMinidumpMini08100701.dmp。根据前面设置的符号文件地址，软件会自动连接到微软网站，得到符号信息。 当下面的命令行运行出现!analyze-v(常用的一个分析命令)蓝色命令时，点击它就将得到DMP文件详细的信息。从中找到蓝色字母部分就是什么软件引起的蓝屏了。【以上来自《电脑爱好者》24期】 下面是一段例子： Dump文件的分析     当按上面的方法运行后，windbg输出了以下内容： *** Fatal System Error: 0x000000d1                        (0xE1147008,0x0000001C,0x00000000,0xFBE93403)   Break instruction exception - code 80000003 (first chance)   A fatal system error has occurred.   Debugger entered on first try; Bugcheck callbacks have not been   invoked.   A fatal system error has occurred. ******************************************************************************* *                                                                             * *                        Bugcheck Analysis                                    * *                                                                             * ******************************************************************************* Use !analyze -v to get detailed debugging information. 2.BugCheck D1, {e1147008, 1c, 0, fbe93403} *** ERROR: Module load completed but symbols could not be loaded for myfault.sys 3.Probably caused by : myfault.sys ( myfault+403 ) Followup: MachineOwner --------- nt!RtlpBreakWithStatusInstruction: 80527da8 cc              int     3 Kd:>  上面这一段，有用的信息，如1和2两段，说明的是一个问题，都指明了BugCheck是D1，并给了四个参数，这里的D1可以在windbg 文档的Bug Check Code Reference中查出其具体含义，也可用!analyze –show D1命令查出。3说明引起的原因是myfault.sys 模块。接着在kd后输入!analyze –v命令，这个命令是详细列出dump文件的信息。 windbg输出如下： kd> !analyze -v ******************************************************************************* *                                                                             * *                        Bugcheck Analysis                                    * *                                                                             * ******************************************************************************* DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)  //指明Bugcheck 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       //上面的Arg1. CURRENT_IRQL:  1c       //上面的Arg2 FAULTING_IP:     //指出发生错误时所执行的指令 myfault+403 fbe93403 8b06            mov     eax,dword ptr [esi] DEFAULT_BUCKET_ID:  DRIVER_FAULT   //指出错误类型，是驱动错误 BUGCHECK_STR:  0xD1   //bugcheck索引，可查windbg文档，也可!analyze –show D1 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: //反映了错误前堆栈中函数调用情况，最下面的0x7c801671处函数调用ntdll中的ZwDeviceIoControlFile，接着 调用了ntdll中的KiFastSystemCallRet，再接着调用了nt（这里的nt指Ntoskrnl）中的KiFastCallEntry，一直到myfault+0x403， 发生异常。 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 //以上几段看名字就知道了，是以上信息的重复没有多大价值。 四。总结     通过以上的分析，知道了蓝屏的原因是Bugcheck D1引起的，是由于驱动程序读操作了过高的IRQL引起的。也知道了这个引发 蓝屏的驱动程序是myfault.sys，属于notmyfaulf.exe的进程。还知道了蓝屏前bug程序myfault.sys的调用情况等多个有用信息， 接着就可以在myfault.sys源程序中进行bug修改了。

windows 蓝屏 DMP文件分析

2011年03月29日 星期二 下午 07:41

在蓝屏瞬间，系统会形成一个存储器转储文件——死机瞬间的内存映像，通常是C：WINDOWSMinidmp 目录下的DMP文件，它就是我们要找的救星，分析它就能查找到问题所在。 “救星”帮忙，看清 DMP文件需要使用MS提供的WinDbg工具来分析：第一步：设置符号文件路径，点击”Files→Symbol File Path“，输入”SRV*DownstreamStore*http://msdl.microsoft.com/download/symbols“(微软提供的一个网络上的symbol服务器)。 第二步：打开minidump文件进行分析，点击”File→Open Crash Dump“，如打开C：WINDOWSMinidumpMini08100701.dmp。根据前面设置的符号文件地址，软件会自动连接到微软网站，得到符号信息。 当下面的命令行运行出现!analyze-v(常用的一个分析命令)蓝色命令时，点击它就将得到DMP文件详细的信息。从中找到蓝色字母部分就是什么软件引起的蓝屏了。【以上来自《电脑爱好者》24期】 下面是一段例子： Dump文件的分析     当按上面的方法运行后，windbg输出了以下内容： *** Fatal System Error: 0x000000d1                        (0xE1147008,0x0000001C,0x00000000,0xFBE93403)   Break instruction exception - code 80000003 (first chance)   A fatal system error has occurred.   Debugger entered on first try; Bugcheck callbacks have not been   invoked.   A fatal system error has occurred. ******************************************************************************* *                                                                             * *                        Bugcheck Analysis                                    * *                                                                             * ******************************************************************************* Use !analyze -v to get detailed debugging information. 2.BugCheck D1, {e1147008, 1c, 0, fbe93403} *** ERROR: Module load completed but symbols could not be loaded for myfault.sys 3.Probably caused by : myfault.sys ( myfault+403 ) Followup: MachineOwner --------- nt!RtlpBreakWithStatusInstruction: 80527da8 cc              int     3 Kd:>  上面这一段，有用的信息，如1和2两段，说明的是一个问题，都指明了BugCheck是D1，并给了四个参数，这里的D1可以在windbg 文档的Bug Check Code Reference中查出其具体含义，也可用!analyze –show D1命令查出。3说明引起的原因是myfault.sys 模块。接着在kd后输入!analyze –v命令，这个命令是详细列出dump文件的信息。 windbg输出如下： kd> !analyze -v ******************************************************************************* *                                                                             * *                        Bugcheck Analysis                                    * *                                                                             * ******************************************************************************* DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)  //指明Bugcheck 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       //上面的Arg1. CURRENT_IRQL:  1c       //上面的Arg2 FAULTING_IP:     //指出发生错误时所执行的指令 myfault+403 fbe93403 8b06            mov     eax,dword ptr [esi] DEFAULT_BUCKET_ID:  DRIVER_FAULT   //指出错误类型，是驱动错误 BUGCHECK_STR:  0xD1   //bugcheck索引，可查windbg文档，也可!analyze –show D1 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: //反映了错误前堆栈中函数调用情况，最下面的0x7c801671处函数调用ntdll中的ZwDeviceIoControlFile，接着 调用了ntdll中的KiFastSystemCallRet，再接着调用了nt（这里的nt指Ntoskrnl）中的KiFastCallEntry，一直到myfault+0x403， 发生异常。 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 //以上几段看名字就知道了，是以上信息的重复没有多大价值。 四。总结     通过以上的分析，知道了蓝屏的原因是Bugcheck D1引起的，是由于驱动程序读操作了过高的IRQL引起的。也知道了这个引发 蓝屏的驱动程序是myfault.sys，属于notmyfaulf.exe的进程。还知道了蓝屏前bug程序myfault.sys的调用情况等多个有用信息， 接着就可以在myfault.sys源程序中进行bug修改了。     http://www.xhjdn.com/news/html/?299.html