· Let's review previous commands:

Let’s see a sample where the debugger broke when “PlayWithArray” raised an exception. We can use the return address of the function it called, “mscorwks!JIT_RngChkFail”, to see where in “PlayWithArray” we were when the exception happened:

0:000> kL

ChildEBP RetAddr

0027e600 79f071ac KERNEL32!RaiseException+0x58

0027e660 79f9293a mscorwks!RaiseTheExceptionInternalOnly+0x2a8

0027e698 7a129a34 mscorwks!UnwindAndContinueRethrowHelperAfterCatch+0x70

0027e738 00371aad mscorwks!JIT_RngChkFail+0xb0

0027e780 003719fe WindowsApplication1!WindowsApplication1.Form1.PlayWithArray(Int32[])+0x55

...

0:000> !u 00371aad

Normal JIT generated code

WindowsApplication1.Form1.PlayWithArray(Int32[])

Begin 00371a58, size c0

00371a58 55 push ebp

...

00371aa0 8b4dc8 mov ecx,dword ptr [ebp-38h]

00371aa3 3b5104 cmp edx,dword ptr [ecx+4]

00371aa6 7205 jb WindowsApplication1!WindowsApplication1.Form1.PlayWithArray(Int32[])+0x55 (00371aad)

00371aa8 e8d67edb79 call mscorwks!JIT_RngChkFail (7a129983)

>>> 00371aad 03449108 add eax,dword ptr [ecx+edx*4+8]

00371ab1 7105 jno WindowsApplication1!WindowsApplication1.Form1.PlayWithArray(Int32[])+0x60 (00371ab8)

00371ab3 e8837fdb79 call mscorwks!JIT_Overflow (7a129a3b)

...

00371b16 5d pop ebp

00371b17 c3 ret

0:000> u 00371aa8

WindowsApplication1!WindowsApplication1.Form1.PlayWithArray(Int32[])+0x50 [C:\__WORKSHOP\Demos\BuggyNETApp\Form1.vb @ 135]:

...

Note how we used the unmanaged version of this command, u, to find out the source code line.

That line corresponds to the following VB.NET statement in “PlayWithArray”:

result += array(i)

It seems we got some exception when accessing the array... Can we tell why? Let’s give it a try:

0:000> !CLRStack -a

OS Thread Id: 0x1f3c (0)

ESP EIP

0027e6f0 77a1b09e [HelperMethodFrame: 0027e6f0]

0027e740 00371aad WindowsApplication1.Form1.PlayWithArray(Int32[])

PARAMETERS:

this = 0x0192f338

array = 0x01983d38

LOCALS:

0x0027e758 = 0x00000000

0x0027e754 = 0x00000006

0x0027e750 = 0x00000003

0x0027e744 = 0x00000000

0x0027e74c = 0x00000003

...

0:000> !da 0x01983d38

Name: System.Int32[]

MethodTable: 7912d7c0

EEClass: 7912d878

Size: 24(0x18) bytes

Array: Rank 1, Number of elements 3, Type Int32

Element Methodtable: 79102290

[0] 00000001

[1] 00000002

[2] 00000003

It seems we tried to access the element at index 3 of the array (the 4^th element), but the array only has 3 elements.

How do I know which local corresponds to “i”? ILDASM may help here, because the locals it shows are in the same order as in !CLRStack. In our case, “i” is in the 3^rd position:

// Code size 49 (0x31)

.maxstack 3

.locals init ([0] int32 PlayWithArray,

[1] int32 result,

[2] int32 i,

[3] class [mscorlib]System.Exception ex,

[4] int32 VB$CG$t_i4$S0)

· We can use registers to check parameters of a method in the call stack:

When we are at the beginning of a function, we must take into consideration that JIT compiler uses _fastcall calling convention. This means that the first two parameters will be passed in the ecx and edx registers. Ecx is used to hold the “this” pointer. We can use those registers to inspect the parameters:

0:000> g

Breakpoint 0 hit

eax=001a6e28 ebx=01ad8880 ecx=01a9f338 edx=01ada608 esi=01ada608 edi=01a9f338

eip=008f1a58 esp=002fe8a4 ebp=00000000 iopl=0 nv up ei ng nz na pe cy

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

WindowsApplication1!WindowsApplication1.Form1.PlayWithArray(Int32[]):

008f1a58 55 push ebp

0:000> !CLRStack -p

OS Thread Id: 0x17fc (0)

ESP EIP

002fe8a4 008f1a58 WindowsApplication1.Form1.PlayWithArray(Int32[])

PARAMETERS:

this = 0x01a9f338

array = 0x01ada608

...

002ff044 79e7c74b [GCFrame: 002ff044]

0:000> !do @ecx

Name: WindowsApplication1.Form1

...

0:000> !da @edx

Name: System.Int32[]

...

Array: Rank 1, Number of elements 3, Type Int32

...

Note that later in the function, esi is typically used to hold the “this” pointer (gotten from ecx).

