17

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?

mskfisher
  • 3,291
  • 4
  • 35
  • 48
  • 1
    This is no longer a problem [from VS 2013](http://blogs.msdn.com/b/visualstudioalm/archive/2013/10/16/opening-64-bit-dumps-of-32-bit-processes-in-visual-studio-2013.aspx) on. – Nick Westgate Oct 05 '15 at 21:30
  • Updated [link](https://devblogs.microsoft.com/devops/opening-64-bit-dumps-of-32-bit-processes-in-visual-studio-2013/) to the resource from the previous comment. – IInspectable Dec 14 '20 at 08:15

5 Answers5

12

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

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Lex Li
  • 60,503
  • 9
  • 116
  • 147
  • 2
    I used ProcDump, as outlined in the linked blog post. Works like a charm, even with managed code in VS2010. – GregC Aug 16 '11 at 22:01
7

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

Shane Lu
  • 1,056
  • 1
  • 12
  • 21
3

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.

shivesh suman
  • 1,511
  • 18
  • 26
  • 1
    Very useful, thank you. Took a dmp of a 32bit process on 64bit Windows Task Manager and this helped switch modes in windbg to diagnose – user1867382 Oct 09 '20 at 22:36
1

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/

Malcolm McCaffery
  • 2,468
  • 1
  • 22
  • 43
1

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.

Ajaykanth
  • 11
  • 1