windbg分析異常崩潰(翻譯自自帶幫助)

幫助原文(英文):http://www.dbgtech.net/windbghelp/index.html
Windows的調試工具
使用!"analyze "擴展命令
調試一個崩潰的目標計算機或應用程序的第一步是使用 !analyze 擴展命令。

這個擴展可以執行大量的自動分析。這個分析的結果顯示在調試器命令窗口中。

你應該使用-v選項,以獲得完全節制的數據顯示。關於其他選項的詳情,請參見!!分析參考頁。

本主題包含。

一個用戶模式的 !analyze -v 示例

內核模式的 !analyze -v 示例

跟進字段和triage.ini文件

其他的!分析技術

一個用戶模式的 !analyze -v 例子
在這個例子中,調試器被連接到一個遇到異常的用戶模式應用程序上。

0:000> !analyze -v


  • 異常分析 *

調試器SolutionDb Connection::Open failed 80004005

如果您連接到互聯網,調試器試圖訪問由微軟維護的崩潰解決方案數據庫。在這種情況下,顯示了一條錯誤信息,表明你的機器無法訪問互聯網,或者網站無法工作。

FAULTING_IP。
ntdll! PropertyLengthAsVariant+73
77f97704 cc int 3

FAULTING_IP字段顯示故障發生時的指令指針。

EXCEPTION_RECORD: ffffffff -- (.exr ffffffffffffff)
ExceptionAddress: 77f97704 (ntdll!PropertyLengthAsVariant+0x00000073)
異常代碼。80000003 (中斷指令異常)
異常標誌。00000000
NumberParameters: 3
參數[0]: 00000000
Parameter[1]: 00010101
參數[2]: ffffffff

EXCEPTION_RECORD字段顯示了這次崩潰的異常記錄。這個信息也可以通過使用.exr(顯示異常記錄)命令來查看。

BUGCHECK_STR: 80000003

BUGCHECK_STR字段顯示了異常代碼。這個名字是個錯誤的說法--BUGCHECK這個詞實際上表示的是內核模式的崩潰。在用戶模式的調試中,異常代碼將被顯示--在這個例子中,是0x80000003。

default_bucket_id: application_fault

DEFAULT_BUCKET_ID字段顯示了這個故障所屬的一般故障類別。

PROCESS_NAME: MyApp.exe

PROCESS_NAME字段指定了引發異常的進程的名稱。

LAST_CONTROL_TRANSFER:從01050963到77f97704

LAST_CONTROL_TRANSFER字段顯示了堆棧中的最後一次調用。在這個例子中,地址爲0x01050963的代碼在0x77F97704處調用了一個函數。你可以用ln(List Nearest Symbols)命令使用這些地址來確定這些地址所在的模塊和函數。

STACK_TEXT:
0006b9dc 01050963 00000000 0006ba04 000603fd ntdll! PropertyLengthAsVariant+0x73
0006b9f0 010509af 00000002 0006ba04 77e1a449 MyApp!FatalErrorBox+0x55 [D:\source_files\MyApp\util.c @ 541]
0006da04 01029f4e 01069850 0000034f 01069828 MyApp!ShowAssert+0x47 [D:\source_files\MyApp\util.c @ 579] 。
0006db6c 010590c3 000e01ea 0006fee4 0006feec MyApp!SelectColor+0x103 [D:\source_files\MyApp\colors.c @ 849] 。
0006fe04 77e11d0a 000e01ea 00000111 0000413c MyApp!MainWndProc+0x1322 [D:\source_files\MyApp\MyApp.c @ 1031] 。
0006fe24 77e11bc8 01057da1 000e01ea 00000111 USER32!UserCallWinProc+0x18
0006feb0 77e172b4 0006fee4 00000001 010518bf USER32!DispatchMessageWorker+0x2d0
0006febc 010518bf 0006fee4 00000000 01057c5d USER32!DispatchMessageA+0xb
0006fec8 01057c5d 0006fee4 77f82b95 77f83920 MyApp!ProcessQCQPMessage+0x3b [D:\source_files\MyApp\util.c @ 2212] 。
0006ff70 01062cbf 00000001 00683ed8 00682b88 MyApp!main+0x1e6 [D:\source_files\MyApp\MyApp.c @ 263]
0006ffc0 77e9ca90 77f82b95 77f83920 7ffdf000 MyApp!mainCRTStartup+0xff [D:\source_files\MyApp\crtexe.c @ 338)
0006fff0 00000000 01062bc0 00000000 000000c8 KERNEL32!BaseProcessStart+0x3d

