Hi all,

This post is a continuation of MANAGED DEBUGGING with WINDBG. Preparing the Environment.

We can only set breakpoints when doing live debugging, but many of the commands explained here can be used when doing dump analysis, too.

· We find the method where we want to set the breakpoint:

If we don’t know the name of the module, class or method we need, we can do the following:

0:004> !DumpDomain

...

--------------------------------------

Domain 1: 00094bd8

LowFrequencyHeap: 00094bfc

HighFrequencyHeap: 00094c54

StubHeap: 00094cac

Stage: OPEN

SecurityDescriptor: 00095938

Name: WindowsApplication1.exe

Assembly: 000d9748 [C:\Windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll]

ClassLoader: 0008d348

SecurityDescriptor: 000d6568

Module Name

790c2000 C:\Windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll

007823dc C:\Windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\sortkey.nlp

00782050 C:\Windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\sorttbls.nlp

Assembly: 000e4ba0 [C:\ __MANAGED DEBUGGING\BuggyNETApp\bin\Debug\WindowsApplication1.exe]

ClassLoader: 0008d658

SecurityDescriptor: 000e4b18

Module Name

00762c3c C:\ __MANAGED DEBUGGING\BuggyNETApp\bin\Debug\WindowsApplication1.exe

...

0:004> !DumpAssembly 000e4ba0

Parent Domain: 00094bd8

Name: C:\ __MANAGED DEBUGGING\BuggyNETApp\bin\Debug\WindowsApplication1.exe

ClassLoader: 0008d658

SecurityDescriptor: 00843678

Module Name

00762c3c C:\ __MANAGED DEBUGGING\BuggyNETApp\bin\Debug\WindowsApplication1.exe

0:004> !DumpModule -mt 00762c3c

Name: C:\ __MANAGED DEBUGGING\BuggyNETApp\bin\Debug\WindowsApplication1.exe

Attributes: PEFile

Assembly: 000e4ba0

LoaderHeap: 00000000

TypeDefToMethodTableMap: 007600c0

TypeRefToMethodTableMap: 007600ec

MethodDefToDescMap: 0076024c

FieldDefToDescMap: 00760344

MemberRefToDescMap: 007603a0

FileReferencesMap: 007605bc

AssemblyReferencesMap: 007605c0

MetaData start address: 01123128 (10832 bytes)

Types defined in this module

MT TypeDef Name

------------------------------------------------------------------------------

00763dbc 0x02000002 WindowsApplication1.My.MyApplication

00765e74 0x02000003 WindowsApplication1.My.MyComputer

00765c48 0x02000004 WindowsApplication1.My.MyProject

007661f4 0x02000005 WindowsApplication1.My.MyProject+MyForms

00766330 0x02000006 WindowsApplication1.My.MyProject+MyWebServices

