分析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文件

回答

相关问题