Windbg崩潰轉儲分析

我很難從使用ProcDump創建的崩潰轉儲中獲取任何有意義的信息，但我確定它與我一直看到的隨機崩潰有關。Windbg崩潰轉儲分析

我有一個在Windows 7 64位上運行的VB6應用程序。每過一段時間，它就會崩潰，在錯誤日誌中留下一個條目，該條目與ntdll.dll錯誤，但沒有提供更多信息。所以，我一直在運行SysInternals的ProcDump進程來爲我自動創建崩潰轉儲。

我一直無法重新創建內部的崩潰，所以我很確定，如果我有一個轉儲，它會告訴我什麼是問題。然而，在大部分時間運行之後，我發現ProcDump已經寫了幾個轉儲文件，儘管程序仍然運行良好。它似乎指向ntdll.dll的問題，但我不知道從哪裏開始爲此應用修復程序。

在垃圾場的一個運行!analyze -v給了我下面的：

******************************************************************************* 
*                    * 
*      Exception Analysis         * 
*                    * 
******************************************************************************* 


FAULTING_IP: 
+0 
00000000 ??    ??? 

EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff) 
ExceptionAddress: 00000000 
    ExceptionCode: 80000003 (Break instruction exception) 
    ExceptionFlags: 00000000 
NumberParameters: 0 

FAULTING_THREAD: 000007c8 

PROCESS_NAME: application.exe 

ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached. 

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid 

NTGLOBALFLAG: 0 

APPLICATION_VERIFIER_FLAGS: 0 

APP: application.exe 

BUGCHECK_STR: APPLICATION_FAULT_STATUS_BREAKPOINT_AFTER_CALL 

PRIMARY_PROBLEM_CLASS: STATUS_BREAKPOINT_AFTER_CALL 

DEFAULT_BUCKET_ID: STATUS_BREAKPOINT_AFTER_CALL 

LAST_CONTROL_TRANSFER: from 7754431f to 7752014d 

STACK_TEXT: 
0382fdf4 7754431f 00000005 035e62c8 00000001 ntdll!ZwWaitForMultipleObjects+0x15 
0382ff88 74cd339a 00000000 0382ffd4 77539ed2 ntdll!TppWaiterpThread+0x33d 
0382ff94 77539ed2 035e6298 74e2a30c 00000000 kernel32!BaseThreadInitThunk+0xe 
0382ffd4 77539ea5 775441f3 035e6298 00000000 ntdll!__RtlUserThreadStart+0x70 
0382ffec 00000000 775441f3 035e6298 00000000 ntdll!_RtlUserThreadStart+0x1b 


STACK_COMMAND: ~0s; .ecxr ; kb 

FOLLOWUP_IP: 
ntdll!ZwWaitForMultipleObjects+15 
7752014d 83c404   add  esp,4 

SYMBOL_STACK_INDEX: 0 

SYMBOL_NAME: ntdll!ZwWaitForMultipleObjects+15 

FOLLOWUP_NAME: MachineOwner 

MODULE_NAME: ntdll 

IMAGE_NAME: ntdll.dll 

DEBUG_FLR_IMAGE_TIMESTAMP: 4ce7ba58 

FAILURE_BUCKET_ID: STATUS_BREAKPOINT_AFTER_CALL_80000003_ntdll.dll!ZwWaitForMultipleObjects 

BUCKET_ID: APPLICATION_FAULT_STATUS_BREAKPOINT_AFTER_CALL_ntdll!ZwWaitForMultipleObjects+15 

WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/BlackJack_exe/1_5_0_0/50227d4e/unknown/0_0_0_0/bbbbbbb4/80000003/00000000.htm?Retriage=1 

Followup: MachineOwner

任何人都可以點我在正確的方向，使這個項目的意義上來說，和我能做些什麼呢？

來源

2012-08-08 Geo Ego

在procdump運行時調試此應用程序的位置？ 'APPLICATION_FAULT_STATUS_BREAKPOINT_AFTER_CALL'似乎表明一個調試器打入了進程，這是procdump捕獲的轉儲。所以這些轉儲不會幫助你，因爲它們不是實際問題的快照。'ProcDump'是一個非常輕量級的工具，您應該嘗試在發生實際問題的地方運行它，然後嘗試分析這些轉儲。 – jcopenha 2012-08-08 20:46:17

我當時沒有調試過。我只是在生產計算機上就地安裝了ProcDump，在啓動時腳本運行（C：\ apps \ procdump.exe -accepteula -e -h -n 10 -t -w application.exe C：\ application.dmp）。所以基本上，我將ProcDump與我們編譯的可執行文件一起運行，隨時捕捉轉儲。所以你說的是這些轉儲基本上是由ProcDump引起的，所以我不需要擔心它們？我試圖捕捉的錯誤絕對是在程序終止時結束的，所以如果它發生在字段中，那就是我試圖獲得的轉儲。 – 2012-08-08 20:55:37

