我最近从客户那里收到了一个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
希望这可以作为有关该主题的良好输入的汇编,除了本帖子中已有的内容外。谢谢。是用户转储还是内核转储?看起来你得到了系统转储。如果是这种情况,那么你可以在windbg上使用!wow64exts扩展来帮助查找问题的根本原因。
我同意答案中提到的,你应该正确获取dmp文件,但是最近我做了一些对于这种不正确获取的dmp文件的实验。我使用WinDbg对SOS.dll进行了补丁以移除架构检查。我不能百分之百确定我得到的是有效的,但至少有些看起来确实是... https://chentiangemalc.wordpress.com/2015/04/17/experimental-use-of-64-bit-dump-of-32-bit-net-process-in-windbg/