SOS Versioning with Windbg
I'm not a .NET developer, but I have to debug dumps from .NET processes from time to time. I picked up some nuggets of information that may be known to .NET developers, but was not known to me.
It turns out, the SOS.dll version that you use in your debugger needs to match the version of the CLR that was running in the process where the dump was captured. Furthermore, you need to find certain symbols when running SOS commands, so having your symbol path set appropriately counts here.
In the past, I used Psscor4 to do the heavy lifting for me. But a version of Psscor4 that is compatible with 4.5+ hasn't yet been released. Unfortunately, using psscor4 in dumps from .NET 4.5+ processes doesn't give a very informative error message. Here is an attempt to use Psscor4 on a dump from what I believe was running .NET 4.6:
0:000> .load C:\Debuggers\Psscor4\x86\x86\psscor4.dll
----------------------------------------------------------------------------
The user dump currently examined is a minidump. Consequently, only a subset
of sos.dll functionality will be available. If needed, attaching to the live
process or debugging a full dump will allow access to sos.dll's full feature
set.
To create a full user dump use the command: .dump /ma <filename>
----------------------------------------------------------------------------
0:000> !dumpheap
Failed to find runtime DLL (clr.dll), 0x80004005
Extension commands need clr.dll in order to have something to do.
0:000> .chain
Extension DLL search Path:
<snipped for brevity>
Extension DLL chain:
C:\Debuggers\Psscor4\x86\x86\psscor4.dll: image 4.0.0.4, API 1.0.0, built Tue Feb 1 12:39:38 2011
[path: C:\Debuggers\Psscor4\x86\x86\psscor4.dll]
<snipped for brevity>
0:000> .unload C:\Debuggers\Psscor4\x86\x86\psscor4.dll
Unloading C:\Debuggers\Psscor4\x86\x86\psscor4.dll extension DLL
The fact that the DLL was built in 2011 should have been a hint that it's waaaay outdated, but the not-so-super-helpful error message of 0x80004005 led me astray for a while.
A common tactic is for folks to let the system figure out where the correct SOS.dll is, by using the .loadby command. However, that doesn't help on the HoloLens dumps I look at, since my dev machine is not running a HoloLens. Again, the debugger spits out a not-so-super-helpful error message as before:
0:000> .loadby sos clr
Unable to find module 'clr'
The keys to get this to work are:
- Explicitly load the correct sos.dll version
- Make sure your symbol path is set appropriately
You can find the version by examining file properties, on the details tab. Look at the version your dumped process is running, and find the appropriate sos.dll to go with it. Here's an example:
0:000> .load c:\foo\sos.dll
----------------------------------------------------------------------------
The user dump currently examined is a minidump. Consequently, only a subset
of sos.dll functionality will be available. If needed, attaching to the live
process or debugging a full dump will allow access to sos.dll's full feature
set.
To create a full user dump use the command: .dump /ma <filename>
----------------------------------------------------------------------------
0:000> !dumpheap
// Lots of debugger spew snipped for locating the CLR symbols, snipped here due to internal Microsoft stuff
Your best bet is to always use the latest SOS.dll that ships with the WDK.