CODEWITHSUNDEEP
windbg
John164
John164

Reputation: 149

WinDbg can't load extension

I am having some trouble loading an extension in WinDbg preview. The extension code can be found here.

At present when I run .extpath I get the default path and the extension is saved in C:\Users\user\AppData\Local\Dbg\EngineExtensions32 however whenever I execute .chain the dll is extension is never loaded and attempting to load the extension manually results in the error The engine has been disconnected unexpectedly.

Error Message

How do I get this extension to load correctly?

As a side note to this on many applications when I attach to them with WinDbg and attempt to load sos.dll I just get the following output and nothing I have found online such as this or this has been able to rectify this:
.cordll -u -ve -l CLRDLL: No CLR image loaded (i.e. mscorwks.dll) CLR DLL status: No load attempts

How do I get the CLR SOS dll to load automatically each time WinDbg starts?

Upvotes: 1

Views: 2062

Answers (1)

Thomas Weller
Thomas Weller

Reputation: 59640

You are asking for help with 2 issues, so here are two answers. On this site we prefer one question at a time.

How do I get this extension to load correctly?

In the link you provided there is a note:

Though I believe I resolved the issue, it may be necessary that you copy the extension to the very same folder where WinDBG is located.

I could reproduce your issue and it was indeed fixed when I copied all the compilation artifacts into the WinDbg directory.

I've opened an issue on the Github repository for that.

How do I get the CLR SOS dll to load automatically each time WinDbg starts?

Loading SOS is not trivial for several reasons:

  • SOS cannot be loaded when WinDbg starts. It also needs a debugging session, so it either needs to be attached to a running program, a crash dump needs to be opened or a new process needs to be started. This means, you either need the -z to load a crash dump, -p to attach py PID, -pn to attach by process name or give the name of an executable.
  • SOS cannot be loaded at the initial breakpoint, because .NET is not available yet and it's unclear which version of SOS to load.
  • You need to run WinDbg in the correct bitness for SOS to load, otherwise it will fail with a bitness mismatch (something like BadImageFormatException in .NET).
  • depending on the .NET version, we need to load SOS where clr, coreclr or mscorwks is. Even worse, in some cases the .NET DLL is not even named correctly (e.g. mscorwks_64800000)
  • when using quotes, we might need to escape these quotes correctly

With that knowledge given, you can now construct a small script and pass that to WinDbg with the -c argument. But let's first identify what needs to be done.

First, we can simply try all .NET versions. two of them will fail and one of them will likely succeed if .NET was loaded. The three commands are

.loadby sos clr
.loadby sos coreclr
.loadby sos mscorwks

Now, we need to do that when .NET is loaded. It's fine for crash dumps or processes which have .NET already running. This will not work for processes started from scratch.

So, for the easy cases we have a command line like

windbg.exe -c ".loadby sos clr;.loadby sos coreclr;.loadby sos mscorwks" -z crash.dmp
windbg.exe -c ".loadby sos clr;.loadby sos coreclr;.loadby sos mscorwks" -p PID
windbg.exe -c ".loadby sos clr;.loadby sos coreclr;.loadby sos mscorwks" -pn name

Things get more complicated for starting new processes. Typically you could do it like

sxe -c".loadby sos clr;g" ld clr

to load SOS as early as the CLR DLL was loaded. Unfortunately, you can only have one ld breakpoint at a time and you can only specify one module. But, we can work around this by setting three unresolved breakpoints:

bu clr!EEStartup ".loadby sos clr;g"
bu mscorwks!EEStartup ".loadby sos mscorwks;g"
bu coreclr!EEStartup ".loadby sos coreclr;g"

Note that we run into ugly escaping problems with the quotes here. These cannot be resolved using double quotes (""), caret quotes (^") or other things we know from the command line. That's why we need to write a script. The command line is then

windbg -c "$$<loadsos.dbg;g" notepad.exe

where $$< is the command to run a script with the given name. That file then contains the needed commands

.loadby sos clr
.loadby sos coreclr
.loadby sos mscorwks
bu clr!EEStartup ".loadby sos clr;g"
bu mscorwks!EEStartup ".loadby sos mscorwks;g"
bu coreclr!EEStartup ".loadby sos coreclr;g"

Upvotes: 2

Related Questions