分析WinDbg中的CLR.dmp文件

我有一個在Visual Studio 2008中創建的C＃.NET 3.5應用程序，該應用程序在沒有開發環境的Windows XP SP3（x86）PC上崩潰。分析WinDbg中的CLR.dmp文件

我已經能夠從PC獲取.dmp文件，並將其帶回到我的Windows 64位開發PC並將其加載到WinDbg 6.12中。

但是，我看不到從我的C＃應用程序調用堆棧中的任何代碼。它看起來完全是一個本地調用堆棧。

!analyze -v的結果如下。

我有與.DMP相同的目錄中的相關EXE，DLL和PDB文件。崩潰的可執行文件以調試模式編譯。

我也有視覺工作室 2008，如果這更容易使用。但打開那裏的轉儲文件也只顯示本地調用堆棧，沒有任何代碼。

如何查看CLR調用堆棧？

0:004> !analyze -v 
******************************************************************************* 
*                    * 
*      Exception Analysis         * 
*                    * 
******************************************************************************* 


FAULTING_IP: 
kernel32!RaiseException+53 
7c812afb 5e    pop  esi 

EXCEPTION_RECORD: 0392f018 -- (.exr 0x392f018) 
ExceptionAddress: 7c812afb (kernel32!RaiseException+0x00000053) 
    ExceptionCode: e0434f4d (CLR exception) 
    ExceptionFlags: 00000001 
NumberParameters: 1 
    Parameter[0]: 80070057 

PROCESS_NAME: foo.exe 

ERROR_CODE: (NTSTATUS) 0xe0434f4d - <Unable to get error code text> 

EXCEPTION_CODE: (NTSTATUS) 0xe0434f4d - <Unable to get error code text> 

EXCEPTION_PARAMETER1: 80070057 

MOD_LIST: <ANALYSIS/> 

MANAGED_STACK: !dumpstack -EE 
No export dumpstack found 

MANAGED_BITNESS_MISMATCH: 
Managed code needs matching platform of sos.dll for proper analysis. Use 'x86' debugger. 

ADDITIONAL_DEBUG_TEXT: Followup set based on attribute [Is_ChosenCrashFollowupThread] from Frame:[0] on thread:[PSEUDO_THREAD] 

LAST_CONTROL_TRANSFER: from 79ef2bfc to 7c812afb 

FAULTING_THREAD: ffffffff 

DEFAULT_BUCKET_ID: STACKIMMUNE 

PRIMARY_PROBLEM_CLASS: STACKIMMUNE 

BUGCHECK_STR: APPLICATION_FAULT_STACKIMMUNE_NOSOS_CLR_EXCEPTION 

STACK_TEXT: 
00000000 00000000 foo.exe+0x0 


SYMBOL_NAME: foo.exe 

FOLLOWUP_NAME: MachineOwner 

MODULE_NAME: foo 

IMAGE_NAME: foo.exe 

DEBUG_FLR_IMAGE_TIMESTAMP: 4d5da0cd 

STACK_COMMAND: ** Pseudo Context ** ; kb 

FAILURE_BUCKET_ID: STACKIMMUNE_e0434f4d_foo.exe!Unknown 

BUCKET_ID: APPLICATION_FAULT_STACKIMMUNE_NOSOS_CLR_EXCEPTION_foo.exe 

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

來源

2011-02-25 PaulH

對不使用.NET 4.0的託管程序進行Minidump調試是非常小的喜悅。它以未處理的管理例外進行轟炸。通過編寫AppDomain.CurrentDomain.UnhandedException的事件處理程序並記錄或顯示e.ExceptionObject.ToString（）的值，提高您的診斷可能性。足以診斷絕大多數病例的麻煩原因。 – 2011-02-26 01:22:10

@Hans - 我在try/catch塊中包裝了Program.cs中的代碼，但是這個事件更加簡潔。謝謝。 – PaulH 2011-02-28 15:24:36

託管代碼需要sos.dll的匹配平臺進行適當的分析。使用「x86」調試器。

您必須使用x86調試器/ WinDbg來調試x86內存轉儲。使用.loadby sos mscorwks加載合適的sos。您還可以使用.chain命令驗證擴展是否已正確加載。

Tess有一些很好的調試教程。

來源

2011-02-27 00:15:41 Naveen

@Naveen - 我的開發PC是Win 7 64位。我可以使用x86調試器還是需要創建一個32位虛擬機來運行它？ – PaulH 2011-02-27 01:03:06

必須使用Windows x86的調試工具（匹配轉儲位）。 32位虛擬機也可以工作，但不是必需的。 – 2011-02-28 06:17:43

打開轉儲並裝入SOS後，！CLRStack或！pe可以顯示調用堆棧或異常。 – 2011-02-28 06:18:47

在WinDbg中調試管理的崩潰轉儲需要額外的模塊（主要是SOS.dll）和命令。

一些很好的起始鏈接是here。

來源

2011-02-25 23:54:11

'.load sos' yield'調用LoadLibrary（sos）失敗，Win32錯誤0n193' – PaulH 2011-02-26 00:07:05

This tutorial是看到一些WinDbg命令的好開始。我想下面的命令就可以顯示當前的堆棧跟蹤：

.sympath SRV*d:\localsymbols*http://msdl.microsoft.com/download/symbols 
!reload 
.loadby sos mscorwks 
K

來源

2011-02-26 00:31:23 BrandonAGr

分析WinDbg中的CLR.dmp文件

回答

相關問題