windbg 除錯崩潰例項 2 則
察看本文應用於的產品
本頁
概要
使用 Windbg.exe 開啟轉儲檔案
使用 Windbg.exe 確定異常堆疊
參考
展開全部 | 關閉全部
概要
沒有異常處理程式定義處理引發的異常時,將呼叫該 UnhandledExceptionFilter 函式。 通常,該函式會將異常傳遞給在 Ntdll.dll 為文...
沒有異常處理程式定義處理引發的異常時,將呼叫該 UnhandledExceptionFilter 函式。 通常,該函式會將異常傳遞給在 Ntdll.dll 為檔案其中捕獲,並嘗試處理設定。
在程序的記憶體快照所在某些情況下,可以看到鎖定點儲存到執行緒的執行緒的呼叫 UnhandledExceptionFilter 函式。 在這的種情況下您可以按照本文以確定導致此異常的 DLL。
回到頂端
開啟安裝除錯程式,資料夾,然後雙擊 Windbg.exe 啟動偵錯程式。
在 檔案 選單上單擊 開啟的崩潰轉儲 (或按 Ctrl+D),然後選擇要檢視該轉儲檔案。
回到頂端
在命令提示符下鍵入 ~ * kb 以列出所有程序中的執行緒。
標識對函式呼叫的執行緒 Kernel32! UnhandledExceptionFilter 。 它類似於以下:
120 id: f0f0f0f0.a1c Suspend: 1 Teb 7ff72000 Unfrozen
ChildEBP RetAddr Args to Child
09a8f334 77eb9b46 0000244c 00000001 00000000 ntdll!ZwWaitForSingleObject+0xb [i386/usrstubs.asm @ 2004]
09a8f644 77ea7e7a 09a8f66c 77e861ae 09a8f674 KERNEL32!UnhandledExceptionFilter+0x2b5
[D:/nt/private/windows/base/client/thread.c @ 1753]
09a8ffec 00000000 787bf0b8 0216fe94 00000000 KERNEL32!BaseThreadStart+0x65 [D:/nt/private/windows/base/client/support.c @ 453]
切換到該執行緒 (在本例中,該執行緒是"~120s")。
在第一個引數的指定位置顯示記憶體內容 Kernel32! UnhandledExceptionFilter 通過 新增 第一個引數 。 此指向 EXCEPTION_POINTERS 結構
0:120> dd 09a8f66c
09a8f66c 09a8f738 09a8f754 09a8f698 77f8f45c
09a8f67c 09a8f738 09a8ffdc 09a8f754 09a8f710
09a8f68c 09a8ffdc 77f8f5b5 09a8ffdc 09a8f720
09a8f69c 77f8f3fa 09a8f738 09a8ffdc 09a8f754
09a8f6ac 09a8f710 77e8615b 09a8fad4 00000000
09a8f6bc 09a8f738 74a25336 09a8f6e0 09a8f910
09a8f6cc 01dc8ad8 0d788918 00000001 018d1f28
09a8f6dc 00000001 61746164 7073612e 09a8f71c
第一個 DWORD 代表異常記錄。 若要獲取有關異常的型別資訊,請請在命令提示符處執行以下:
.exr first DWORD from step 6
0:120> .exr 09a8f738
ExceptionAddress: 78011f32 (MSVCRT!strnicmp+0x00000092)
ExceptionCode: c0000005
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000000
Attempt to read from address 00000000
第二個 DWORD 是上下文記錄。 若要獲取上下文的資訊,請在命令提示符處執行以下:
.cxr second DWORD from step 6
0:120> .cxr 09a8f754
eax=027470ff ebx=7803cb28 ecx=00000000 edx=00000000 esi=00000000 edi=09a8fad4
eip=78011f32 esp=09a8fa20 ebp=09a8fa2c iopl=0 nv up ei ng nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010286
MSVCRT!strnicmp+92:
78011f32 8a06 mov al,[esi]
執行 kv 命令獲得實際的異常的呼叫堆疊。 這有助於您識別可能未被處理正確的過程中實際問題
0:120> kv
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
09a8fa2c 780119ab 09a8fad4 00000000 09a8faa8 MSVCRT!strnicmp+0x92
09a8fa40 7801197c 09a8fad4 00000000 6d7044fd MSVCRT!stricmp+0x3c
09a8fa80 6e5a6ef6 09a8fad4 2193d68d 00e5e298 MSVCRT!stricmp+0xd
09a8fa94 6d7043bf 09a8fad4 09a8faa8 0000001c IisRTL!CLKRHashTable::FindKey+0x59 (FPO: [2,0,1])
09a8faac 749fc22d 09a8fad4 01d553b0 0000001c ISATQ!CDirMonitor::FindEntry+0x1e
(FPO: [Non-Fpo]) [D:/nt/private/inet/iis/svcs/infocomm/atq/dirmon.cpp @ 884]
09a8fac4 749fd1cb 09a8fad4 09a8fb10 525c3a46 asp!RegisterASPDirMonitorEntry+0x6e
(FPO: [EBP 0x09a8fb08] [2,0,4]) [D:/nt/private/inet/iis/svcs/cmp/asp/aspdmon.cpp @ 534]
09a8fb08 749fcdd6 00000000 09a8fcbc 018d1f28 asp!CTemplateCacheManager::RegisterTemplateForChangeNotification+0x8a
(FPO: [Non-Fpo]) [D:/nt/private/inet/iis/svcs/cmp/asp/cachemgr.cpp @ 621]
09a8fb3c 74a08bfe 00000000 000000fa 74a30958 asp!CTemplateCacheManager::Load+0x382
(FPO: [Non-Fpo]) [D:/nt/private/inet/iis/svcs/cmp/asp/cachemgr.cpp @ 364]
09a8fc68 74a0d4c9 04c12518 018d1f28 09a8fcbc asp!LoadTemplate+0x42
(FPO: [Non-Fpo]) [D:/nt/private/inet/iis/svcs/cmp/asp/exec.cpp @ 1037]
09a8fcc0 74a2c3e5 00000000 0637ee38 09a8fd58 asp!CHitObj::ViperAsyncCallback+0x3e8
(FPO: [Non-Fpo]) [D:/nt/private/inet/iis/svcs/cmp/asp/hitobj.cpp @ 2414]
09a8fcd8 787c048a 00000000 77aa1b03 01e91ed8 asp!CViperAsyncRequest::OnCall+0x3f
(FPO: [Non-Fpo]) [D:/nt/private/inet/iis/svcs/cmp/asp/viperint.cpp @ 194]
09a8fce0 77aa1b03 01e91ed8 77a536d8 00000000 COMSVCS!STAActivityWorkHelper+0xa
(FPO: [1,0,0])
09a8fd24 77aa1927 000752f8 000864dc 787c0480 ole32!EnterForCallback+0x6a
(FPO: [Non-Fpo]) [D:/nt/private/ole32/com/dcomrem/crossctx.cxx @ 1759]
09a8fe50 77aa17ea 000864dc 787c0480 01e91ed8 ole32!SwitchForCallback+0x12b
(FPO: [Non-Fpo]) [D:/nt/private/ole32/com/dcomrem/crossctx.cxx @ 1644]
09a8fe78 77aa60c1 000864dc 787c0480 01e91ed8 ole32!PerformCallback+0x50
(FPO: [Non-Fpo]) [D:/nt/private/ole32/com/dcomrem/crossctx.cxx @ 1559]
09a8fed4 77aa5fa6 04f2b4c0 787c0480 01e91ed8 ole32!CObjectContext::InternalContextCallback+0xf5
(FPO: [Non-Fpo]) [D:/nt/private/ole32/com/dcomrem/context.cxx @ 3866]
09a8fef4 787bd3c3 04f2b4c0 787c0480 01e91ed8 ole32!CObjectContext::DoCallback+0x1a
(FPO: [Non-Fpo]) [D:/nt/private/ole32/com/dcomrem/context.cxx @ 3746]
09a8ff24 787bf373 0216fb3c 00000007 09a8ffec COMSVCS!STAActivityWork::DoWork+0x73
(FPO: [0,4,2])
09a8ffb4 77e8758a 0216fe94 0216fb3c 00000007 COMSVCS!STAThread::STAThreadWorker+0x2bb
(FPO: [EBP 0x09a8ffec] [1,31,4])
09a8ffec 00000000 787bf0b8 0216fe94 00000000 KERNEL32!BaseThreadStart+0x52
(FPO: [Non-Fpo]) [D:/nt/private/windows/base/client/support.c @ 451]
=========================
1、崩潰發生過程
程式執行過程中,崩潰,彈出mssagebox,提示R6034錯誤。檢視r6034錯誤:表示執行庫的manifest設定不正確,
2、提取dump過程
1)檢視工作管理員,崩潰的程序還在。判定可以用Windbg截獲dump
2)開啟windbg,file--attach to a process,選擇崩潰程序如test.exe;
3)使用命令 .dump /mf d:/test.dmp
4)確認提取成功:檢視在d盤根目錄下是否有test.dmp檔案。
3、分析崩潰原因
1) 開啟windbg,file--open crash dump ,開啟dump檔案test.dmp
2) 檢視崩潰檔案版本:使用lm v m test* 獲得崩潰程序檔案test.exe檔案資訊
1. 0:008> lm v m test*
2. start end module name
3. 00400000 00526000 test (deferred)
4. Image path: C:/Program Files (x86)/test/test.exe
5. Image name: test.exe
6. Timestamp: Wed Dec 10 17:29:43 2008 (493F8C07)
7. CheckSum: 0012ACC3
8. ImageSize: 00126000
9. File version: 2008.12.10.34
10. Product version: 1.0.1126.34
11. File flags: 0 (Mask 3F)
12. File OS: 40004 NT Win32
13. File type: 2.0 Dll
14. File date: 00000000.00000000
15. Translations: 0000.04b0
16. InternalName: test
17. ProductVersion: 1,0,1126,34
18. FileVersion: 2008,12,10,34
3)載入對應符號pdb,根據Timestamp: Wed Dec 10 17:29:43 2008 (493F8C07),找到對應的pdb檔案,選擇file--symble file path 將pdb檔案路徑加入。
4)分析
1. 0:008> ~*k 看所有執行緒的堆疊
2. 0 Id: 990.c38 Suspend: 1 Teb: 7efdd000 Unfrozen
3. ChildEBP RetAddr
4. WARNING: Stack unwind information not available. Following frames may be wrong.
5. 0017d878 75ae81c8 user32!WaitMessage+0x15
6. 0017d8ac 75af478a user32!GetCursorFrameInfo+0x7c
7. 0017d958 75af46f5 user32!SetMessageQueue+0x4e8
8. 0017dab0 75b2d2c3 user32!SetMessageQueue+0x453
9. 0017db0c 75b2d342 user32!MessageBoxTimeoutW+0x52
10. 0017db40 75b2d390 user32!MessageBoxTimeoutA+0x76
11. 0017db60 75b2d3d5 user32!MessageBoxExA+0x1b
12. 0017db7c 718f986e user32!MessageBoxA+0x18
13. 0017dbc0 718f1c2c msvcr80!__crtMessageBoxA+0x1b4
14. 0017dbe4 718f2217 msvcr80!_NMSG_WRITE+0x162
15. 0017dc20 718f2348 msvcr80!__p__winver+0x13c
16. 0017dc30 776dfcc0 msvcr80!_CRTDLL_INIT+0x1d
17. 0017dc50 776e9b28 ntdll!RtlReleasePebLock+0x28
18. 0017dd48 776e95ae ntdll!LdrFindResourceDirectory_U+0x9bf
19. 0017dfcc 777029db ntdll!LdrFindResourceDirectory_U+0x445
20. 0017e250 765e4d50 ntdll!RtlDestroyQueryDebugBuffer+0x48d5
21. 0017e2b4 765e4dca kernel32!LoadLibraryExW+0x112
22. 0017e2c8 004265e9 kernel32!LoadLibraryW+0x11 此處為程式到系統程式的一個臨界點。分析首先從這裡分析起。
23. 0017e524 00426e43 test!KLoadDllUtility::AutoSearchLoadLibrary+0x5f [e:/kloaddllutility.h @ 32]
24. 0017e554 00426877 test!KPopSupport::InitializeKPopSystem+0x29 [e:/popimport.cpp @ 1037]
25. ……………………
分析執行緒堆疊,一般情況下,出現messagebox都是不正常的。由於此次崩潰系統有彈出messagebox,而剛好第一個執行緒堆疊有messagebox相關字眼,所以懷疑是第一個執行緒堆疊出現問題。
1. 0:008> dd 0017e2c8 dd (dd表示以四個位元組的方式檢視ebp資訊。)
2. 0017e2c8 0017e524 004265e9 0017e314 004d3578 (0017e524表示上一個函式的ebp; 004265e9 表示函式返回地址 0017e314 表示函式的引數 檢視msdn,loadlibary只有一個引數,並且引數是一個字串,所以只有0017e314有效,並且表示一個地址。)
3. 0017e2d8 02724fd8 00000000 00000000 00000000
4. 0017e2e8 00000000 026fc1a8 00000000 00000000
5. 0017e2f8 00000000 00000008 0000000f 00000000
6. 0017e308 00000000 00000000 00000000 003a0063
7. 0017e318 0050005c 006f0072 00720067 006d0061
8. 0017e328 00460020 006c0069 00730065 00280020
9. 0017e338 00380078 00290036 004b005c 006e0069
10. 0:008> db 0017e314 (db以位元組的方式檢視引數內容)
11. 0017e314 63 00 3a 00 5c 00 50 00-72 00 6f 00 67 00 72 00 c.:./.P.r.o.g.r.
12. 0017e324 61 00 6d 00 20 00 46 00-69 00 6c 00 65 00 73 00 a.m. .F.i.l.e.s.
13. 0017e334 20 00 28 00 78 00 38 00-36 00 29 00 5c 00 4b 00 .(.x.8.6.)./.e.
14. 0017e344 69 00 6e 00 67 00 73 00-6f 00 66 00 74 00 5c 00 i.r.g.s.o.f.t./.
15. 0017e354 4b 00 69 00 6e 00 67 00-73 00 6f 00 66 00 74 00 e.i.n.g.s.o.f.t.
16. 0017e364 20 00 49 00 6e 00 74 00-65 00 72 00 6e 00 65 00 .I.n.t.e.r.n.e.
17. 0017e374 74 00 20 00 53 00 65 00-63 00 75 00 72 00 69 00 t. .h.e.c.u.r.i.
18. 0017e384 74 00 79 00 20 00 32 00-30 00 30 00 38 00 5c 00 t.y. .2.0.0.8./.
19. 0:008> db (db繼續顯示,使內容顯示完全)
20. 0017e394 53 00 43 00 4f 00 4d 00-2e 00 64 00 6c 00 6c 00 S.C.O.M...d.l.l.
21. 0017e3a4 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
22. 0017e3b4 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
23. 0017e3c4 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
24. 0017e3d4 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
25. 0017e3e4 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
26. 0017e3f4 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
27. 0017e404 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ...............
4、分析結果總結
分析發現 :呼叫了scom.dll.根據對產品功能的瞭解,test不會呼叫該dll,說明調用出錯,調錯了檔案,接下來需要做的是理清test呼叫流程,修改bug啦。
至於為啥錯誤id為r6034,是因為scom.dll需要執行庫,而test程序內部未設定。
From:http://blog.csdn.net/kingpcn/article/details/6319869