与崩溃转储相比，WinDbg 在附加到进程时显示不同的调用堆栈
我正在分析将本机库与托管代码一起使用时发生的死锁。我使用 WinDbg 来调试问题，目的是保存转储，以便供应商可以在其场所观察到问题。
当附加到有问题的进程时，我在任何调用堆栈之前看到以下消息：
警告：堆栈展开信息不可用。以下框架可能是错误的。
当直接连接到流程时，框架实际上看起来是正确的。但是，当我转储该文件，然后在另一台计算机上的 WinDbg 中打开转储时，其中一个堆栈帧不同（也显示上述错误。）这最初让供应商感到困惑，因为代码路径似乎不可能。
我使用以下方法进行转储：
.dump /ma filename.dmp
什么会导致这种差异，我可以采取什么措施来可靠地分析转储文件的调用堆栈？是否还有其他我应该注意的歪曲数据？
I'm analysing a deadlock that's occurring when using a native library alongside managed code. I'm using WinDbg to debug the problem with the intention of saving a dump such that the vendor might observe the issue on their premises.
When attaching to the problematic process I see the following message before any call stacks:
WARNING: Stack unwind information not available. Following frames may be wrong.
The frames actually look correct when attached directly to the process. However, when I take a dump of this file and then open the dump in WinDbg on another machine, one of the stack frames is different (the above error is displayed too.) This originally had the vendor stumped, as the code path seemed impossible.
I took the dump using:
.dump /ma filename.dmp
What would cause this discrepancy, and is there anything I can do to reliably analyse a dump file's call stacks? Might there be any other misrepresented data I should be aware of?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这听起来好像您的 pdb 可能不匹配。您是否尝试过
!chksym和!itoldyouso命令？例如，请参阅 Bugslayer 文章另一件可以尝试的事情是
!sym busy它应该显示正在加载哪些 pdb 文件。另请参见MSDN 博客
This sounds like you might have mismatched pdbs. Have you tried the
!chksymand!itoldyousocommands? eg see the Bugslayer articleAnother thing to try is
!sym noisythat should show you which pdb files are being loaded.See also MSDN blog
该警告告诉您调试器无法将堆栈上的一个或多个地址与现有模块信息相关联。由于托管代码是由 CLR 即时编译的，因此代码没有相应的模块，因此会出现警告。
SOS 命令 !clrstack 具有来自 CLR 的必要信息，可以显示有意义的堆栈（或者至少没有警告）。如果您使用任何本机堆栈转储命令，您将看到托管代码的此警告。
即将出版的《高级 .NET 调试》一书提供了更多详细信息。请参阅http://advanceddotnetdebugging.com/
The warning is telling you that the debugger cannot associate one or more addresses on the stack with existing module information. As managed code is compiled on the fly by the CLR there are no corresponding modules for the code and thus the warning.
The SOS command !clrstack has the necessary info from the CLR to display a meaningful stack (or at least without the warning). If you use any of the native stack dump command, you'll see this warning for managed code.
The upcoming book Advanced .NET Debugging has additional details. See http://advanceddotnetdebugging.com/