在 windbg 中调试“发布模式”二进制文件/转储文件答案

【问题标题】：Debugging "release-mode" binaries/dumps in windbg在 windbg 中调试“发布模式”二进制文件/转储文件
【发布时间】：2011-06-21 16:23:56
【问题描述】：

我还没有找到一个很好的资源来调试 Windbg 中的 RELEASE 模式二进制文件或转储。

我了解启用编译器优化后调试会受到更多限制。但有时我别无选择——例如，对不可重现的问题进行故障转储分析。

如果有一些文章描述了发布二进制文件的可能性（或需要注意的事项），那就太好了。有人知道这样的资源吗？

我正在寻找类似this 的东西，但要详细得多。我希望Advanced Windows Debugging 会有一些东西，但没有这样的运气。

【问题讨论】：

我不知道具体的资源，但如果您有具体的问题，我可能会提供一些帮助。你在使用 WER 吗？
Good tutorial for WinDBG?的可能重复
@jeffamaphone - 我没有具体问题。在我看来，这是一个很常见的问题，很多人会受益于获得更多信息的地方
@Steve - 有很多很好的 windbg 教程，但我还没有看到一个涵盖非调试二进制文件的问题。这个问题专门针对启用优化编译的二进制文件，这比“正常”调试要困难得多

【解决方案1】：

第一条规则：保留您发布的每个构建版本中的所有 pdb：来自 exe 和您生成的任何其他 dll 中的所有 pdb

第二条规则：尝试获取重现步骤，因为能够在您自己的机器上重现崩溃比浏览崩溃日志更有效地利用您的时间。

除了您可以从发布构建崩溃中获得多少信息之外，您还要听天由命。一些崩溃分析专家可以通过崩溃转储创造奇迹，但对于我们这些普通人来说，这取决于崩溃的性质和可重复性。

要检查的一件事是，您的优化发布版本已将“省略帧指针”设置为“否”。仅这一点就可以让调试变得更容易，因为 99% 的时间你会得到一个意义模糊的堆栈。

请注意，大多数情况下，“this”指针在发布版本中会显示为 NULL，但有时您可以在堆栈中上下导航以查找它作为参数传递的位置。不过，一般来说，不要依赖调试器中变量的显示。如果这些值看起来合理，那么它们可能是正确的。如果它们看起来大错特错，那么要么是你的错误，要么只是对已优化变量的虚假显示。

哦，看看传奇的 John Robbins（Bugslayer），了解一些很棒的故障转储分析资源。

【讨论】：

【解决方案2】：

如果您有 PDB，大多数事情都是可能的（多年来，我一直仅在发布模式下调试 Windows 操作系统 DLL！）。

要意识到的是，WinDbg 现在欺骗你的频率要高得多——也就是说，它会显示它看到的，而这并不总是真实的价值是。例如，如果您尝试在 amd64 上的第 15 帧上运行 dv，则显示的值无法准确，因为编译器将信息存储在寄存器中。

另一个区别是函数现在将被内联，因此帧的最后一个堆栈可能不是实际最后一帧，它可能是一个被复制粘贴到的小函数更大的功能。

【讨论】：