Scenario: You have a 32-bit managed process running on a 64-bit machine. The process crashes sometimes. The customer created a crash dump in the Task Manager and sent it to you. You try to open it in the VS Debugger, but realize that the call stack looks really strange and does not contain any useful information. What’s the problem?

Ok. You cannot use the VS Debugger to analyze Crash Dumps in this scenario. You have a 64-bit Crash Dump for 32-bit managed process. What to do?
The answer is WinDbg. You can use it to check the dump.

Here is an example how you can get a call stack for threads of the crashed process.

1. Install 32-bit Version of Windows Debugging Tools on 64-bit machine

Download link: http://msdn.microsoft.com/en-us/windows/hardware/gg463009
Note: The Setup will automatically install 64-bit version. You have to select also to Install Debugging Tools Redistributables.
After installation, go to the Folder C:\Program Files\Microsoft SDKs\Windows\v7.1\Redist\Debugging Tools for Windows\ and install dbg_x86.msi from there.

2. Start 32-bit WinDbg.
3. Open 64-bit Dump of the 32-bit .NET Process.
4. Configure symbol path to the debug files (I assume, you have all .pdb files and binaries which match the Dump).

File > Symbol File Path…

5. Load SOS extension to debug .NET modules. Execute the following command:

.loadby sos mscorwks

6. Check that the extension was loaded. Execute

.chain
You should see something like this in you extension path
C:\Windows\Microsoft.NET\Framework\v2.0.50727\sos: image 2.0.50727.5446, API 1.0.0, built Fri Mar 25 19:34:29 2011
[path: C:\Windows\Microsoft.NET\Framework\v2.0.50727\sos.dll]

7. Activate WoW 64-bit extension. Execute

!wow64exts

8. Switch to 32-bit mode (that’s might be unnecessary)

!sw

9. Get the call stack for all threads:

Usually, you execute !clrstack command to see the managed call stack. But it does not work in this scenario.
So you should execute !EEStack command, which will successfully collect the stack of all threads managed and native.