问题标签 [postmortem-debugging]

有人可以推荐一个很好的免费工具来分析 Adplus/windbg/sos 以外的 .Net 内存转储吗？

在 AppVerifier 下，我们的一个应用程序崩溃了。我得到一个 DMP 文件，但它是一个小型转储。具体来说，虽然我有调用堆栈，但我还想要故障进程的用户空间内存（它使用很多全局变量）。如何配置 App Verifier（或 Windows）以提供完整的转储文件？

当 vsjitdebugger 被配置为 HKLM 中的默认调试器时，是否可以将 WinDbg 包含在由 vsjitdebugger 显示的调试器列表中...\AeDebug？

理想情况下，我希望能够在 vsjitdebugger 中的选项列表中包含更多命令行，这些命令行在进程遇到未处理的异常时可用：使用 DrWatson 或使用 WinDbg 保存小型转储以供以后检查。

情况如下：

背景

我有一个在 Visual Studio 2008 中开发的混合模式 .NET/Native 应用程序。

我所说的混合模式是指前端是用 C++ .NET 编写的，它调用本机 C++ 库。本机代码在应用程序中完成大部分工作，包括根据需要启动新线程。.NET 代码仅用于 UI 目的（赢取表单）。

我有一个在测试人员的计算机上运行的应用程序的发布版本。

本机库经过全面优化编译，但也启用了调试（“调试信息格式”设置为“程序数据库”）。

这意味着我在 PDB 文件中有应用程序的调试符号。

问题

所以无论如何，其中一位测试人员遇到了应用程序问题，它偶尔会在 XP 上崩溃。我已经能够使用 Watson 博士多次运行获得崩溃的小型转储。

当我调试它时（使用 minidump - 我实际上并没有调试真正的应用程序），所有调试符号都正确加载：我可以正确看到所有本机线程的完整堆栈跟踪。其他线程（可能是 .NET 线程）没有堆栈跟踪，但它们至少都向我显示了线程是在哪个 dll 上启动的（即 ntdll.dll）。

它正确报告失败的线程（“用户（5）.dmp 中 0x0563d652 处的未处理异常：0xC0000005：访问冲突读取位置 0x00000000）。

但是，当我进入线程时，它显示没有任何用处。在堆栈跟踪中有一个条目，它只有内存地址“0563d652()”（甚至不是“ntldll.dll”）。

当我进行拆卸时，它只显示大约 30 条指令的随机部分。内存地址的任何一侧都只是“？？？”。它几乎看起来不是我的源代码的一部分（您的二进制文件不是按顺序加载到内存中吗？在中间有一组随机的汇编语句是否正常？）。

我的问题

所以基本上我的问题是三次的。

1）任何人都可以解释调试器缺乏信息吗？

2）请记住，我无法显示我的代码中发生的错误，任何人都可以提出失败的原因

3) 我可以做任何其他事情来帮助我在未来诊断当前的问题吗？

帮助！

约翰

更新：

这是来自 WinDBG 的失败线程的堆栈转储

很奇怪吧？甚至不显示 DLL。

是否有可能我已经以某种方式破坏了堆栈/堆，导致线程刚刚被破坏......？

无论如何从 gdb 中的核心文件中发现 PyObject* 的 python 值

我正在寻找一个跨平台的崩溃处理程序。Google Breakpad看起来很有希望，但它非常缺乏任何文档，并且需要进行合理的调整才能真正开始使用。

什么是更好的选择？

我所需要的只是能够在崩溃时可靠地记录崩溃转储、堆栈跟踪和 CPU 信息。或者，使用 Google Breakpad 的体验如何？它是伟大的还是可怕的？

在安装时在 .NET 托管应用程序上执行 ngen 并从应用程序的 Windows 错误报告中检索故障转储时，如何使用它来查看堆栈跟踪、变量等？

以下是与该问题相关的一些背景：我们有一个在安装时生成的 .NET 应用程序。当它由于未处理的 .NET 异常而崩溃时，崩溃被存储在 Windows 错误报告中，并且我能够从 winqual.microsoft.com 下载 minidump.mdmp 文件。

