在 WinDbg 中分析 CLR .dmp 文件
我在 Visual Studio 2008 中创建了一个 C# .NET 3.5 应用程序，该应用程序在没有开发环境的 Windows XP SP3 (x86) PC 上崩溃。
我已经能够从 PC 获取 .dmp 文件并将其带回我的 Windows 7 64 位开发 PC 并将其加载到 WinDbg 6.12 中。
但是，我在 C# 应用程序的调用堆栈中看不到任何代码。看起来它完全是一个本机调用堆栈。
!analyze -v 的结果如下。
我在与 .DMP 相同的目录中拥有相关的 EXE、DLL 和 PDB 文件。崩溃的可执行文件是在调试模式下编译的。
我还有 Visual Studio 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
---------
I have a C# .NET 3.5 application created in Visual Studio 2008 that is crashing on a Windows XP SP3 (x86) PC with no development environment.
I have been able to get the .dmp file from the PC and take it back to my Windows 7 64-bit development PC and load it into WinDbg 6.12.
But, I can't see any code in the call stack from my C# application. It looks like it's entirely a native call stack.
The result from !analyze -v is below.
I have the relevant EXE, DLL, and PDB files in the same directory as the .DMP. The executable that crashed was compiled in debug mode.
I also have Visual Studio 2008, if that's easier to use. But opening the dump file in there also only shows a native call stack, nothing from my code.
How can I view the CLR call stack?
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
---------
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您必须使用x86 调试器/WinDbg 来调试 x86 内存转储。使用
.loadby sos mscorwks加载适当的sos。您还可以使用.chain命令验证扩展是否已正确加载。Tess 有一些很好的调试教程。
You would have to use the x86 debugger/WinDbg to debug an x86 memory dump. Use
.loadby sos mscorwksto load the appropriate sos. You could also verify if the extension is loaded properly by using the.chaincommand.Tess has some good debugging tutorials.
本教程是了解一些 WinDbg 命令的良好开端。我认为以下命令应该显示当前的堆栈跟踪：
This tutorial is a good start to see some of the WinDbg commands. I think the following commands should show you the current stack trace:
在 WinDbg 中调试托管故障转储需要额外的模块（主要是 SOS.dll）和命令。
此处有一些不错的起始链接。
Debugging managed crash dumps in WinDbg requires additional modules (primarily SOS.dll) and commands.
Some good starting links are here.