WinDbg: Copy of SOS.dll x86 4.0.30319.237

Question

I am using WinDbg to look into a process dump. The dump has been taken on an x86 server with .NET 4 SP1 (4.0.30319.237). I'm attempting to debug on my x64 machine using the x86 version of WinDbg, but I get the following issue.

0:000> !EEVersion
The version of SOS does not match the version of CLR you are debugging.  Please
load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.0.30319.237
SOS Version: 4.0.30319.239
4.0.30319.237 retail
Workstation mode
SOS Version: 4.0.30319.239 retail build

As my machine has taken a recent security patch, the SOS DLL file is now at version 4.0.30319.239, so I am unable to use any of the CLR extensions in WinDbg. I have connected to Microsoft symbol servers and got the correct version of mscordacwks.dll .

Where can I get a copy of SOS.dll version 4.0.30319.237?

The best match I get online is via Reliability Update 1 for the .NET Framework 4 . However, this cannot be installed on my machine (and I don't have a second one) as it's already superceeded.

Nightmare!

Answer 1

I'm in nearly the same situation.

0:000> !EEVersion
The version of SOS does not match the version of CLR you are debugging.  Please
load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.0.30319.235
SOS Version: 4.0.30319.239
4.0.30319.235 retail
Workstation mode
SOS Version: 4.0.30319.239 retail build

I have downloaded and used psscor4, it don't complain, and the stack looks sensible

0:000> !psscor4.EEVersion
4.0.30319.235 retail
Workstation mode
SOS Version: 4.0.0.4 retail build
0:000> !psscor4.DumpStack
OS Thread Id: 0x874 (0)
Current frame: ntdll!KiFastSystemCallRet
ChildEBP RetAddr  Caller,Callee
002ec6c8 77d16a24 ntdll!NtWaitForSingleObject+0xc 
002ec6cc 758e6f0f mswsock!SockWaitForSingleObject+0x1ba , calling        ntdll!NtWaitForSingleObject
002ec70c 758e65cc mswsock!SockDoConnectReal+0x2c3 , calling    mswsock!SockWaitForSingleObject
002ec77c 71a63267 clr!GetCompileFlags+0x144 , calling clr!_EH_epilog3
002ec780 76ee2f7d ws2_32!WahReferenceContextByHandle+0x63 
002ec7a4 758e5fac mswsock!SockDoConnect+0x3a1 , calling mswsock!SockDoConnectReal
002ec7e4 76a82c6a kernel32!FlushInstructionCache+0x18 , calling     ntdll!ZwFlushInstructionCache

You could give it a try !

Answer 2

If you don't have the same exact .NET build installed on your analysis machine as was running on the machine on which the dump was taken, you really need more than just SOS.dll off the dump machine.

1. Get the following assemblies: sos.dll , mscordacwks.dll , and (possibly) mscorwks.dll (if .NET 2) or clr.dll (.NET 4).

2. Put them all in a directory on the analysis machine. The examples below assumes C:\\Debug .

3. Copy, then rename, the mscordacwks machine to reflect the platform and build number. Remember that 64-bit in this context usually must be named AMD64 if not from Itanium.

   Examples:

   mscordacwks_x86_x86_2.0.50727.3625.dll

   or

   mscordacwks_AMD64_AMD64_4.0.30319.269.dll

4. Bring up WinDbg, and add that directory to the execution path so the renamed mscordacwks can be found.

   Example: ".exepath+ C:\\Debug"

5. Explicitly load the matching SOS

   Example: ".load C:\\Debug\\sos"

Happy debugging!

Answer 3

The only way I ever found to fix this was to get the SOS.dll from the machine that generated the dump. I've had this happen a couple of times now and that was the only solution that worked for me. It's really annoying that MS doesn't make sure to put the SOS.dlls for all versions on the symbol server.