在windbg中调试“release-mode”二进制文件/转储

时间:2011-06-21 16:23:56

标签: windows debugging windbg dump

我还没有在windbg中找到调试RELEASE模式二进制文件或转储的好资源。

我知道启用编译器优化后调试会变得更加有限。但有时我没有选择 - 例如,对不可重现的问题进行崩溃转储分析。

如果有一些文章描述了发布二进制文件的可能性(或注意事项),那将是非常好的。有谁知道这样的资源?

我正在寻找像this这样的东西,但有更详细的内容。我希望Advanced Windows Debugging会有一些东西,但没有这样的运气。

2 个答案:

答案 0 :(得分:4)

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

第二条规则:尝试获得复制步骤,因为能够在您自己的计算机上重现崩溃比使用崩溃日志更有效地利用您的时间。

除此之外,你还会受到众神的怜悯,因为你可以从发布版本崩溃中获得多少信息。一些崩溃分析大师可以通过崩溃转储来创造奇迹,但对于我们其他人而言,它只取决于崩溃的性质和可重复性。

要检查的一件事是,您的优化发布版本将“Omit Frame Pointers”设置为“No”。只有这样才能使调试变得更加容易,因为99%的时间你会得到一个模糊的有意义的堆栈。

请注意,大多数情况下,'this'指针在发布版本中将显示为NULL,但有时您可以在堆栈中上下导航以查找它作为参数传递的位置。通常,不要依赖于调试器中的变量显示。如果值看起来合理,那么他们可能是正确的。如果他们看起来非常错误,那么这就是你的错误,或者只是虚假显示已经优化的变量。

哦,查看传奇的John Robbins(Bugslayer),了解一些出色的崩溃转储分析资源。

答案 1 :(得分:3)

如果您有PDB,大多数事情都是可能的(我多年来一直在发布模式下调试Windows操作系统DLL!)。

要意识到的是,WinDbg现在会更多地骗你 - 也就是说,它会显示看到的内容,这并不总是真实的价值是。例如,如果您尝试在amd64上的第15帧上运行dv,则没有 way 显示的值将是准确的,因为编译器将信息存储在寄存器中。

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