How to load SOS in Windbg for a 32bit app running on a 64bit server

Question

Trying to debug a process dump of a 32-bit .NET application running on a 64-bit Windows edition Using debugger 6.3.9600.16384 x86.

Spent a couple of hours searching for a solution. Found numerous topics on stackoverflow and other sites, however I'm unable to fix the issue. I'm about to pull my hair out.

Checked the .NET version that was in use by the process

0:000> lmv m clr
start    end        module name
618a0000 61f3b000   clr        (pdb symbols)          c:\symcache\clr.pdb\5182A0CFB60D40DB90EEF44DEC7ACB932\clr.pdb
    Loaded symbol image file: clr.dll
    Mapped memory image file: c:\symcache\clr.dll\52717E8469b000\clr.dll
    Image path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
    Image name: clr.dll
    Timestamp:        Wed Oct 30 22:47:48 2013 (52717E84)
    CheckSum:         0069CCD3
    ImageSize:        0069B000
    File version:     4.0.30319.18444
    Product version:  4.0.30319.18444
    File flags:       8 (Mask 3F) Private
    File OS:          4 Unknown Win32
    File type:        2.0 Dll
    File date:        00000000.00000000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

Copied clr.dll, mscordacwks.dll and SOS.dll from the server running the application to C:\Temp\Dlls. Renamed mscordacwks.dll to mscordacwks_x86_x86_4.0.30319.18444.dll.

0:000> .cordll -u -lp c:\temp\dlls -ve
CLRDLL: Unable to get version info for 'c:\temp\dlls\mscordacwks.dll', Win32 error 0n87
CLRDLL: Unable to get version info for 'c:\temp\dlls\SOS_x86_x86_4.0.30319.18444.dll', Win32 error 0n87
Cannot Automatically load SOS
CLRDLL: Loaded DLL c:\temp\dlls\mscordacwks_x86_x86_4.0.30319.18444.dll
CLR DLL status: Loaded DLL c:\temp\dlls\mscordacwks_x86_x86_4.0.30319.18444.dll

0:000> .loadby sos clr
0:000> !clrstack
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
            2) the file mscordacwks.dll that matches your version of clr.dll is 
                in the version directory or on the symbol path
            3) or, if you are debugging a dump file, verify that the file 
                mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
            4) you are debugging on supported cross platform architecture as 
                the dump file. For example, an ARM dump file must be debugged
                on an X86 or an ARM machine; an AMD64 dump file must be
                debugged on an AMD64 machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to clr.dll as well.

Tried setting the executable path

0:000> .exepath c:\temp\dlls
Executable image search path is: c:\temp\dlls
Expanded Executable image search path is: c:\temp\dlls

************* Symbol Path validation summary **************
Response                         Time (ms)     Location
OK                                             c:\temp\dlls
0:000> .reload
................................................................
..........................................................
Loading unloaded module list
.....
0:000> !clrstack
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
            2) the file mscordacwks.dll that matches your version of clr.dll is 
                in the version directory or on the symbol path
            3) or, if you are debugging a dump file, verify that the file 
                mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
            4) you are debugging on supported cross platform architecture as 
                the dump file. For example, an ARM dump file must be debugged
                on an X86 or an ARM machine; an AMD64 dump file must be
                debugged on an AMD64 machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to clr.dll as well.

Tried .loadby sos clr

0:000> .loadby sos clr
0:000> !clrstack
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
            2) the file mscordacwks.dll that matches your version of clr.dll is 
                in the version directory or on the symbol path
            3) or, if you are debugging a dump file, verify that the file 
                mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
            4) you are debugging on supported cross platform architecture as 
                the dump file. For example, an ARM dump file must be debugged
                on an X86 or an ARM machine; an AMD64 dump file must be
                debugged on an AMD64 machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to clr.dll as well.

Who can help me? Don't know what else I can try anymore.

Answer 1

How did you create the dump file? If you're debugging a 32bit process on 64bit windows you must use the 32bit version of task manager located at

C:\Windows\SysWOW64\taskmgr.exe

Then proceed to right click on the process and 'Create Dump File'

Once you've taken the correct dump open it in WinDbg (X64) on the machine on which the dump was taken - that is Install windbg on the remote PC if possible as this reduces issues debugging if you have different versions (even subtle) of the .NET framework

Answer 2

You have done a lot of things right:

1. you have taken a 32 bit dump of a 32 bit application using WER LocalDumps
2. you have copied the SOS and mscordacwks from the original PC
3. you have renamed it correctly
4. you have chosen 32 bit WinDbg
5. you have used .cordll and the correct mscordacwks DLL was loaded

There's only one small thing which went wrong:

.loadby sos clr

This command will load SOS from the same location where clr.dll is located. This will be determined on your PC, so this may load a different version of SOS than present in the dump.

Instead, provide the full path to SOS which you have collected from the PC:

.load c:\temp\dlls\sos.dll