00765de0 0x02000007 WindowsApplication1.My.MyProject+ThreadSafeObjectProvider`1

00766e94 0x02000008 WindowsApplication1.Form1

Types referenced in this module

MT TypeRef Name

------------------------------------------------------------------------------

5e4e3d4c 0x01000001 Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase

79104368 0x01000002 System.Collections.ArrayList

...

0:004> !DumpMT -md 00766e94

EEClass: 00ed0a30

Module: 00762c3c

Name: WindowsApplication1.Form1

mdToken: 02000008 (C:\ __MANAGED DEBUGGING\BuggyNETApp\bin\Debug\WindowsApplication1.exe)

BaseSize: 0x158

ComponentSize: 0x0

Number of IFaces in IFaceMap: 15

Slots in VTable: 395

--------------------------------------

MethodDesc Table

Entry MethodDesc JIT Name

7b05e348 7b4a4668 PreJIT System.Windows.Forms.Form.ToString()

...

7b068b6c 7b4a4680 PreJIT System.Windows.Forms.Form.OnResizeEnd(System.EventArgs)

00851638 00766d68 JIT WindowsApplication1.Form1.get_Button1()

...

0076c2d8 00766d60 JIT WindowsApplication1.Form1.InitializeComponent()

0076c1b4 00766e08 NONE WindowsApplication1.Form1.CopyMem(IntPtr, IntPtr, Int64)

0076c2ec 00766db8 NONE WindowsApplication1.Form1.Button1_Click(System.Object, System.EventArgs)

...

Now, the method we choose can be jitted (.NET compiles IL to asm when we are going to use a method for the first time - Just In Time-)/pre-jitted, or not:

0:004> !DumpMD 00766d60

Method Name: WindowsApplication1.Form1.InitializeComponent()

Class: 00ed0a30

MethodTable: 00766e94

mdToken: 06000021

Module: 00762c3c

IsJitted: yes

m_CodeOrIL: 00850a08

0:004> !DumpMD 00766db8

Method Name: WindowsApplication1.Form1.Button1_Click(System.Object, System.EventArgs)

Class: 00ed0a30

MethodTable: 00766e94

mdToken: 0600002d

Module: 00762c3c

IsJitted: no

m_CodeOrIL: ffffffff

If we know the name of the method and in which module we can find it, we can get the method descriptor and jitted address directly like this:

0:004> !Name2EE WindowsApplication1!WindowsApplication1.Form1.InitializeComponent

...

0:004> !Name2EE WindowsApplication1 WindowsApplication1.Form1.InitializeComponent

Module: 00762c3c (WindowsApplication1.exe)

Token: 0x06000021

MethodDesc: 00766d60

Name: WindowsApplication1.Form1.InitializeComponent()

JITTED Code Address: 00850a08

0:004> !Name2EE WindowsApplication1 WindowsApplication1.Form1.Button1_Click

Module: 00762c3c (WindowsApplication1.exe)

Token: 0x0600002d

MethodDesc: 00766db8

Name: WindowsApplication1.Form1.Button1_Click(System.Object, System.EventArgs)

Not JITTED yet. Use !bpmd -md 00766db8 to break on run.

And if we know the name of the method but not the module, we can still get the method descriptor and jitted address like this:

0:004> !Name2EE * WindowsApplication1.Form1.InitializeComponent

Module: 790c2000 (mscorlib.dll)

--------------------------------------

...

--------------------------------------

Module: 00762c3c (WindowsApplication1.exe)

Token: 0x06000021

MethodDesc: 00766d60

Name: WindowsApplication1.Form1.InitializeComponent()

JITTED Code Address: 00850a08

--------------------------------------

...

Like a process, an Application Domain or AppDomain is both a container and a boundary. The .NET runtime uses an AppDomain as a container for code and data and to isolate code inside of a secure boundary.

An AppDomain belongs to only a single process, but single process can hold multiple AppDomains: typically a system domain (tracks all domains), a shared domain (contains code which is shared between all the other app domains), and at least one other app domain (the main app domain of the app).

In ASP.NET, w3wp.exe will hold system and shared domains, and also a default domain and one app domain per web application (virtual directory marked as application):

0:000> !dumpdomain

--------------------------------------

System Domain: 7a38bb38

...

--------------------------------------

Shared Domain: 7a38c110

…

--------------------------------------

Domain 1: 001a8d58

…

Name: DefaultDomain

…

--------------------------------------

Domain 2: 001caff8

…

Name: /LM/w3svc/1/ROOT/DebuggingWorkshop-1-128030638920977997

…

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

Index: MANAGED DEBUGGING with WINDBG. Introduction and Index.

Regards,

Alex (Alejandro Campos Magencio)

Hi all,

This post is a continuation ofMANAGED 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*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)

Hi all,

This post is a continuation ofMANAGED DEBUGGING with WINDBG. Prerequisites.

· I won’t explain every single detail on WinDbg or debugger extension commands. I don’t want to duplicate much info. I will mainly focus on which commands to use and how to use them depending on the circumstances, with samples.

Disclaimer: there could be several ways to combine the commands and get the same info. I will just show my way. There could be better ways, and I would love to know them. Thanks!

· If we don’t know how a command works we can get extensive help in other places:

We can get help on WinDbg and its commands in Debugger.chm help file. We can open this file directly from the debugger:

0:000> .hh

We can also see all commands in an extension:

0:000> !SOS.help

Or we can get help for just one command in an extension:

0:004> !SOS.help !command

We won’t only get the possible parameters. We will also get useful explanations and tips to use the commands. I suggest you take a look to the help of every single command you use.

Next post: MANAGED DEBUGGING with WINDBG. Preparing the Environment.

Index: MANAGED DEBUGGING with WINDBG. Introduction and Index.

Regards,

Alex (Alejandro Campos Magencio)

Hi all,

This post is a continuation of MANAGED DEBUGGING with WINDBG. Introduction and Index.

· I won’t explain the following basic concepts here, so it’s better if you know them before trying to read these posts:

ü User Mode vs. Kernel Mode.

ü Differences between Application, Process and Thread.

ü Memory basics: differences between Virtual Memory, Stack, NT Heap, etc.

ü Symbols and Symbol Servers.

ü Call Stacks.

ü Crashes vs. Hangs.

ü First Chance vs. Second Chance Exceptions.

ü Full vs. Mini Dumps.

ü Debuggers & Debugger Extensions.

ü Unmanaged debugging basics.

· Tools we’ll need to install to follow these posts:

ü .NET Framework 2.0 SDK x86and/or .NET Framework 2.0 SDK x64.

ü WinDbg.exe debugger and other Debugging Tools for Windows.

ü SOS.dll debugger extension:

x86 à C:\Windows\Microsoft.NET\Framework\v2.0.50727

x64 à C:\Windows\Microsoft.NET\Framework64\v2.0.50727

ü Lutz Roeder’s .NET Reflector.

Next post: MANAGED DEBUGGING with WINDBG. Help.

Index: MANAGED DEBUGGING with WINDBG. Introduction and Index.

Regards,

Alex (Alejandro Campos Magencio)

Hi all,

The other dayI posted the list of commands I use on WinDbg when debugging .NET issues: SOS Cheat Sheet (.NET 2.0/3.0/3.5). In the next few posts I will provide you with additional info and samples on how to use those commands.

1.Prerequisites
2.Help
3.Preparing the Environment
4.Setting a Breakpoint. Part1. Part 2. Part 3
5.Call Stacks. Part 1. Part 2. Part 3
6.Threads. Part 1. Part 2
7.Thread Stacks. Part1. Part 2
8.Managed Heap. Part 1.Part 2. Part 3. Part 4. Part 5
9.Breaking on an Exception. Part 1. Part 2
10.Locks

Regards,

Alex (Alejandro Campos Magencio)