为什么Minidumps没有提供好的电话堆栈？ [英] Why don't Minidumps give good call stacks?

问题描述

多年来，我已经在许多游戏项目中使用了minidumps，似乎有50％的机会有一个有效的电话堆栈。我可以做些什么来使它们有更好的调用堆栈？

我已经尝试将最新的dbghelp.dll放在exe目录中。这似乎有助于一些。

Visual Studio 2008或2010是否更好？ （我还在VS 2005）。

我使用的代码看起来像此示例。

解决方案

有一件事可以提高准确性在转储中找到的调用堆栈是使用除Visual Studio之外的调试器 - 具体来说，使用WinDbg或另一个使用dbgeng.dll中的Windows调试器调试引擎的工具（与Visual Studio Debugger调试引擎相反）根据我们的经验，WinDbg在同一转储中产生好的调用堆栈是100％可靠的，Visual Studio生成不可用或极不准确的调用堆栈。从我可以告诉的情况下，如果未处理的异常是崩溃的根源，WinDbg会自动执行重构/恢复异常callstack的棘手过程，但Visual Studio不（或不能？）。这两个调试器使用用于解释堆栈的不同启发式

WinDbg首先可能令人生畏，所以这里是我的快速指南，说明如何使它更容易，甚至避免直接使用它。

仅提供好的电话组合的真人指南

这些从最快/最简单到最慢/最隐秘的解释。

1. 最简单的选项：使用 DbgDiag from Microsoft

   
   
   

   这是一个鲜为人知的工具，可以自动对常见问题进行大量分析，而且非常方便，给予非程序员甚至客户。它快速，几乎是万无一失，已经成为我的去工具，用于快速分析一个进入的崩溃转储。

   
   
   
   
   
   • 启动DebugDiag Analysis应用程序
   
   
   • 在主页面上选择CrashHangAnalysis复选框
   
   
   • 将转储拖放到主页面的数据文件窗格中
   
   
   • 点击开始分析
   
   
   
   
   

   
   几秒钟到几分钟后，它会吐出一个不错的.mhtml文件，其中包含对问题的分析，所有相关信息线程，完整的调用堆栈等等。所有超链接和易于使用。 DebugDiag甚至可以自动执行一些更复杂的分析，这在WinDbg中是可能的，但是很痛苦（比如跟踪你的应用程序中的350个线程中的哪一个导致死锁）。注意：出于安全考虑，Chrome不会下载或打开.mhtml文件，因此您必须在Internet Explorer或Microsoft Edge中打开它才能使用。这是烦人的，我已经向DebugDiag团队（[e-mail]）提交了一个请求，将格式更改为纯HTML




2. 中间选项：将WinDbg安装为Visual Studio的备用调试引擎

   
   
   
   
   
   • 如果尚未安装Visual Studio已安装。这需要在下一步之前完成。
   
   
   • 安装 Windows驱动程序工具包（WDK）
   
   
   • 启动Visual Studio，（部分重要！）使用新的文件 - >打开 - >崩溃转储...选项打开转储。这将使用Windows调试器调试崩溃转储（如果您在Visual Studio上拖放转储或使用标准的文件 - >打开 - >文件...选项打开转储，那么将调试它使用旧的Visual Studio调试引擎...所以请小心使用正确的选项）。
   
   
   • 您现在应该可以使用Visual Studio GUI查看正确的调用堆栈，但有些工作方式不同（监视窗口需要使用不熟悉的WinDbg语法，线程ID为不同等）。注意：Visual Studio UI可能非常缓慢，特别是如果涉及许多线程，并且线程或并行堆栈窗口打开。
   
   



3. 硬核选项：直接使用WinDbg

   
   
   
   
   
   • 启动WinDbg.exe
   
   
   • 将转储拖放到WinDbg窗口中
   
   
   • 键入！analyze -v ，然后按Enter键。经过一段时间的WinDbg将会吐出一个崩溃调用堆栈，并且还估计了问题的根源。如果你正在分析一个僵局，你可以尝试！analyze -v -hang ，WinDbg将经常显示你所涉及的依赖链。
   
   
   
   
   

   
   此时您可能拥有所需的所有信息！但是，如果您想要检查Visual中的进程状态Studio调试器可以执行以下其他步骤：

   
   
   
   
   
   • 在Visual Studio中打开崩溃转储
   
   
   • 右键单击callstack窗口，然后选择转到拆装。
   
   
   • 将WinDbg输出调用堆栈顶端的十六进制地址粘贴到反汇编窗口的地址栏中，然后按Enter键。您现在正处于崩溃的位置，看看反汇编的代码。
   
   
   • 右键单击反汇编窗口并选择转到源代码，以转到源代码那个地点。现在您正在查看坠机站点的源代码。
   
   

