Don’t you just love the following error message when trying to debug a minidump with SOS and WinDBG?

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.1
SOS Version: 4.0.30319.235

SOS is built as part of the framework, so if you have a newer version of .NET on your machine than was running on the machine where the minidump was taken, you are completely out of luck. I guess you could set up a VM, install the original RTM .NET version and copy the SOS out of the framework directory. Lather, rinse, and repeat for each and every hotfix and service pack and you will eventually have all of the SOS.DLLs saved off. What would be nice is if the debugger would just get the right one every time.

This week I was working a fantastic group at Blizzard and we ran into something undocumented that we thought was awesome. WinDBG can download the right version of SOS if you get everything set up right. This seems to work for .NET 4.0 (but only post RTM builds) and .NET 4.5.

All my testing was with the latest WinDBG 6.2.9200.16384 from the Windows 8 SDK that you download here. The super important part to get SOS automatically downloaded is that you have to have the Microsoft symbol servers set up in the _NT_SYMBOL_PATH environment variable. The easiest way to do that is to use my WintellectPowerShell module to run the Set-SymbolServer cmdlet with the –public switch. WintellectPowerShell is freely available at GitHub.

Once you have the minidump loaded, the trick is to run !analyze –v. With the symbol server set up, the !analyze command will grab the correct version of SOS from Microsoft because that’s how it does the analysis! The downloaded SOS will be put into your local symbol cache and loaded from there. Here’s what the extension chain will be after running !analyze.

0:016> .chain
Extension DLL search Path:
      c:WinDBGWINXP;c:WinDBGwinext;c:WinDBGwinextarcade;…
Extension DLL chain:
     C:SYMBOLSPUBLICsos_AMD64_AMD64_4.0.30319.18046.dll5155291195e000sos_AMD64_AMD64_4.0.30319.18046.dll: image 4.0.30319.18046, API 1.0.0, built Thu Mar 28 22:29:32 2013
         [path: C:SYMBOLSPUBLICsos_AMD64_AMD64_4.0.30319.18046.dll5155291195e000sos_AMD64_AMD64_4.0.30319.18046.dll]
     dbghelp: image 6.2.9200.20512, API 6.2.6, built Thu Sep 06 22:45:49 2012
         [path: c:WinDBGdbghelp.dll]

     ext: image 6.2.9200.20522, API 1.0.0, built Fri Sep 21 01:17:05 2012
         [path: c:WinDBGwinextext.dll]
     exts: image 6.2.9200.16384, API 1.0.0, built Wed Jul 25 19:15:20 2012
         [path: c:WinDBGWINXPexts.dll]
     uext: image 6.2.9200.16384, API 1.0.0, built Wed Jul 25 19:15:09 2012
         [path: c:WinDBGwinextuext.dll]
     ntsdexts: image 6.2.9200.16384, API 1.0.0, built Wed Jul 25 19:16:01 2012
         [path: c:WinDBGWINXPntsdexts.dll]

Having fought the battle of the SOS version many times, this little trick will save us all a ton of time.