First of all, Source Code mode has to be enabled. We’ll need symbols and source code files correctly configured.

We can choose the frame of the method we want to see:

0:000> knL100

# ChildEBP RetAddr

00 0027e600 79f071ac KERNEL32!RaiseException+0x58

01 0027e660 79f9293a mscorwks!RaiseTheExceptionInternalOnly+0x2a8

02 0027e698 7a129a34 mscorwks!UnwindAndContinueRethrowHelperAfterCatch+0x70

03 0027e738 00371aad mscorwks!JIT_RngChkFail+0xb0

04 0027e780 003719fe WindowsApplication1!WindowsApplication1.Form1.PlayWithArray(Int32[])+0x55

05 00000000 7b062c9a WindowsApplication1!WindowsApplication1.Form1.Button6_Click(System.Object, System.EventArgs)+0x86

06 0027e7e8 7b11cb29 System_Windows_Forms_ni!System.Windows.Forms.Control.OnClick(System.EventArgs)+0x6a

...

0:000> .frame 4

04 0027e780 003719fe WindowsApplication1!WindowsApplication1.Form1.PlayWithArray(Int32[])+0x55 [C:\__WORKSHOP\Demos\BuggyNETApp\Form1.vb @ 135]

WinDbg will automatically open the source code file and locate where in the function we are in this call stack:

Private Function PlayWithArray(ByVal array As Integer()) As Integer

Dim result As Integer

Try

For i As Integer = 0 To 3

result += array(i)

Next

Catch ex As Exception

result = -1

End Try

Return result

End Function

· We can see the MSIL (Microsoft Intermediate Language) of a method in the call stack:

When compiling to managed code, the compiler translates our source code into Microsoft intermediate language (MSIL), which is a CPU-independent set of instructions that can be efficiently converted to native code. MSIL includes instructions for loading, storing, initializing, and calling methods on objects, as well as instructions for arithmetic and logical operations, control flow, direct memory access, exception handling, and other operations. Before code can be run, MSIL must be converted to CPU-specific code by a just-in-time (JIT) compiler.

To see the IL, we first need to get the method descriptor like this:

0:000> !CLRStack

OS Thread Id: 0x1f3c (0)

ESP EIP

0027e6f0 77a1b09e [HelperMethodFrame: 0027e6f0]

0027e740 00371aad WindowsApplication1.Form1.PlayWithArray(Int32[])

0027e788 003719fe WindowsApplication1.Form1.Button6_Click(System.Object, System.EventArgs)

0027e7a8 7b062c9a System.Windows.Forms.Control.OnClick(System.EventArgs)

...

0:000> !IP2MD 00371aad

MethodDesc: 00116e28

Method Name: WindowsApplication1.Form1.PlayWithArray(Int32[])

Class: 00380a30

MethodTable: 00116ecc

mdToken: 06000039

Module: 00112c3c

IsJitted: yes

m_CodeOrIL: 00371a58

Or directly with:

0:000> !DumpStack -EE

OS Thread Id: 0x1f3c (0)

Current frame:

ChildEBP RetAddr Caller,Callee

0027e738 00371aad (MethodDesc 0x116e28 +0x55 WindowsApplication1.Form1.PlayWithArray(Int32[]))

...

Additionally, if we just hit a breakpoint, we can also use the eip (Instruction Pointer) register for this purpose:

0:000> !IP2MD @eip

MethodDesc: 00116e28

Method Name: WindowsApplication1.Form1.PlayWithArray(Int32[])

...

Now we can take a look to IL code for that method:

0:000> !DumpIL 00116e28

ilAddr = 00d73298

IL_0000: nop

IL_0001: nop

.try

{

IL_0002: ldc.i4.0

IL_0003: stloc.2

IL_0004: ldloc.1

IL_0005: ldarg.1

IL_0006: ldloc.2

IL_0007: ldelem.i4

IL_0008: add.ovf

IL_0009: stloc.1

IL_000a: nop

IL_000b: ldloc.2

IL_000c: ldc.i4.1

IL_000d: add.ovf

IL_000e: stloc.2

IL_000f: ldloc.2

IL_0010: ldc.i4.3

IL_0011: stloc.s VAR OR ARG 4

IL_0013: ldloc.s VAR OR ARG 4

IL_0015: ble.s IL_0104

IL_0017: leave.s IL_002a

} // end .try

.catch

{

IL_0019: dup

IL_001a: call Microsoft.VisualBasic.CompilerServices.ProjectDat::SetProjectError

IL_001f: stloc.3

IL_0020: nop

IL_0021: ldc.i4.m1

IL_0022: stloc.1

IL_0023: call Microsoft.VisualBasic.CompilerServices.ProjectDat::ClearProjectError

IL_0028: leave.s IL_002a

} // end .catch

IL_002a: nop

IL_002b: ldloc.1

IL_002c: stloc.0

IL_002d: br.s IL_002f

IL_002f: ldloc.0

IL_0030: ret