<注意：以上所有都需要配置正确的符号服务器路径，否则您将无法解析调用堆栈中的符号。我建议您设置 _NT_SYMBOL_PATH环境变量，以便Visual Studio，WinDbg和DebugDiag自动使用。

I've used minidumps on many game projects over the years and they seem to have about a 50% chance of having a valid call stack. What can I do to make them have better call stacks?

I've tried putting the latest dbghelp.dll in the exe directory. That seems to help some.

Is Visual Studio 2008 or 2010 any better? (I'm still on VS 2005).

The code I use looks like this sample.

解决方案

One thing you can do to improve the accuracy of call stacks found in dumps is to use a debugger other than Visual Studio -- specifically, use WinDbg or another tool that uses the "Windows Debugger" debugging engine found in dbgeng.dll (as opposed to the "Visual Studio Debugger" debugging engine that Visual Studio uses).

In our experience, WinDbg is 100% reliable in producing good call stacks from the same dumps where Visual Studio produces unusable or wildly inaccurate call stacks. From what I can tell, in cases where an unhandled exception is the source of the crash WinDbg automatically performs the tricky process of reconstructing/recovering the exception callstack, but Visual Studio does not (or cannot?). The two debuggers use different heuristics for interpreting stacks

WinDbg can be daunting at first, so here's my quick guide on how to make it easier or even avoid having to use it directly.

A Mere Mortal's Guide To Extracting Good Callstacks

These are ordered from "fastest/easiest" to "slowest/most cryptic to interpret".

1. Easiest Option: use DbgDiag from Microsoft

   This is a little-known tool that automates a lot of analysis of common problems, and it's simple enough to give to non-programmers or even customers. It's fast and nearly foolproof, and has become my "go to" tool for quickly analyzing an incoming crash dump.

   • Launch the "DebugDiag Analysis" application
   • Select the "CrashHangAnalysis" checkbox on the main page
   • Drag-and-drop your dump into the "Data files" pane on the main page
   • Click "Start Analysis"

   
   After a few seconds to a few minutes it will spit out a nice .mhtml file containing an analysis of the problem, info about all the related thread, complete call stacks, etc. All hyperlinked and easy to use.

   DebugDiag even automates some of the more complicated analysis that is possible but painful in WinDbg (like tracking down which of the 350 threads in your application is responsible for a deadlock).

   Note: Chrome will not download or open .mhtml files for security reasons, so you must open in Internet Explorer or Microsoft Edge for it to be usable. This is annoying, and I've filed a request with the DebugDiag team ([e-mail]) to change the format to plain HTML

2. Middle option: Install WinDbg as an alternate debugging engine for Visual Studio

   • Install Visual Studio if it's not yet installed. This needs to be done before the next step.
   • Install the Windows Driver Kit (WDK)
   • Launch Visual Studio, and (this part is important!) use the new "File -> Open -> Crash Dump..." option to open the dump. This will debug the crash dump using the Windows Debugger (if you instead drag-and-drop the dump on Visual Studio or use the standard "File -> Open -> File..." option to open the dump, it will debug it using the old Visual Studio debugging engine... so be careful to use the right option).
   • You should now be able to see the correct call stack and navigate around using the Visual Studio GUI, although some things work differently (the watch windows require using the unfamiliar WinDbg syntax, thread IDs are different, etc). Note: the Visual Studio UI may be very sluggish, especially if many threads are involved and the 'threads' or 'parallel stacks' windows are open.

3. Hardcore option: Use WinDbg directly

   • Launch WinDbg.exe
   • Drag-and-drop your dump into the WinDbg window
   • Type !analyze -v and press Enter. After a little bit of time WinDbg will spit out a crash call stack, and also its estimation of what the source of the problem is. If you're analyzing a deadlock, you can try !analyze -v -hang and WinDbg will often show you the dependency chain involved.

   
   At this point you may have all the info you need! However, if you then want to examine the process state in the Visual Studio debugger you can take the following additional steps:

   • Open the crash dump in Visual Studio
   • Right-click in the callstack window and choose "Go to Disassembly"
   • Paste the hex address from the top line of WinDbg's output callstack into the "Address" bar of the Disassembly window and press enter. You're now at the location of the crash, looking at the disassembled code.
   • Right-click in the disassembly window and choose "Go To Source Code" to go to the source code for the location. Now you're looking at the source code at the crash site.

Note: all of the above require having correct symbol server paths configured, otherwise you won't be able to resolve the symbols in the call stacks. I recommend setting the _NT_SYMBOL_PATH environment variable so that it's automatically available to Visual Studio, WinDbg, and DebugDiag.

这篇关于为什么Minidumps没有提供好的电话堆栈？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！