Debugging dump of 32-bit process captured on 64-bi

问题:

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?

回答1:

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.

http://blogs.msdn.com/b/tess/archive/2010/09/29/capturing-memory-dumps-for-32-bit-processes-on-an-x64-machine.aspx

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

回答2:

I worked around the problem by using 32 bit task manager (C:\Windows\SysWOW64\Taskmgr.exe) to capture the dump.

回答3:

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.

回答4:

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.

回答5:

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/