MANAGED DEBUGGING with WINDBG. Preparing the Environment

Hi all,

This post is a continuation of MANAGED DEBUGGING with WINDBG. Help.




Let’s assume we’ve attached WinDbg to our problematic .NET application just when it starts, so .NET dlls are not loaded in the process yet.

·         We verify the symbol path and set it to something useful:

0:000> .sympath

Symbol search path is: <empty>

0:000> .sympath srv*c:\symbols*\\symbols\symbols

Symbol search path is: srv*c:\symbols*\\symbols\symbols

0:000> .sympath+ srv*c:\symbolspub*

Symbol search path is: srv*c:\symbols*\\symbols\symbols;srv*c:\symbolspub*

0:000> .sympath+ C:\__MANAGED DEBUGGING\BuggyNETApp\bin\Debug

Symbol search path is: srv*c:\symbols*\\symbols\symbols;srv*c:\symbolspub*;C:\__MANAGED DEBUGGING\BuggyNETApp\bin\Debug


Without symbols we can find a lot of info from assembly metadata, but we won’t be able i.e. to step through the code with Source Mode On. While the .NET metadata contains the function names and parameter types, symbols provide source file names and line numbers.

·         We verify the source code path and set it to something useful:

0:000> .srcpath

Source search path is: <empty>

0:000> .srcpath \\sourceserver\myproduct\myproductversion\sources

Source search path is: \\sourceserver\myproduct\myproductversion\sources

0:000> .srcpath+ C:\__MANAGED DEBUGGING\BuggyNETApp

Source search path is: \\sourceserver\myproduct\myproductversion\sources;C:\__MANAGED DEBUGGING\BuggyNETApp


·         We verify the loaded extensions and load SOS.dll:

We take a look to the chain of loaded extensions, and verify if SOS is in there:

0:000> .chain

Extension DLL search Path:


Extension DLL chain:

    dbghelp: image 6.9.0001.70, API 6.1.6, built Tue Jan 08 04:04:26 2008

        [path: c:\debuggers\dbghelp.dll]


If not, we load it if we know its path and the version which corresponds to the version of the Framework:

0:000> .load SOS


We can find out the version of the Framework we are using and the SOS we need like this:

0:004> !EEVersion

2.0.50727.1433 retail

Workstation mode

SOS Version: 2.0.50727.42 retail build


Be careful, we may find wrong versions of the extensions loaded (i.e. SOS for .NET 1.1), so we will have to unload them first by using the path we saw with .chain:

0:000> .unload SOS

0:000> .unload PSSCor


We may let the debugger choose the right version of SOS for us. For that we need mscorwks.dll to be loaded:

0:000> sxe ld mscorwks.dll

0:000> g

ModLoad: 79e70000 7a3ff000   C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll

eax=0027f110 ebx=00000000 ecx=0027f108 edx=0006c37a esi=7ffdf000 edi=20000000

eip=77be0f34 esp=0027f14c ebp=0027f190 iopl=0         nv up ei pl zr na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246


77be0f34 c3              ret

0:000> .loadby SOS mscorwks


This is useful when doing live debugging.

We can do it in a different way, by waiting for the CLR notification exception which indicates that mscorlib.dll has been loaded. Mscorwks.dll will be loaded by then:

0:000> sxe -c “” clrn

0:000> g

ModLoad: 790c0000 79bf6000   C:\Windows\assembly\NativeImages_v2.0.50727_32\mscorlib\32e6f703c114f3a971cbe706586e3655\

CLR notification: module ‘mscorlib’ loaded

(1088.e68): CLR notification exception – code e0444143 (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

eax=0029fa20 ebx=0000000b ecx=00000002 edx=00000000 esi=00000000 edi=000d64f0

eip=77a1b09e esp=0029fa20 ebp=0029fa70 iopl=0         nv up ei pl nz ac po nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000212


77a1b09e c9              leave

0:000> .loadby SOS mscorwks


Or even better, we may instruct the debugger to load the right version of SOS automatically as soon as it can:

0:000> sxe -c “.loadby sos mscorwks; g” ld mscorwks.dll

0:000> g

ModLoad: 72800000 72d90000   C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll





Next post: MANAGED DEBUGGING with WINDBG. Setting a Breakpoint. Part 1.

Index: MANAGED DEBUGGING with WINDBG. Introduction and Index.




Alex (Alejandro Campos Magencio)

Comments (2)

  1. jrv says:

    Instead of:

    .load SOS

    which may result in loading the wrong version of SOS, use:

    .loadby sos mscorwks

    That loads the version of sos that corresponds to the version of mscorwks (


  2. Yes, you are right. ".loadby SOS" is also commented in this post 🙂