Loading sos.dll to Windbg

Windbg is still the golden standard to troubleshoot memory dumps. and sos extension is still the essential tool to help with managed memory dump investigation. With .NET Framework (4.8 or earlier), it could be as easy as .loadby sos clr. But things got a little trickier with .NET Core, as you need to install dotnet-sos for the extension, and that could cause some confusions to get it work.

So, the thing is that you can’t (or rather, can’t stop at) install dotnet-sos like this

dotnet tool install -g dotnet-sos

Which will install it in a weird path like this C:\Users\quma.dotnet\tools.store\dotnet-sos\9.0.607501\dotnet-sos\9.0.607501\tools\net6.0\win-x64

And if you run the command to load it like this

.load C:\Users\vimvq\.dotnet\tools\.store\dotnet-sos\8.0.510501\dotnet-sos\8.0.510501\tools\net6.0\any\win-x64\sos.dll

You can’t run any command that you’re used to, like !dumpheap

0:000> !dumpheap 
Error: Fail to create host ldelegate 80070002
Error: ICLRRuntimeHost::ExecuteInDefaultAppDomain failed 80070002
Unrecognized command 'dumpheap'

Why? Because now sos.dll is simply a loader, the commands like !dumpheap is implemented in a different dll that is not in the same folder with sos.dll. If you open the folder, it looks like this

So you don’t have the assemblies that contain the commands you need.

What you want is to install it with

dotnet-sos install

so it will be installed in a path like C:\Users\quma.dotnet\sos, and the folder should look like this

And then you can run .load C:\Users\quma\.dotnet\sos\sos.dll in WinDBG and everything should run as expected. Note that if you run .load command with wrong path before, you need to restart the debugging process. (Press Stop Debugging and Ctrl+D to reload the memory dump.