次の方法で共有

MANAGED DEBUGGING with WINDBG. Preparing the Environment

  • [アーティクル]

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

Symbol search path is: srv*c:\symbols*\\symbols\symbols;srv*c:\symbolspub*https://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*https://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)

Comments

  • Anonymous
    July 19, 2009
    Instead of: .load SOSwhich may result in loading the wrong version of SOS, use:.loadby sos mscorwksThat loads the version of sos that corresponds to the version of mscorwks (http://msdn.microsoft.com/en-us/library/bb190764.aspx)JR
  • Anonymous
    July 19, 2009
    Yes, you are right. ".loadby SOS" is also commented in this post :-)