Tip for Reading IL: The CLR is stack-based. A two-operand operation such as Add pops the two top values from the stack and adds them.

ILDASM.exe (Visual Studio.NET) will show the same IL code that we’ve just seen, plus the following declarations just before it:

// Code size 49 (0x31)

.maxstack 3

.locals init ([0] int32 PlayWithArray,

[1] int32 result,

[2] int32 i,

[3] class [mscorlib]System.Exception ex,

[4] int32 VB$CG$t_i4$S0)

And Reflector.exe will show our function like this:

Private Function PlayWithArray(ByVal array As Integer()) As Integer

Dim result As Integer

Try

Dim VB$CG$t_i4$S0 As Integer

Dim i As Integer = 0

Do

result = (result + array(i))

i += 1

VB$CG$t_i4$S0 = 3

Loop While (i <= VB$CG$t_i4$S0)
Catch exception1 As Exception

ProjectData.SetProjectError(exception1)

Dim ex As Exception = exception1

result = -1

ProjectData.ClearProjectError

End Try

Return result

End Function

All this may help us to understand the correspondence between our code and its IL version.

· We can write an image loaded in memory to a file:

You can save a module after patching it on the fly when live debugging, or get the original DLLs or EXEs when debugging a dump. If we save a managed binary, we can use the file with ILDASM.exe or Reflector.exe, for instance. We save a module like this:

0:004> lm

start end module name

00a20000 00a2c000 WindowsApplication1 (deferred)

…

79e70000 7a3ff000 mscorwks (private pdb symbols) c:\symbols\mscorwks.pdb\62286AFFFC674D5198883B98518936FF2\mscorwks.pdb

...

7afd0000 7bc6c000 System_Windows_Forms_ni (deferred)

0:004> !SaveModule 79e70000 c:\mscorwks.dll

5 sections in file

section 0 - VA=1000, VASize=53abd2, FileAddr=400, FileSize=53ac00

section 1 - VA=53c000, VASize=9, FileAddr=53b000, FileSize=200

section 2 - VA=53d000, VASize=189d0, FileAddr=53b200, FileSize=16000

section 3 - VA=556000, VASize=670, FileAddr=551200, FileSize=800

section 4 - VA=557000, VASize=37bc4, FileAddr=551a00, FileSize=37c00

· We can see the assembly code of a method in the call stack:

If method is jitted, we can see its assembly code as we will do it with any other unmanaged method:

0:000> !DumpStack -EE

OS Thread Id: 0x1f3c (0)

Current frame:

ChildEBP RetAddr Caller,Callee

0027e738 00371aad (MethodDesc 0x116e28 +0x55 WindowsApplication1.Form1.PlayWithArray(Int32[]))

...

0:000> !DumpMD 0x116e28

Method Name: WindowsApplication1.Form1.PlayWithArray(Int32[])

Class: 00380a30

MethodTable: 00116ecc

mdToken: 06000039

Module: 00112c3c

IsJitted: yes

m_CodeOrIL: 00371a58

0:000> uf 00371a58

WindowsApplication1!WindowsApplication1.Form1.PlayWithArray(Int32[]) [C:\__WORKSHOP\Demos\BuggyNETApp\Form1.vb @ 129]:

129 00371a58 55 push ebp

129 00371a59 8bec mov ebp,esp

129 00371a5b 57 push edi

129 00371a5c 56 push esi

129 00371a5d 53 push ebx

129 00371a5e 83ec34 sub esp,34h

129 00371a61 33c0 xor eax,eax

129 00371a63 8945e8 mov dword ptr [ebp-18h],eax

...

...

WindowsApplication1!WindowsApplication1.Form1.PlayWithArray(Int32[])+0xb5 [C:\__WORKSHOP\Demos\BuggyNETApp\Form1.vb @ 144]:

144 00371b0d 8b45d8 mov eax,dword ptr [ebp-28h]

144 00371b10 8d65f4 lea esp,[ebp-0Ch]

144 00371b13 5b pop ebx

144 00371b14 5e pop esi

144 00371b15 5f pop edi

144 00371b16 5d pop ebp

144 00371b17 c3 ret

Note that if we have symbols we can tell the line number in the source code file.

We have a .NET version of uf command which understands managed code:

0:000> !u 00371a58

Normal JIT generated code

WindowsApplication1.Form1.PlayWithArray(Int32[])

Begin 00371a58, size c0

>>> 00371a58 55 push ebp

00371a59 8bec mov ebp,esp

00371a5b 57 push edi

00371a5c 56 push esi

00371a5d 53 push ebx

00371a5e 83ec34 sub esp,34h

00371a61 33c0 xor eax,eax

00371a63 8945e8 mov dword ptr [ebp-18h],eax

...

00371b16 5d pop ebp

00371b17 c3 ret

You can pass to this command any address within that method and it will show the same assembly and where we are in it (>>>).

Note that we may run this command with an address within an unmanaged method and if we have private symbols and source code, it shows all the assembly in that method along with the source code itself!