我将 minidump.mdmp 放在包含 .dbg 文件的文件夹中，用于构建崩溃的应用程序，然后双击 minidump.mdmp 以在 VS2008 SP1 的新实例中打开它。我的堆栈跟踪如下所示：

kernel32.dll!RaiseException() + 0x3d 字节
mscorwks.dll!RaiseTheExceptionInternalOnly() + 0x295 字节
mscorwks.dll!JIT_Throw() + 0x130 字节
MyApp.ni.exe!000007feee74c84c()
[下面的帧可能不正确和/或丢失，没有为 MyApp.ni.exe 加载符号]
0000000070000d5e()
MyApp.ni.exe!000007feee611000()
000000000300bf78()
000000000300bf60()

Modules 窗口表明已为 OS 和 .NET DLL 加载了符号，但对于应用程序模块，我得到以下信息：

MyApp.exe -> 符号文件中没有本机符号。
MyApp.ni.exe -> 找不到匹配的二进制文件。
MyAppsLibrary.ni.dll -> 找不到匹配的二进制文件。

分步执行发布代码有什么意义吗？我注意到省略了一些代码行，即一些方法调用。此外，变量预览不会显示某些变量，并且会显示其他一些变量的无效（非真实）值，因此这一切都具有误导性。

我在问这个问题，因为将 WinDbg crashdump 文件加载到 Visual Studio 会带来与步骤执行相同的堆栈和变量部分视图。除了在没有优化的情况下重新编译应用程序之外，有什么方法可以改善故障转储分析体验？

Windows、Visual Studio 2005、非托管 C++

我有一个用 VC++ 6 构建的旧 DLL 文件。现在我需要调查转储文件，但我没有可用的 PDB。WinDbg 报告的堆栈跟踪也不准确。

是否可以使用更高版本的 Visual Studio 重建项目，即 2003、2005、2008，生成 PDB，并使用它将地址映射到旧 DLL 中的符号？是否有类似 VC 6.0 兼容模式来构建项目？

获得 VC++ 6 是一种选择，但看起来 VS6.0 已经从 MSDN 订阅者下载页面消失了 :(

谢谢！

在我的应用程序中，每当我的应用程序崩溃时，我都会使用 MiniDumpWriteDump 函数（请参阅 dbghelp.dll）来编写崩溃转储文件。

我还使用符号服务器来存储我所有的可执行文件和 pdb 文件，这样每当客户向我发送故障转储文件时，调试器就会自动获取正确版本的可执行文件和调试信息。

我还将 Windows DLL（ntdll.dll、kernel32.dll、...）及其调试信息存储在符号服务器中（使用 SymChk）。调试信息是从 Microsoft 的公共符号服务器获取的。

大多数情况下，这很完美，除非：

• 客户在其中一个 Windows DLL 中崩溃
• 并且客户使用我没有放入符号服务器的 DLL

这是因为在 Symbol Server 中存储每个 Windows DLL 的每个风格是完全不可撤销的（尤其是每周的补丁）。

因此，如果客户崩溃了，比如说 NTDLL.DLL 的 5.2.123.456 版本，而我没有将这个确切版本的 DLL 放在我的符号服务器中，那么我就被卡住了。甚至微软的公共符号服务器也无济于事，因为它只提供调试信息，而不是 DLL 本身。

我目前的解决方案是向客户索要他的 DLL，但这并不总是那么容易。因此，我正在寻找更好的解决方案。

有没有办法让调试器显示正确的调用堆栈，或者加载特定 DLL 的调试信息，即使您没有 DLL 的确切版本？

或者，有没有办法获得所有（或重要的）Windows DLL（来自 Microsoft）的所有版本？

编辑：

与此同时，我找到了一个非常简单的方法来解决这个问题。使用实用程序 ModuleRescue（请参阅http://www.debuginfo.com/tools/modulerescue.html），您可以从 minidump 文件生成虚拟 DLL。有了这些虚拟 DLL，调试器就满足了，并正确地开始从 Microsoft 服务器加载调试符号。