我並不是說你不必擔心他們。只是！分析-v的報告讓我覺得這些並不是真正的崩潰，而是調試器的中斷。我會檢查各個線程的調用堆棧，看看是否有其他異常。 – jcopenha 2012-08-08 21:01:30

爲了確保，我已經在我身邊執行了一些測試，附加到健康流程並製作剛開始流程的轉儲。在所有的情況下，輸出！analyze -v與你的非常相似，除了我的一個更詳細的事實，我認爲它取決於調試器版本。

例如，這裏是連接到剛開始畫圖後，我已經得到的輸出：

******************************************************************************* 
*                    * 
*      Exception Analysis         * 
*                    * 
******************************************************************************* 

GetPageUrlData failed, server returned HTTP status 404 
URL requested:  http://watson.microsoft.com/StageOne/mspaint_exe/6_1_7600_16385/4a5bca29/ntdll_dll/6_1_7601_17725/4ec4aa8e/80000003/00050530.htm?Retriage=1 

FAULTING_IP: 
ntdll!DbgBreakPoint+0 
00000000`76d90530 cc    int  3 

EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff) 
ExceptionAddress: 0000000076d90530 (ntdll!DbgBreakPoint) 
ExceptionCode: 80000003 (Break instruction exception) 
ExceptionFlags: 00000000 
NumberParameters: 1 
Parameter[0]: 0000000000000000 

FAULTING_THREAD: 0000000000000cbc 

DEFAULT_BUCKET_ID: STATUS_BREAKPOINT 

PROCESS_NAME: mspaint.exe 

ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached. 

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid 

EXCEPTION_PARAMETER1: 0000000000000000 

MOD_LIST: <ANALYSIS/> 

NTGLOBALFLAG: 0 

APPLICATION_VERIFIER_FLAGS: 0 

PRIMARY_PROBLEM_CLASS: STATUS_BREAKPOINT 

BUGCHECK_STR: APPLICATION_FAULT_STATUS_BREAKPOINT 

LAST_CONTROL_TRANSFER: from 0000000076e37ef8 to 0000000076d90530 

STACK_TEXT: 


FOLLOWUP_IP: 
ntdll!DbgBreakPoint+0 
00000000`76d90530 cc    int  3 

SYMBOL_STACK_INDEX: 0 

SYMBOL_NAME: ntdll!DbgBreakPoint+0 

FOLLOWUP_NAME: MachineOwner 

MODULE_NAME: ntdll 

IMAGE_NAME: ntdll.dll 

DEBUG_FLR_IMAGE_TIMESTAMP: 4ec4aa8e 

STACK_COMMAND: ~8s ; kb 

FAILURE_BUCKET_ID: STATUS_BREAKPOINT_80000003_ntdll.dll!DbgBreakPoint 

BUCKET_ID: X64_APPLICATION_FAULT_STATUS_BREAKPOINT_ntdll!DbgBreakPoint+0 

WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/mspaint_exe/6_1_7600_16385/4a5bca29/ntdll_dll/6_1_7601_17725/4ec4aa8e/80000003/00050530.htm?Retriage=1 

Followup: MachineOwner 
---------

我也是在這裏ProcDump標誌的解釋採取一看：http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx。它看起來像使用命令行一樣

C:\apps\procdump.exe -accepteula -e -h -n 10 -t -w application.exe

你讓procdump停止懸掛或異常的所有跡象都沒有設置具體的參數，如內存使用數量或CPU使用率procent。

我會建議使用DebugDiag，它提供了很好的用戶界面，您可以在其中配置規則來描述何時應該創建轉儲。下面是我的解釋，如何收集轉儲，當你有過多的內存使用量的問題，或高CPU使用率：

http://kate-butenko.blogspot.com/2012/06/how-to-gather-dump-with-debugdiag.html

，這裏是另一種微細的截屏解釋，如何獲取轉儲在DebugDiag資料爲特定的異常：

http://blogs.msdn.com/b/kaushal/archive/2012/05/09/using-debugdiag-to-capture-a-dump-on-first-chance-exception.aspx

從一套更ligthweight工具，你也可以檢查ADPlus工具（位於C：\ Program Files文件\ Windows調試工具（x64）的˚F以上）。我更喜歡DebugDiag，因爲它允許捕獲特定類型的異常。

來源

2012-08-10 12:23:50 KateButenko

謝謝你的徹底答案！ – 2012-08-10 15:44:46

Windbg崩潰轉儲分析

回答

相關問題