SOS Command: !DumpMethodSig <sigaddr> <moduleaddr>
SOS Command: !DumpAssembly <Assembly address>
Example output:
0:000>!dumpdomain ... 0:000> !dumpassembly 1ca248 Parent Domain: 0014f000 Name: C:pubunittest.exe ClassLoader: 001ca060 Module Name 001caa50 C:pubunittest.exe
An assembly can consist of multiple modules, and those will be listed. You can get an Assembly address from the output of !DumpDomain.
SOS Command: !ThreadPool
This command lists basic information about the ThreadPool, including the number of work requests in the queue, number of completion port threads, and number of timers.
!ThreadPool CPU utilization 0% Worker Thread: Total: 0 Running: 0 Idle: 0 MaxLimit: 0 MinLimit: 0 Work Request in Queue: 0 -------------------------------------- Number of Timers: 0 -------------------------------------- Completion Port Thread:Total: 0 Free: 0 MaxFree: 0 CurrentLimit: 0 MaxLimit: 1000 MinLimit: 0
SOS Command: !DumpModule [-mt] <Module address>
You can get a Module address from !DumpDomain, !DumpAssembly and other functions. Here is sample output:
0:000> !dumpmodule 1caa50 Name: C:pubunittest.exe Attributes: PEFile Assembly: 001ca248 LoaderHeap: 001cab3c TypeDefToMethodTableMap: 03ec0010 TypeRefToMethodTableMap: 03ec0024 MethodDefToDescMap: 03ec0064 FieldDefToDescMap: 03ec00a4 MemberRefToDescMap: 03ec00e8 FileReferencesMap: 03ec0128 AssemblyReferencesMap: 03ec012c MetaData start address: 00402230 (1888 bytes)
The Maps listed map metadata tokens to CLR data structures. Without going into too much detail, you can examine memory at those addresses to find the appropriate structures. For example, the TypeDefToMethodTableMap above can be examined:
0:000> dd 3ec0010 03ec0010 00000000 00000000 0090320c 0090375c 03ec0020 009038ec ...
This means TypeDef token 2 maps to a MethodTable with the value 0090320c. You can run !DumpMT to verify that. The MethodDefToDescMap takes a MethodDef token and maps it to a MethodDesc, which can be passed to !DumpMD.
There is a new option “-mt”, which will display the types defined in a module, and the types referenced by the module. For example:
0:000> !dumpmodule -mt 1aa580
Name: C:pubunittest.exe
...<etc>...
MetaData start address: 0040220c (1696 bytes)
Types defined in this module
MT TypeDef Name
------------------------------------------------------------------------------
030d115c 0x02000002 Funny
030d1228 0x02000003 Mainy
Types referenced in this module
MT TypeRef Name
------------------------------------------------------------------------------
030b6420 0x01000001 System.ValueType
030b5cb0 0x01000002 System.Object
030fceb4 0x01000003 System.Exception
0334e374 0x0100000c System.Console
03167a50 0x0100000e System.Runtime.InteropServices.GCHandle
0336a048 0x0100000f System.GC
SOS Command: !Token2EE <module name> <token>
This function allows you to turn a metadata token into a MethodTable or MethodDesc. Here is an example showing class tokens being resolved:
!token2ee unittest.exe 02000003 Module: 001caa38 Token: 0x02000003 MethodTable: 0090375c EEClass: 03ee1ae0 Name: Bank !token2ee image00400000 02000004 Module: 001caa38 Token: 0x02000004 MethodTable: 009038ec EEClass: 03ee1b84 Name: Customer
The module you are “browsing” with Token2EE needs to be loaded in the process. This function doesn’t see much use, especially since a tool like ILDASM can show the mapping between metadata tokens and types/methods in a friendlier way. But it could be handy sometimes.
You can pass “*” for <module name> to find what that token maps to in every loaded managed module. <module name> can also be the debugger’s name for a module, such as mscorlib or image00400000.
SOS Command: !DumpMD <MethodDesc address>
This command lists information about a MethodDesc. You can use !IP2MD to turn a code address in a managed function into a MethodDesc:
!DumpMD 00933008 Method Name: FindProduct.Program.AppendProduct(System.Collections.Generic.List`1<FindProduct.Product>) Class: 00931300 MethodTable: 00933024 mdToken: 06000002 Module: 00932c5c IsJitted: yes CodeAddr: 00ff00e8
If IsJitted is “yes,” you can run !U on the CodeAddr pointer to see a disassembly of the JITTED code. You can also call !DumpClass, !DumpMT, !DumpModule on the Class, MethodTable and Module fields above.
SOS Command: !DumpClass <EEClass address>
The EEClass is a data structure associated with an object type. !DumpClass will show attributes, as well as list the fields of the type. The output is similar to !DumpObj. Although static field values will be displayed, non-static values won’t because you need an instance of an object for that.
You can get an EEClass to look at from !DumpMT, !DumpObj, !Name2EE, and !Token2EE among others.
!dumpclass 00931300 Class Name: FindProduct.Program mdToken: 02000002 (C:svnNetInverseFindProductbinDebugFindProduct.exe) Parent Class: 790c3ef0 Module: 00932c5c Method Table: 00933024 Vtable Slots: 4 Total Method Slots: 5 Class Attributes: 100000 NumInstanceFields: 0 NumStaticFields: 0
SOS Commmand: !DumpMT [-MD] <MethodTable address>
Examine a MethodTable. Each managed object has a MethodTable pointer at the start. If you pass the “-MD” flag, you’ll also see a list of all the methods defined on the object.
.load sos ... !clrstack ... OS Thread Id: 0x6f8 (1784) ESP EIP 0012f3d4 00ff01b4 FindProduct.Program.AppendProduct(System.Collections.Generic.List`1<FindProduct.Product>) ... !ip2md 00ff01b4 MethodDesc: 00933008 Method Name: FindProduct.Program.AppendProduct(System.Collections.Generic.List`1<FindProduct.Product>) Class: 00931300 MethodTable: 00933024 ... !dumpmt 00933024 EEClass: 00931300 Module: 00932c5c Name: FindProduct.Program mdToken: 02000002 (C:svnNetInverseFindProductbinDebugFindProduct.exe) BaseSize: 0xc ComponentSize: 0x0 Number of IFaces in IFaceMap: 0 Slots in VTable: 7
SOS Command: !SyncBlk [-all | <syncblk number>]
A SyncBlock is a holder for extra information that doesn’t need to be created for every object. It can hold COM Interop data, HashCodes, and locking information for thread-safe operations.
When called without arguments, !SyncBlk will print the list of SyncBlocks corresponding to objects that are owned by a thread. For example, a
lock(MyObject)
{
....
}
statement will set MyObject to be owned by the current thread. A SyncBlock will be created for MyObject, and the thread ownership information stored there (this is an oversimplification, see NOTE below). If another thread tries to execute the same code, they won’t be able to enter the block until the first thread exits.
This makes !SyncBlk useful for detecting managed deadlocks. Consider that the following code is executed by Threads A & B:
Resource r1 = new Resource();
Resource r2 = new Resource();
...
lock(r1) lock(r2)
{ {
lock(r2) lock(r1)
{ {
... ...
} }
} }
This is a deadlock situation, as Thread A could take r1, and Thread B r2, leaving both threads with no option but to wait forever in the second lock statement. !SyncBlk will detect this with the following output:
0:003> !syncblk Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner 238 001e40ec 3 1 001e4e60 e04 3 00a7a194 Resource 239 001e4124 3 1 001e5980 ab8 4 00a7a1a4 Resource
It means that Thread e04 owns object 00a7a194, and Thread ab8 owns object 00a7a1a4. Combine that information with the call stacks of the deadlock: (threads 3 and 4 have similar output)
0:003> k ChildEBP RetAddr 0404ea04 77f5c524 SharedUserData!SystemCallStub+0x4 0404ea08 77e75ee0 ntdll!NtWaitForMultipleObjects+0xc 0404eaa4 5d9de9d6 KERNEL32!WaitForMultipleObjectsEx+0x12c 0404eb38 5d9def80 mscorwks!Thread::DoAppropriateAptStateWait+0x156 0404ecc4 5d9dd8bb mscorwks!Thread::DoAppropriateWaitWorker+0x360 0404ed20 5da628dd mscorwks!Thread::DoAppropriateWait+0xbb 0404ede4 5da4e2e2 mscorwks!CLREvent::Wait+0x29d 0404ee70 5da4dd41 mscorwks!AwareLock::EnterEpilog+0x132 0404ef34 5da4efa3 mscorwks!AwareLock::Enter+0x2c1 0404f09c 5d767880 mscorwks!AwareLock::Contention+0x483 0404f1c4 03f00229 mscorwks!JITutil_MonContention+0x2c0 0404f1f4 5b6ef077 image00400000!Worker.Work()+0x79 ...
By looking at the code corresponding to Worker.Work()+0×79 (run “!u 03f00229″), you can see that thread 3 is attempting to acquire the Resource 00a7a1a4, which is owned by thread 4.
NOTE:
It is not always the case that a SyncBlock will be created for every object that is locked by a thread. In version 2.0 of the CLR and above, a mechanism called a ThinLock will be used if there is not already a SyncBlock for the object in question. ThinLocks will not be reported by the !SyncBlk command. You can use “!DumpHeap -thinlock” to list objects locked in this way.