CODEWITHSUNDEEP
c#windbg
mellow-yellow
mellow-yellow

Reputation: 1820

WinDBG: .loadby clr gives "Syntax error in extension string"

I'm new to WinDBG. On Windows 7 Pro 64-bit, I need to debug a running 32-bit application that loads .NET code, opens Silverlight, calls WebBrowser unmanaged ActiveX control and then causes an IE certificate error. I need to debug that certificate error--meaning, the unmanaged ActiveX part. Here are my steps:

> launch WinDBG.exe x86
> Click File -> Open Executable -> (open MYPROG.EXE)
> .load psscor2
> .loadby sos clr
Unable to find module 'clr'

> .loadby sos
Syntax error in extension string

Thoughts?

Upvotes: 1

Views: 1463

Answers (3)

Thomas Weller
Thomas Weller

Reputation: 59513

Your description is a bit confusing, since there are three parts to be considered:

  1. "a running 32-bit application that loads .NET code"
  2. "opens Silverlight"
  3. "calls WebBrowser unmanaged ActiveX control"

Regarding 1, running a .NET executable

I will assume that this is a .NET application, so the .NET framework is loaded first and then the application is run. From how you wrote the sentence, one could also think it's a C++ (native) application that runs and then loads .NET as a hosting process (which I think is unlikely).

WinDbg will stop at the "initial breakpoint", which is the first time the debugger can take control over the process. At this time, the executable has not run yet. For .NET, this also means that .NET has not been loaded yet.

You can wait until .NET was loaded by setting a breakpoint for loading the clr module like so:

sxe ld clr

When that breakpoint is hit, .loadby sos clr will work, since it can find the CLR module, determine its path and then load SOS from the same directory. The syntax error you're getting is because the command .loadby needs the second argument to search the related module.

Other than that, you can load SOS with .load and the full path. Just make sure you load the correct version.

Note that some of the commands may not work until .NET has also been initialized, i.e. the managed heap is functional. For "normal" .NET applications, you could set a breakpoint at the beginning of the Main method.

Regarding 2, Silverlight

For Silverlight, the .NET module is not clr but coreclr, so the command needs to be changed to

.loadby sos coreclr

If Silverlight is running as a separate process (sllauncher.exe), you may want to attach to that process (try .tlist and .attach) or debug child processes (.childdbg 1) to make sure you capture problems there. Switch between processes with |xs (where x is the process number).

Regarding 3, unmanaged ActiveX Control

This has nothing to do with .NET any more, so SOS will not help here (except to get the relationship between your .NET code and the native code).

You mention an "an IE certificate error". If that again is another process (iexplore.exe), attach to it as well (commands as before).

Upvotes: 2

Hans Passant
Hans Passant

Reputation: 942119

The .loadby command is a shortcut, it avoids having to type the full path name of the sos.dll file. It uses the path of the 2nd argument, clr.dll, to figure out where sos.dll is stored. That can only work if clr.dll is already loaded.

It is not in your case, Silverlight no doubt gets initialized later. And it doesn't use clr.dll, it uses the .NETCore version of the CLR, coreclr.dll. Also note that Silverlight has its own version of sos.dll

So you must type the full name:

   .load "C:\Program Files (x86)\Microsoft Silverlight\5.1.41212.0\sos.dll"

Replace 5.1.41212.0, if necessary, with the version of Silverlight on your machine.

Upvotes: 4

hoodaticus
hoodaticus

Reputation: 3880

You are getting that error because the CLR has not been loaded into the process. Make sure managed code has run before you try to load SOS that way, or else just use the full path to SOS.dll for your CLR version.

Upvotes: 2

Related Questions