CLR Discovery Series: Windbg+sos dynamic debug Profiling managed code

http://blog.csdn.net/garyye/article/details/4788070 

When using VS for managed application debugging, sometimes it's always a bit of a struggle. For example, when looking at a managed heap or a compute stack, VS is not competent. This time, the Windbg+sos extension debugging module provides us with a good solution.
Let's look at a piece of code:
Class Program
{
static void Main (string[] args)
{
Program B = new program ();
B.test ();
System.Console.ReadLine ();
}

public void Test ()
{
int i = 67;
System.Console.WriteLine ((char) i);
System.Console.WriteLine ((char) 67);
i = 1;
}
}
This is a forced type conversion in C #, and we now use Windbg+sos to parse the evaluation stack and to force the JIT code after the type conversion.
Load the running program in WinDbg, attach to this process, and then load the SOS Extension Debug module:
0:003>. Load C:/windows/microsoft.net/framework/v2.0.50727/sos.dll
The current thread is then displayed:
0:003> ~
0 id:cf0.450 suspend:1 teb:7ffdf000 unfrozen
1 Id:cf0.be8 suspend:1 teb:7ffdd000 unfrozen
2 id:cf0.168 suspend:1 teb:7ffdc000 unfrozen
. 3 id:cf0.7d0 suspend:1 teb:7ffde000 unfrozen
Switch to a No. 0 thread:
0:003> ~0s
Eax=0012f2e4 ebx=00000000 ecx=0012f400 edx=00000008 esi=0012f1f4 edi=00250688
eip=7c92eb94 esp=0012f194 ebp=0012f1b4 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:
7C92EB94 c3 ret
Displays the address associated with the test method:
0:000>!NAME2EE TestConcoleApp.exe TestConcoleApp.Program.test
MODULE:00AB2C24 (TestConcoleApp.exe)
token:0x06000002
Methoddesc:00ab2ff0
Name:TestConcoleApp.Program.test ()
Jitted Code Address:00d000f8
Shows the IL code after this method was compiled by the C # compiler:
0:000>!dumpil 00ab2ff0
ILADDR = 00402074
Il_0000:nop
IL_0001:LDC.I4.S 67
il_0003:stloc.0
il_0004:ldloc.0
IL_0005:conv.u2
Il_0006:call System.console::writeline
Il_000b:nop
IL_000C:LDC.I4.S 67
Il_000e:call System.console::writeline
Il_0013:nop
il_0014:ldc.i4.1
il_0015:stloc.0
Il_0016:ret

Here, Sandwi to conv.u2 This instruction has been puzzled a lot. I also puzzled over this question for a long time, read a lot of information also did not find, later prepared in SSCLI C # compiler inside find the answer, but did not find the place ...
It was later confirmed that this directive was a command generated by the C # compiler for type safety. The function is to convert an integer into a unsigned int16, and then 0 for int32 to press into the stack.
This is a language compiler behavior, in order to confirm the idea, at the same time wrote a similar VB code to confirm our idea:
Module Module1

Sub Main ()
Dim I as Integer

i = 67
System.Console.WriteLine (CHR (i))
System.Console.WriteLine (CHR (67))
System.Console.ReadLine ()

End Sub

End Module
The post-compilation Il Code also supports the idea above.
Here, thanks to Microsoft's MBE confirmed my conjecture about the reason for the existence of CONV.U2. However, Zhangyi said that the CONV.U2 directive in the test method was optimized in the JIT-generated native code, but I disagree with this:
0:000>!u 00d000f8
This instruction is the local code that displays the JIT-compiled test method, based on
Jitted Code Address:00d000f8
In this line. The results appear as follows:
Normal JIT Generated code
TestConcoleApp.Program.test ()

Push ESI
Push EAX
mov DWORD ptr [ESP],ECX
CMP DWORD ptr ds:[0ab2dd8h],0
Je 00d0010b (jump to XOR Esi,esi here)
Call mscorwks! CORLAUNCHAPPLICATION+0X108B4 (7a08e179)
XOR Esi,esi
Nop
MOV esi,43h
MOVZX Ecx,si
Call mscorlib_ni+0x2f8b9c (793b8b9c) (System.Console.WriteLine (Char), mdtoken:06000759)
Nop
MOV ecx,43h
Call mscorlib_ni+0x2f8b9c (793b8b9c) (System.Console.WriteLine (Char), mdtoken:06000759)
Nop
MOV esi,1
Pop ecx
Pop esi
Ret
Here, movzx ecx,si This instruction corresponds to the IL code inside the CONV.U2, the corresponding int before 0 into the ECX register.

PostScript: About dynamic debugging managed code, I also just contact soon, above has inaccurate place, welcome everybody to correct a lot

CLR Discovery Series: Windbg+sos dynamic debug Profiling managed code