Windbg核心調試之dump分析

鏈 接: http://bbs.pediy.com/showthread.php?threadid=35044 
詳細信息: 


一．Dump文件的產生，意義和類型
    當系統發生錯誤是，最常見的就是藍屏（Blue screen），這時就會在系統目錄下產生一個Dump文件，如MEMORY.DMP 。這個文件的主要意義在於分析系統錯誤發生的原因，以作出解決的方法。
   它可分爲三種類型：
   1.完全內存轉儲。這個文件比較大，和物理內存相當，包含了程序崩潰前系統及用戶模式下的所有信息。
   2.核心內存轉儲。這個文件大小約物理內存的三分之一，主要包含崩潰前系統內核的運行情況。一般爲了分析內核錯誤，就選用這種文件。
   3.小內存轉儲。這個文件小，只有64k，剛好一個頁面文件大小。它包含了相對比較少的信息，主要可用於微軟的在線分析。
   以上三種形式的文件可以在我的電腦——〉鼠標右鍵——〉屬性——〉高級——〉故障及恢復中設置。如下圖：

二。Dump文件的強迫產生
   由於我們也不知道何時會產生一個系統錯誤，從而得到dump文件，所以當練習分析時，可認爲強迫產生一個。一般有以下兩個辦法。
   1.雙機聯調。這裏的雙機可以是物理上的兩臺電腦，也可以是用虛擬機模擬。我想這裏的大多數人應該選擇後者，爲啥？還不是money的問題~_^。當用windbg把被調試機聯上以後，就可以用.crash命令產生一個藍屏，當然之前要在被調試機裏把dump產生的路徑和類型設定好。還有另外一張辦法，是通過修改註冊表後，用鍵盤產生dump，但這種方法哪有第一種來的快，所以就不說了，感興趣的可以查查windbg幫助文檔看看。
   2.單機驅動產生。這種方法，不必用雙機聯調，在本機上就可以辦到。由於驅動深入到了內核，它的要求非常苛刻，一個簡單的除零操作就可引發藍屏。但是驅動的編寫與普通win32 api是有很大不同的，爲了減輕負擔，我直接運用一個現成的程序，是《Microsoft Windows Internals》作者寫的Notmyfault（見附件）。它由Notmyfault.exe和Myfault.sys兩部分組成。正如名字一樣，引發藍屏的不是Notmyfault.exe而是由他加載到內核中的Myfault.sys。如圖:

   我在這裏兩種方法都同時用了，先在虛擬機裏執行Notmyfault，接着windbg立刻檢測到了系統崩潰，並輸出相關信息。 
三。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修改了。
---------  


--------------------------------------------------------------------------------

  ©2000-2007 PEdiy.com All rights reserved. 
By PEDIY