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)