SOS: Always use the correct debugger

I cannot stress this enough.  It is very important that you use the same architecture for the debugger as the process that you are trying to troubleshoot.

Wrong version when capturing a dump

If you use a 64-bit debugger to capture a dump of a32-bit process, when you try to open the dump, you will get error messages like:

WARNING: shlwapi overlaps msvcp60
WARNING: msdatl3 overlaps msdtcprx
WARNING: wldap32 overlaps dnsapi
WARNING: mscorjit overlaps mscoree
WARNING:  rasapi32 overlaps dnsapi
WARNING: tapi32 overlaps rasapi32

This will make troubleshooting impossible as things won’t work correctly.  Basically this is telling you that one of these files have their start address inside the address of the other file.  So things won’t look correct in this situation.

You must use a 32-bit debugger to capture a 32-bit process and a 64-bit debugger for a 64-bit process (matching amd64 and ia64 also).

Wrong version when debugging a dump

There are some things you can do if you use the wrong architecture for opening the dump.  For example, to get some callstacks, you can run:

.effmach x86
.load wow64exts

But for managed code, you will get a failure such as:

CLR DLL status: ERROR: DLL init failure, Win32 error 0n87

Managed code actually has to have them match up so that things can be loaded properly.  So if you use mismatching versions, things will not work correctly.

You must use a 32-bit debugger to analyze a 32-bit dump and a 64-bit debugger to analyze a 64-bit dump when you want to look at managed data.