我最近收到了一位客户的 64 位故障转储。
我们的进程都是 32 位的,但客户的机器运行的是 x64 Server 2008。
Visual Studio(2008 和 2010 Express)告诉我必须使用 64 位版本MSVSMON.EXE
,但我不能,因为我没有 64 位机器。
我很确定在 WinDbg 中有一种方法可以做到这一点,但我发现 WinDbg 是敌对的。
有没有办法在 32 位机器上调试 64 位转储,最好使用 Visual Studio?
我最近收到了一位客户的 64 位故障转储。
我们的进程都是 32 位的,但客户的机器运行的是 x64 Server 2008。
Visual Studio(2008 和 2010 Express)告诉我必须使用 64 位版本MSVSMON.EXE
,但我不能,因为我没有 64 位机器。
我很确定在 WinDbg 中有一种方法可以做到这一点,但我发现 WinDbg 是敌对的。
有没有办法在 32 位机器上调试 64 位转储,最好使用 Visual Studio?
您需要确保客户使用 32 位工具(adplus 或 DebugDiag)来为您的 32 位进程捕获故障转储。然后您可以使用您的 32 位机器来调试转储。
尽管 Isalamon 的评论在技术上是正确的,但没有人愿意执行它,因为堆栈跟踪太可怕了。
让您的客户知道这是必要的,并希望他/她合作。
如果您不熟悉转储分析,Microsoft 随时为您服务,http://support.microsoft.com
我通过使用 32 位任务管理器 ( C:\Windows\SysWOW64\Taskmgr.exe ) 来捕获转储来解决这个问题。
使用 !wow64exts.sw 切换到 x86 模式的建议,我得到了很好的结果,如下所示:
http://blogs.msdn.com/b/ntdebugging/archive/2008/06/03/how-to-debug-wow64-applications.aspx
同样的建议数字在这里:
以及这里的背景和相关命令:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384163(v=vs.85).aspx
除了这个线程中已经存在的内容之外,希望这可以作为关于这个主题的体面输入的汇编。谢谢。
是用户转储还是内核转储?看起来你得到了系统转储。如果是这种情况,那么您可以使用 !wow64exts 对 windbg 扩展的帮助,这可能是问题的根源。
我同意您应该正确捕获 dmp 文件的观点,但最近对此类错误捕获的 dmp 文件进行了一些实验。我使用 WinDbg 修补 SOS.dll 以删除拱形检查。我不是 100% 确定我得到的是否有效,但至少有一些看起来如此...... https://chentiangemalc.wordpress.com/2015/04/17/experimental-use-of-64-位转储的 32 位网络进程 in-windbg/