调试“发布模式” Windbg 中的二进制文件/转储
我还没有找到一个好的资源来调试 Windbg 中的 RELEASE 模式二进制文件或转储。
我知道启用编译器优化后调试会变得更加受限。但有时我别无选择——例如，对不可重现的问题进行故障转储分析。
如果有一些文章描述发布二进制文件的可能性（或需要注意的事项），那就太好了。有人知道这样的资源吗？
我正在寻找类似这个的东西，但有很多更多细节。我希望 高级 Windows 调试 会有一些内容，但没有这样的运气。
I've yet to find a good resource for debugging RELEASE mode binaries or dumps in windbg.
I understand that debugging becomes more limited with compiler optimization enabled. But sometimes I don't have a choice--for example, crash dump analysis on a non-reproducible issue.
It'd be really nice if there were some write-up that describes what IS possible (or what to watch out for) with release binaries. Does anyone know of such a resource?
I'm looking for something like this, but with much more detail. I was hoping Advanced Windows Debugging would have something on it, but no such luck.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
第一条规则：保留您发布的每个版本中的所有 pdb：来自 exe 和您生成的任何其他 dll
第二条规则：尝试获取复制步骤，因为能够在您自己的计算机上重现崩溃比费力地查看崩溃日志更有效地利用您的时间。
除此之外，你能从发布版本崩溃中获得多少信息，就得听天由命了。一些崩溃分析专家可以通过崩溃转储创造奇迹，但对于我们其他凡人来说，这取决于崩溃的性质和再现性。
要检查的一件事是您的优化发布版本已将“忽略帧指针”设置为“否”。仅此一点就可以使调试变得更加容易，因为 99% 的情况下您都会得到一个模糊有意义的堆栈。
请注意，大多数情况下“this”指针在发布版本中会显示为 NULL，但有时您可以在堆栈中上下导航以查找它作为参数传递的位置。但一般来说，不要依赖调试器中变量的显示。如果这些值看起来合理，那么它们可能是正确的。如果它们看起来非常错误，那么要么是你的错误，要么只是已优化的变量的虚假显示。
哦，看看传奇人物约翰·罗宾斯（Bugslayer）的一些知识很棒的故障转储分析资源。
First rule: keep all the pdbs from every build you release: both from the exe and any other dlls you produce
Second rule: try to get reproduction steps, as being able to reproduce a crash on your own machine is a far more effective use of your time than wading through a crash log.
Beyond that you're at the mercy of the gods as to how much information you can get out of a release build crash. Some crash analysis gurus can work miracles with a crash dump, but for the rest of us mere mortals it depends on the nature and reproducibility of the crash.
One thing to check is that your optimised release builds have got the 'Omit Frame Pointers' setting as 'No'. That alone will make debugging much easier as 99% of the time you'll get a vaguely meaningful stack.
Be aware that most of the time the 'this' pointer will appear as NULL in a release build, but sometimes you can navigate up and down the stack to find where it is passed as a parameter. In general though, don't rely on the display of variables in the debugger. If the values look sensible then they're probably right. If they look wildly wrong then either that's your bug, or that's just a bogus display of a variable that's been optimised out.
Oh, and check out the legendary John Robbins (the Bugslayer) for some great crash dump analysis resources.
如果您有 PDB，那么大多数事情都是可能的（多年来我仅在发布模式下调试 Windows 操作系统 DLL！）。
需要认识到的是，WinDbg 现在会更频繁地对您撒谎 - 也就是说，它将显示它看到的内容，而这并不总是实际值。例如，如果您尝试在 amd64 上的第 15 帧上运行
dv，则显示的值不可能准确，因为编译器将信息存储在寄存器中。另一个区别是函数现在将被内联，因此帧的最后一个堆栈可能不是实际的最后一个帧，它可能是一个已复制粘贴到更大函数中的小函数。
If you have PDBs, most things are possible (I debugged Windows OS DLLs solely in release mode for years!).
The thing to realize is that WinDbg will now lie to you far more often - that is, it will display what it sees, which is not always what the actual value is. For example, if you try to run
dvon frame 15 on amd64, there is no way that the values displayed will be accurate, since the compiler stored the info in a register.The other difference, is that functions will now be inlined, so the last stack of the frame may not be the actual last frame, it may be a small function that has been copy-pasted into the bigger function.