如何为 .NET 进行良好的故障转储? [英] How do I take a good crash dump for .NET?

问题描述

我捕获了在 64 位 Windows 操作系统上运行的 32 位 .NET 应用程序的故障转储.在分析过程中，有人发现我有一个 64 位转储，并告诉我由于位错误，无法分析此转储.

当使用 Windows 任务管理器创建转储时，我没有意识到我做错了什么.这始终适用于 32 位操作系统.

如何为 .NET 进行良好的转储，尤其是正确的位数?

解决方案

为什么 bitness 与此相关?

位数对于 .NET 应用程序很重要，原因如下:

• 需要正确位数的 DAC(数据访问控制)库 (mscordakwks.dll).没有可用的跨位 DAC.
• 调试器需要能够加载正确位数的 SOS 调试扩展

不可能将转储从 64 位转换为 32 位，尽管理论上它应该包含所有必要的信息.

如果你觉得幸运，你也可以尝试一些说明

• ProcDump
• 微软 Visual Studio
• Windows 错误报告 LocalDumps

捕获具有特定位数的转储的工具:

• 64 位:64 位操作系统上的默认任务管理器
• 32 位:任务管理器在 64 位操作系统上从 %windir%SysWOW64 askmgr.exe 运行
• 64 位:ProcDump 使用 -64 运行 命令行开关
• 32 位:WinDbg x86 版本
• 64 位:WinDbg x64 版本
• 32 位:DebugDiag x86 版本
• 64 位:DebugDiag x64 版本
• 32 位:ADPlus x86 版本
• 64 位:ADPlus x64 版本

只需根据您的应用程序选择位数，而不是根据操作系统.

为什么记忆在这里很重要?

对于.NET，你需要一个完整的内存转储，否则你无法弄清楚对象的内容.要包含完整内存，请执行以下操作:

• 在WinDbg中，在执行.dump
时指定/ma
• 在 Process Explorer 中，选择创建完整转储"(尽管从技术上讲，结果仍然是一个小型转储)
• 在 ProcDump 中，应用 -ma命令行开关
• 在 Visual Studio 中，选择带堆的小型转储"
• 任务管理器将始终创建一个内存已满的转储
• 对于 Windows 错误报告 LocalDumps 将 DumpType 设置为 2

Visual Studio 说明

我发现许多开发人员甚至不知道 Visual Studio 可以创建转储.原因可能是菜单长时间不可见.这些是步骤:

• 启动 Visual Studio:菜单不可见
• 附加到进程:菜单仍然不可见
• 中断:菜单变得可见(在调试/转储另存为下找到它)

为什么要转储 32 位应用程序的 64 位?

可能只是为了调试 WoW64 层本身.

I have captured a crash dump of my 32 bit .NET application running on a 64 bit Windows operating system. During the analysis somebody found out that I have a 64 bit dump and told me that it is not possible to analyze this dump due to wrong bitness.

When using Windows Task Manager to create the dump, I was not aware that I was doing something wrong. This always worked for 32 bit operating systems.

How can I take a good dump for .NET, especially with the correct bitness?

解决方案

Why is bitness relevant here?

The bitness matters for .NET applications for the following reasons:

• a DAC (data access control) library (mscordakwks.dll) of the correct bitness is needed. There's no cross-bitness DAC available.
• the debugger needs to be able to load the SOS debugging extension of the correct bitness

It is not possible to convert a dump from 64 bit to 32 bit, although in theory it should contain all necessary information.

If you're feeling lucky, you can also try some of the instructions anyway

• How to use Windbg to debug a dump of a 32bit .NET app running on a x64 machine

How to detect the bitness of an application?

If you don't know the bitness, you can find it out like this:

Windows 7 Task Manager shows *32 on processes:

In Windows 8 task manager, go to the Details tab and add a column named Platform:

Visual Studio shows the bitness when attaching to the process:

Process Explorer can be configured to show the Image Type column:

Tools

Programs which detect bitness automatically:

• Process Explorer
• ProcDump
• Microsoft Visual Studio
• Windows Error Reporting LocalDumps

Tools which capture a dump with specific bitness:

• 64 Bit: default Task Manager on a 64 bit OS
• 32 Bit: Task manager run from %windir%SysWOW64 askmgr.exe on a 64 Bit OS
• 64 Bit: ProcDump run with the -64 command line switch
• 32 Bit: WinDbg x86 version
• 64 Bit: WinDbg x64 version
• 32 Bit: DebugDiag x86 version
• 64 Bit: DebugDiag x64 version
• 32 Bit: ADPlus x86 version
• 64 Bit: ADPlus x64 version

Just choose the bitness according to your application, not according the OS.

Why is memory relevant here?

For .NET you need a full memory dump, otherwise you cannot figure out the content of the objects. To include full memory, do the following:

• in WinDbg, specify /ma when doing .dump
• in Process Explorer, choose "Create full dump" (although technically, the result is still a minidump)
• in ProcDump , apply the -ma command line switch
• in Visual Studio, choose "Minidump with heap"
• Task Manager will always create a dump with full memory
• For Windows Error Reporting LocalDumps set DumpType to 2

Visual Studio instructions

I found out that many developers aren't even aware that Visual Studio can create dumps. The reason probably is that the menu is invisible for a long time. These are the steps:

• Start Visual Studio: menu is invisible
• Attach to a process: menu is still invisible
• Break: menu becomes visible (find it under Debug / Save dump as)

Why 64 bit dumps of 32 bit applications at all?

Probably just for debugging the WoW64 layer itself.

这篇关于如何为 .NET 进行良好的故障转储?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！