STACK_TEXT字段顯示了出錯組件的堆棧跟蹤。

FOLLOWUP_IP。
MyApp!FatalErrorBox+55
01050963 5e pop esi

FOLLOWUP_NAME: dbg

SYMBOL_NAME。 MyApp!FatalErrorBox+55

MODULE_NAME: モンクレール_NAME: MyApp

IMAGE_NAME。 MyApp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 383490a9

當 !analyze 確定了可能導致錯誤的指令時,它將在 FOLLOWUP_IP 字段中顯示。SYMBOL_NAME、MODULE_NAME、IMAGE_NAME和DBG_FLR_IMAGE_TIMESTAMP字段顯示與該指令對應的符號、模塊、圖像名稱和圖像時間戳。

STACK_COMMAND: .ecxr ; kb

STACK_COMMAND字段顯示用於獲得STACK_TEXT的命令。你可以用這個命令來重複這個堆棧跟蹤顯示,或者改變它來獲得相關的堆棧信息。

BUCKET_ID: 80000003_MyApp!FatalErrorBox+55

BUCKET_ID: 80000003_MyApp!FatalErrorBox+55

BUCKET_ID字段顯示了當前故障所屬的具體故障類別。這個類別有助於調試器確定在分析輸出中顯示哪些其他信息。

跟進: dbg

關於FOLLOWUP_NAME和Followup字段的信息,見The Followup Field and the triage.ini File。

還有其他各種可能出現的字段。

如果控制被轉移到一個無效的地址,那麼FAULTING_IP字段將包含這個無效的地址。FAILED_INSTRUCTION_ADDRESS字段代替了FOLLOWUP_IP字段,將顯示從這個地址反彙編的代碼,儘管這個反彙編可能毫無意義。在這種情況下,SYMBOL_NAME、MODULE_NAME、IMAGE_NAME和DBG_FLR_IMAGE_TIMESTAMP字段將指這個指令的調用者。
如果處理器發生錯誤,你可能會看到SINGLE_BIT_ERROR、TWO_BIT_ERROR或POSSIBLE_INVALID_CONTROL_TRANSFER字段。
如果內存損壞似乎已經發生,CHKIMG_EXTENSION字段將指定應該用來調查的!!Chkimg擴展命令。
內核模式的 !analyze -v 示例
在這個例子中,調試器被連接到一臺剛剛崩潰的計算機上。

kd> !analyze -v


  • 錯誤檢查分析 *

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
試圖訪問一個可分頁的(或完全無效的)地址。
中斷請求級別(IRQL)太高。 這通常是
這通常是由於驅動程序使用了不適當的地址造成的。
如果內核調試器可用,可以得到堆棧回溯。

顯示的第一個元素顯示了錯誤檢查代碼和關於這種類型的錯誤檢查的信息。一些顯示的文字可能不適用於這個特定的實例。關於每個錯誤檢查的更多細節,見錯誤檢查代碼參考部分。

參數。
Arg1: 00000004, 被引用的內存
Arg2: 00000002,IRQL
Arg3: 00000001,數值0=讀操作,1=寫操作
Arg4: f832035c, 引用內存的地址

接下來顯示錯誤檢查參數。它們後面都有一個描述。例如,第三個參數是1,後面的註釋解釋說,這表示一個寫操作失敗。

調試細節。

WRITE_ADDRESS: 00000004 Nonpaged pool

current_irql: 2

接下來的幾個字段根據崩潰的性質不同而不同。在這種情況下,我們看到WRITE_ADDRESS和CURRENT_IRQL字段。這些只是重述了錯誤檢查參數中顯示的信息。通過比較語句 "Nonpaged pool "和錯誤檢查文本 "an attempt was made to access a pagable (or completely invalid) address",我們可以看到該地址是無效的。本例中的無效地址是0x00000004。

