136

Background: I'm new to WinDbg and trying to get it running for the first time. I want to examine a memory dump I took from a running ASP.NET 4 site hosted in IIS 7 on Windows Server 2008 (x86) and downloaded to my local machine.

I installed the debugging tools and launched WinDbg for the first time, opening the crash dump. I went to File | Symbol File Path and set the path to *srv*c:\symbols*http://msdl.microsoft.com/download/symbols* and waited for all the symbols to load.

When trying to load SOS, I ran into problems. First, I tried the following command...

.loadby sos mscorwks

...and received the response Unable to find module 'mscorwks'.

After scouring the web, I tried to load mscorwks by executing the following command...

sxe ld mscorwks.dll
g

...and received the response "No runnable debuggees error in 'g'"

I copied SOS.dll (from C:\Windows\Microsoft.NET\Framework\v4.0.30319) into the WinDbg directory, then tried...

.load sos

...and received the error...

The call to LoadLibrary(sos) failed, Win32 error 0n193
    "%1 is not a valid Win32 application."
Please check your debugger configuration and/or network access.

I'm not quite sure how to proceed. I just want to load SOS and dig around this dump file. Any help would be greatly appreciated.

Fyi...I am trying to open the dump file on a 64-bit version of Windows 7 with the 64-bit version of Windbg.

Community
  • 1
  • 1
Kevin Babcock
  • 10,187
  • 19
  • 69
  • 89

4 Answers4

212

The CLR runtime dll was renamed to clr.dll with .NET 4. So in order to load the correct version of SOS you need to adjust your .loadby command. I.e.

.loadby sos clr

Also, if you're on 64 bit, you should install the 32 bit version of Debugging Tools for Windows as well in order to debug 32 bit apps. They install side-by-side, so there's no problem in having both the 32 bit and the 64 bit version on the same machine.

I would advice against copying SOS.dll. SOS needs to match the exact version of the framework, so as long as you load it from the framework directory using .loadby, you're all set.

Matthew Steeples
  • 7,858
  • 4
  • 34
  • 49
Brian Rasmussen
  • 114,645
  • 34
  • 221
  • 317
  • I'm finding it challenging to get both on my system, since the latest installers autodetect the CPU type. Is there an override flag that you know of for the msi? I'm going to install an old 32bit version of WinDbg, but don't know what to expect. – Dave Dec 21 '10 at 07:51
  • 5
    @Dave: Maybe too little too late, but per the install webpage found here: http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx you can select to install the Redistributable Packages which puts MSIs for each architecture version here: C:\Program Files\Microsoft SDKs\Windows\v7.1\Redist\Debugging Tools for Windows – Aaron Lerch Jun 30 '11 at 14:39
  • 1
    If I say `.loadby sos clr` I get `Unable to find module 'clr'`. I'm trying to debug .NET 4 with x64 WinDbg – Csaba Toth Jun 04 '13 at 23:29
  • 2
    @CsabaToth is it a dump or are you doing live debugging? If you're doing live debugging the the CLR may not have been loaded yet. You can do `sxe ld clr` to stop when the CLR has been loaded and then you can load SOS at that point. – Brian Rasmussen Jun 05 '13 at 16:53
  • 1
    @BrianRasmussen It's a compiled executable. If I take a look at the Modules window, clr it loaded. – Csaba Toth Jun 06 '13 at 15:47
  • @CsabaToth Could you post a question with the relevant details please. – Brian Rasmussen Jun 06 '13 at 16:14
  • @BrianRasmussen: http://stackoverflow.com/questions/16926920/cannot-use-windbg-and-sos-in-visual-studio-immediate-window – Csaba Toth Jun 06 '13 at 16:31
  • In a nutshell: my main goal is to debug why/who/how loads a certain version of a 3rd party dll in a .NET desktop app. I start the program in non-native (not .NET) mode, so I can set a Function breakpoint to kernel32 dll. Then when the given assembly loads, I'd need to see the native (.NET) call stack too, and that's when I want to load the SOS. In my VS 2012 however WinDbg doesn't seem to be alive in the Immediate Window. In VS 2010 at least it spits meaningful error messages like WinDbg is there at least. – Csaba Toth Jun 06 '13 at 16:35
18

The WinDbg command 'g' means [Continue]

Since you're opening a dump-file there is no way to 'continue', it only contains the process memory.

So the message " No runnable debuggees error in 'g' " is logical in your case since the process is not running.

Concerning loading the correct version of SOS use the following command depending on the .NET version.

.NET 4 and higher .loadby sos

.NET 3.5 and 2 .loadby sos mscorwks

.NET 1.0 and 1.1 .load clr10\sos

HerbalMart
  • 1,669
  • 3
  • 27
  • 50
1

Answers above need improvement, since over the course of time things has been easier to handle sos loading.

JOHN ROBBINS has nice article around it, See that Microsoft symbol servers are configured in symbol file path and run !analyze -v on windbg prompt, this will do the trick it will download relevant sos files. To verify run .chain on the prompt and you will see the loaded dll.

Kiran Prabhu
  • 51
  • 1
  • 1
  • 7
  • The John Robbins article has been moved to https://www.wintellect.com/automatically-load-the-right-sos-for-the-minidump/ – Ryan Hill Oct 13 '20 at 14:27
0

Just came across a similar issue loading SOS and was getting "specified module could not be found". Came up with a different solution so if the solutions here don't help you, try this out:

.loadby sos clr - specified module could not be found

Community
  • 1
  • 1
Denis
  • 11,796
  • 16
  • 88
  • 150