在 64 位计算机上捕获的 32 位进程的调试转储
我最近收到了一位客户发来的 64 位故障转储。
我们的进程都是 32 位的，但客户的计算机正在运行 x64 Server 2008。Visual
Studio（2008 和 2010 Express）告诉我必须使用 64 位版本的 MSVSMON.EXE，我不能，因为我没有 64 位机器。
我很确定 WinDbg 中有一种方法可以做到这一点，但我发现 WinDbg 是敌对的。
有没有办法在 32 位计算机上调试 64 位转储，最好使用 Visual Studio？
I recently received a 64-bit crash dump from a customer.
Our processes are all 32-bit, but the customer's machine is running x64 Server 2008.
Visual Studio (both 2008 and 2010 Express) is telling me that I have to use the 64-bit version of MSVSMON.EXE, which I can't because I don't have a 64-bit machine.
I'm pretty sure there's a way to do this in WinDbg, but I find WinDbg to be hostile.
Is there any way to debug a 64-bit dump on a 32-bit machine, preferably using Visual Studio?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您需要确保客户使用 32 位工具（adplus 或 DebugDiag）来捕获 32 位进程的故障转储。然后您可以使用 32 位计算机来调试转储。
链接
虽然 Isalamon 的评论在技术上是正确的，但没有人愿意执行它，因为堆栈跟踪很糟糕。
让您的客户知道这是必要的，并希望他/她配合。
如果您不熟悉转储分析，Microsoft 随时为您服务，http://support.microsoft.com
You need to make sure that customer uses 32 bit tools (adplus or DebugDiag) to capture crash dumps for your 32 bit processes. Then you can use your 32 bit machine to debug the dumps.
Link
Though Isalamon's comment is technically correct, nobody would like to execute that as the stack trace is horrible.
Let your customer know that this is necessary, and hope that he/she cooperates.
If you are not familiar with dump analysis, Microsoft is always there for you, http://support.microsoft.com
我通过使用 32 位任务管理器 (C:\Windows\SysWOW64\Taskmgr.exe) 捕获转储来解决该问题。
I worked around the problem by using 32 bit task manager (C:\Windows\SysWOW64\Taskmgr.exe) to capture the dump.
我按照此处建议的使用 !wow64exts.sw 切换到 x86 模式的建议获得了出色的结果：
http://blogs.msdn.com/b/ntdebugging/archive/2008/06/03/how-to-debug-wow64-applications.aspx
这里有相同的建议：
http://blogs.msdn。 com/b/msdnforum/archive/2010/03/14/i-use-windbg-to-debug-a-dump-of-a-32bit-时如何-i-switch-to-32bit-mode- application-running-on-an-x64-machine.aspx
后台和相关命令在这里：
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384163(v=vs.85).aspx
希望除了本线程中已有的内容之外，这还可以作为有关该主题的体面输入的汇编。谢谢。
I have gotten excellent results using the advice on switching to x86 mode using !wow64exts.sw as advised here:
http://blogs.msdn.com/b/ntdebugging/archive/2008/06/03/how-to-debug-wow64-applications.aspx
Same advice figures here:
http://blogs.msdn.com/b/msdnforum/archive/2010/03/14/how-do-i-switch-to-32bit-mode-when-i-use-windbg-to-debug-a-dump-of-a-32bit-application-running-on-an-x64-machine.aspx
And background and related commands over here:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384163(v=vs.85).aspx
Hope this serves as a compilation of decent inputs on this topic in addition to what already exists in this thread. Thanks.
是用户转储还是内核转储？看来您已获得系统转储。如果是这种情况，那么您可以借助 Windbg 上的 !wow64exts 扩展来找到问题的根源。
Is it Userdump or kernel dump? It looks like you got the system dump. If that is the case, then you can take help of !wow64exts extension on windbg and can root cause the problem.
我同意你应该正确捕获 dmp 文件的说法，但最近对这种类型的错误捕获的 dmp 文件做了一些实验。我使用 WinDbg 修补 SOS.dll 以删除拱门检查。我不是 100% 确定我得到的内容是否有效，但至少有一些看起来是这样...... https://chentiangemalc.wordpress.com/2015/04/17/experimental-use- of-64-bit-dump-of-32-bit-net-process-in-windbg/
I agree with anwer you should get dmp file captured correctly, but recently did some experiments with this type of incorrectly captured dmp file. I used WinDbg to patch SOS.dll to remove the arch check. I'm not 100% sure if what I'm getting is valid, but at least some it appears so... https://chentiangemalc.wordpress.com/2015/04/17/experimental-use-of-64-bit-dump-of-32-bit-net-process-in-windbg/