Decrypt my World

Cryptography, Security, Debugging and more!

MANAGED DEBUGGING with WINDBG. Preparing the Environment

MANAGED DEBUGGING with WINDBG. Preparing the Environment

  • Comments 2

Hi all,

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

 

PREPARING THE ENVIRONMENT

 

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*http://msdl.microsoft.com/downloads/symbols

Symbol search path is: srv*c:\symbols*\\symbols\symbols;srv*c:\symbolspub*http://msdl.microsoft.com/downloads/symbols

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

Symbol search path is: srv*c:\symbols*\\symbols\symbols;srv*c:\symbolspub*http://msdl.microsoft.com/downloads/symbols;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:

    c:\debuggers\WINXP;c:\debuggers\winext;...

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

ntdll!KiFastSystemCallRet:

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\mscorlib.ni.dll

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

KERNEL32!RaiseException+0x58:

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.

 

Regards,

 

Alex (Alejandro Campos Magencio)

Page 1 of 1 (2 items)
Leave a Comment
  • Please add 2 and 3 and type the answer here:
  • Post
Translate This Page