FAULTING_IP:
USBPORT!USBPORT_BadRequestFlush+7c
f832035c 894204 mov [edx+0x4],eax

FAULTING_IP字段顯示故障發生時的指令指針。

default_bucket_id: driver_fault

DEFAULT_BUCKET_ID字段顯示了這個故障所屬的一般故障類別。

BUGCHECK_STR:0xD1

BUGCHECK_STR字段顯示錯誤檢查代碼,我們已經看到了。在某些情況下會附加額外的分流信息。

TRAP_FRAME: f8950dfc -- (.trap fffffffff8950dfc)
.trap fffffffff8950dfc
ErrCode = 00000002
eax=81cc86dc ebx=81cc80e0 ecx=81e55688 edx=00000000 esi=81cc8028 edi=8052cf3c
eip=f832035c esp=f8950e70 ebp=f8950e90 iopl=0 nv up ei pl nz ac po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010216
USBPORT!USBPORT_BadRequestFlush+7c:
f832035c 894204 mov [edx+0x4],eax ds:0023:000004????????
.陷阱
重置默認上下文

TRAP_FRAME字段顯示這次崩潰的陷阱幀。這個信息也可以通過使用.trap(顯示陷阱幀)命令來查看。

LAST_CONTROL_TRANSFER:從f83206e0到f832035c

LAST_CONTROL_TRANSFER字段顯示堆棧上的最後一次調用。在這個例子中,地址爲0xF83206E0的代碼調用了0xF832035C的函數。你可以使用ln(List Nearest Symbols)命令來確定這些地址所在的模塊和函數。

STACK_TEXT:
f8950e90 f83206e0 024c7262 00000000 f8950edc USBPORT!USBPORT_BadRequestFlush+0x7c
f8950eb0 804f5561 81cc8644 81cc8028 6d9a2f30 USBPORT!USBPORT_DM_TimerDpc+0x10c
f8950fb4 804f5644 6e4be98e 00000000 ffdff000 nt!KiTimerListExpire+0xf3
f8950fe0 8052c47c 8053cf20 00000000 00002e42 nt!KiTimerExpiration+0xb0
f8950ff4 8052c16a efdefd44 00000000 00000000 nt!KiRetireDpcList+0x31

STACK_TEXT字段顯示了故障組件的堆棧跟蹤。
FOLLOWUP_IP。
USBPORT!USBPORT_BadRequestFlush+7c
f832035c 894204 mov [edx+0x4],eax

FOLLOWUP_IP字段顯示了可能導致錯誤的指令的反彙編。

FOLLOWUP_NAME: usbtri

SYMBOL_NAME: USBPORT!USBPORT_BadRequestFlush+7c

MODULE_NAME: USBPORT

IMAGE_NAME: USBPORT.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 3b7d868b

SYMBOL_NAME、MODULE_NAME、IMAGE_NAME和DBG_FLR_IMAGE_TIMESTAMP字段顯示了與此指令(如果有效)或與此指令的調用者(如果無效)相對應的符號、模塊、圖像和圖像時間戳。

STACK_COMMAND: .trap fffffffff8950dfc ; kb

STACK_COMMAND字段顯示了用於獲得STACK_TEXT的命令。你可以用這個命令來重複這個堆棧跟蹤顯示,或者改變它來獲得相關的堆棧信息。

BUCKET_ID: 0xD1_W_USBPORT!USBPORT_BadRequestFlush+7c

BUCKET_ID字段顯示了當前故障所屬的具體故障類別。這個類別有助於調試器確定在分析輸出中顯示哪些其他信息。

internal_solution_text: http://oca.microsoft.com/resredir.asp?sid=62&State=1

如果您連接到互聯網,調試器會嘗試訪問由微軟維護的崩潰解決方案數據庫。這個數據庫包含了大量的網頁鏈接,這些網頁都有關於已知錯誤的信息。如果發現與你的問題相匹配,INTERNAL_SOLUTION_TEXT字段將顯示一個你可以訪問的URL,以獲取更多信息。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章