With the latest release of sosex comes a new set of functions to debug. It is pretty awesome that one person (Steve) alone could pull of such cool things. In this blog post, I am just going to demonstrate how easy it is to debug managed code using sosex compared to sos.
using System;
using System.Collections.Generic;
namespace MemCheck
{
internal class Test
{
Dictionary<int, string> dict = new Dictionary<int, string>();
private static void Main(string[] args)
{
var p = new Test();
for (int i = 0; i < 100; i++)
{
p.dict.Add(i, i.ToString());
}
Console.WriteLine("Done");
Console.Read();
}
}
}
I like to keep the code simple , so it is easy to follow. The debugging goal for today is to get the Dictionary values. First I am going to demonstrate it using sos and then using sosex.
As usual I start the app and then attach it to windbg.
.loadby sos clr
FYI in .net 4.0 clr is the dll that has CLR implementation. In prior versions it used to be in mscorwks. The next command would look for the object Test in the memory
!dumpheap -type MemCheck.Test 0:000> !dumpheap -type MemCheck.Test Address MT Size 0000000002761e20 000007ff00054110 24 total 0 objects Statistics: MT Count TotalSize Class Name 000007ff00054110 1 24 MemCheck.Test Total 1 objects
The next step is to dump the object
0:000> !do 0000000002761e20 Name: MemCheck.Test MethodTable: 000007ff00054110 EEClass: 000007ff00162350 Size: 24(0x18) bytes File: C:\Users\naveen\Documents\Visual Studio 2010\Projects\Test\bin\Debug\Test.exe Fields: MT Field Offset Type VT Attr Value Name 000007feec2b7a48 4000001 8 ...tring, mscorlib]] 0 instance 0000000002761e38 dict
Notice the dict object is in the 8th offset . To dump contents dict object I would use the command !do poi(0000000002761e20+8) , which is pointer deference of Test object on it is 8th offset. And here is the output
0:000> !do poi(0000000002761e20+8) Name: System.Collections.Generic.Dictionary`2[[System.Int32, mscorlib],[System.String, mscorlib]] MethodTable: 000007feec2b7a48 EEClass: 000007feebe113c0 Size: 88(0x58) bytes File: C:\Windows\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll Fields: MT Field Offset Type VT Attr Value Name 000007feec27c7d8 4000bee 8 System.Int32[] 0 instance 0000000002764788 buckets 000007feecbd3dc8 4000bef 10 ...non, mscorlib]][] 0 instance 0000000002764ab8 entries 000007feec27c848 4000bf0 40 System.Int32 1 instance 100 count 000007feec27c848 4000bf1 44 System.Int32 1 instance 100 version 000007feec27c848 4000bf2 48 System.Int32 1 instance -1 freeList 000007feec27c848 4000bf3 4c System.Int32 1 instance 0 freeCount 000007feec2a5a48 4000bf4 18 ...Int32, mscorlib]] 0 instance 0000000002761ef0 comparer 000007feecc75f78 4000bf5 20 ...Canon, mscorlib]] 0 instance 0000000000000000 keys 000007feecc72078 4000bf6 28 ...Canon, mscorlib]] 0 instance 0000000000000000 values 000007feec275ab8 4000bf7 30 System.Object 0 instance 0000000000000000 _syncRoot 000007feec29a1b8 4000bf8 38 ...SerializationInfo 0 instance 0000000000000000 m_siInfo
And the dictionary object in turn stores them within an array which is again the 8th offset. This time because we know it is an array we are going to use the !dumparray command on the memory location. The command to get the details is
!dumparray -details poi(poi(0000000002761e20+8)+8) MT Field Offset Type VT Attr Value Name 000007feec27c848 400047b 0 System.Int32 1 instance -1 m_value [195] 0000000002764aa4 Name: System.Int32 MethodTable: 000007feec27c848 EEClass: 000007feebe00890 Size: 24(0x18) bytes File: C:\Windows\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll Fields: MT Field Offset Type VT Attr Value Name 000007feec27c848 400047b 0 System.Int32 1 instance -1 m_value [196] 0000000002764aa8 Name: System.Int32 MethodTable: 000007feec27c848 EEClass: 000007feebe00890 Size: 24(0x18) bytes File: C:\Windows\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll Fields: MT Field Offset Type VT Attr Value Name 000007feec27c848 400047b 0 System.Int32 1 instance -1 m_value
Here is the partial output.
Now lets try and do the same thing using sosex. The one thing that I really like about the new sosex is that I can use names rather than pointer deference which is way much easier. Launched the app and then loaded sosex using the command
.load F:\Work\Tools\debuggers\sosex.dll
and then switched the thread from 4th to 0th thread using ~0s. By default the debugger injects a thread into the process for debugging and that was the 4th thread. The next command I issued was to get stack trace
!mk 0:000> !mk Thread 0: ESP EIP 00:U 000000000015e408 0000000077bc00da ntdll!ZwRequestWaitReplyPort+0xa 01:U 000000000015e410 0000000077a72b08 KERNEL32!ConsoleClientCallServer+0x54 02:U 000000000015e440 0000000077aa5601 KERNEL32!ReadConsoleInternal+0x1f1 03:U 000000000015e590 0000000077aba922 KERNEL32!ReadConsoleA+0xb2 04:U 000000000015e670 0000000077a89934 KERNEL32!zzz_AsmCodeRange_End+0x8bea 05:U 000000000015e6b0 000007feed0317c7 clr!DoNDirectCall__PatchGetThreadCall+0x7b 06:M 000000000015e760 000007feec1d34a1 DomainNeutralILStubClass.IL_STUB_PInvoke(Microsoft.Win32.SafeHandles.SafeFileHandle, Byte*, Int32, Int32 ByRef, IntPtr)(+0x0 IL)(+0x0 Native) 07:M 000000000015e880 000007feec97f59a System.IO.__ConsoleStream.ReadFileNative(Microsoft.Win32.SafeHandles.SafeFileHandle, Byte[], Int32, Int32, Int32, Int32 ByRef)(+0x53 IL)(+0xba Native) 08:M 000000000015e8f0 000007feec97f402 System.IO.__ConsoleStream.Read(Byte[], Int32, Int32)(+0x5d IL)(+0x62 Native) 09:M 000000000015e950 000007feec18e63c System.IO.StreamReader.ReadBuffer()(+0xa0 IL)(+0x5c Native) 0a:M 000000000015e9a0 000007feec915630 System.IO.StreamReader.Read()(+0x21 IL)(+0x30 Native) 0b:M 000000000015e9e0 000007feec987458 System.IO.TextReader+SyncTextReader.Read()(+0x0 IL)(+0x38 Native) 0c:M 000000000015ea30 000007ff00170213 MemCheck.Test.Main(System.String[])(+0x39 IL)(+0xf3 Native) [C:\Users\naveen\Documents\Visual Studio 2010\Projects\Test\Program.cs, @ 17,13] 0d:U 000000000015eaa0 000007feed0710b4 clr!CallDescrWorker+0x84 0e:U 000000000015eaf0 000007feed0711c9 clr!CallDescrWorkerWithHandler+0xa9 0f:U 000000000015eb70 000007feed071245 clr!MethodDesc::CallDescr+0x2a1 10:U 000000000015eda0 000007feed171675 clr!ClassLoader::RunMain+0x228 11:U 000000000015eff0 000007feed1717ac clr!Assembly::ExecuteMainMethod+0xac 12:U 000000000015f2a0 000007feed171562 clr!SystemDomain::ExecuteMainMethod+0x452 13:U 000000000015f850 000007feed173dd6 clr!ExecuteEXE+0x43 14:U 000000000015f8b0 000007feed173cf3 clr!CorExeMainInternal+0xc4 15:U 000000000015f920 000007feed1f7365 clr!CorExeMain+0x15 16:U 000000000015f960 000007fef8f13309 mscoreei!CorExeMain+0x41 17:U 000000000015f990 000007fef8fa5b21 MSCOREE!CorExeMain_Exported+0x57 18:U 000000000015f9c0 0000000077a6f56d KERNEL32!BaseThreadInitThunk+0xd 19:U 000000000015f9f0 0000000077ba3281 ntdll!RtlUserThreadStart+0x1d
FYI the command !mk has been part of sos from the initial version. I am interested in only looking at the code that I wrote so I would like to move stack frame to 0c which is MemCheck.Test.Main . To do that the command is !mframe 0c, which moves to that stackframe. The reason to move the particular stack frame is to look for variables in the stack and the command to variables is !mdv , which display managed local variables
0:000> !mdv Frame 0xc: (MemCheck.Test.Main(System.String[])): [A0]:args:0x0000000002761dd8 (System.String[]) [L0]:p:0x0000000002761e20 (MemCheck.Test) [L1]:i:0x0000000000000064 (System.Int32) [L2]:CS$4$0000:0x0000000000000000 (System.Boolean)
Notice we see the local variable “p” which is of type MemCheck.Test. To display type p we issue the command !mdt p
0:000> !mdt p 0000000002761e20 (MemCheck.Test) dict:0000000002761e38 (System.Collections.Generic.Dictionary`2[[System.Int32, mscorlib],[System.String, mscorlib]])
I didn’t have to get memory address , I am using the names which is very intuitive ,especially when we have to debug large application with N levels of nesting.So to get the dict values from p the command to issue is !mdt -e p.dict
!mdt -e p.dict [98] (System.Collections.Generic.Dictionary`2+Entry[[System.Int32, mscorlib],[System.String, mscorlib]]) VALTYPE (MT=000007feec2b7b28, ADDR=0000000002765400) key:0x62 (System.Int32) value:0000000002765e48 (System.String: "98") [99] (System.Collections.Generic.Dictionary`2+Entry[[System.Int32, mscorlib],[System.String, mscorlib]]) VALTYPE (MT=000007feec2b7b28, ADDR=0000000002765418) key:0x63 (System.Int32) value:0000000002765e68 (System.String: "99")
Here is the partial output. Notice I never had to use a memory pointer or do a pointer deference .This is very similar to VS.NET debugging where I am used to the variable names compared the memory address. Thanks to Steve for providing such a cool extension.
