Debugging Tools for Windows: SOSEX Is Now CLR 4.0 Ready
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Introduction
The SOS managed code debugger extension has long been used by engineers to troubleshoot pesky bugs in managed code applications. While SOS contains a plethora of extremely powerful commands, there were some debugging tasks that were still tedious to perform. Luckily, Steve Johnson identified these tasks and wrote a debugger extension called SOSEX that addressed some of these deficiencies. Since debugger extensions are, generally speaking, strictly tied to the operating system or runtime version, a new release is typically made available with the release of a new version of the operating system or runtime. With the advent of CLR 4.0, Steve has not only updated his SOSEX debugger extension to work on the new version of the CLR but also added a bunch of new and useful commands. In this article, I'll detail some of these new commands and how they work in relationship to a faulty application.
Installation
The SOSEX v4.0 debugger extension can be downloaded from
http://www.stevestechspot.com/SOSEXV40NowAvailable.aspx
The installation process is very simple and comes in the form of a ZIP file (x86 or x64) that contains the sosex.dll. Simply extract the flavor you are interested in and place it in your favorite debugger extensions folder (I typically install it into the default debugger folder). You can then load the debugger extension in any of your debug sessions using the .load debugger command as shown below:
.load sosex.dll
New Commands
SOSEX provides a slew of new commands as well as enhancements to existing commands. In this section of the article I will describe some of the new commands that are available as part of this new release.
Enhancements to Existing Commands
The dlk command of SOSEX is incredibly useful when analyzing potential deadlock problems in your code. Rather than having to manually do lots and lots of analysis (dumping out potentially offending stacks, correlating the locks that are taken, etc.), the dlk command automates much of this process for you. In SOSEX v2.0 the dlk command was able to do deadlock analysis based on sync blocks and with version 4.0 it now extends that functionality to include the common ReaderWriterLock. Simply run the dlk command (without any parameters) and it will grovel through all the threads looking for potential deadlocks. For example, the below output is run on an application exhibiting a deadlock using a ReaderWriterLock:
0:004> !dlk
Examining SyncBlocks...
Scanning for ReaderWriterLocks...
Scanning for lock holders on ReaderWriterLocks...
Scanning for threads waiting on SyncBlocks...
Scanning for threads waiting on ReaderWriterLocks...
Deadlock detected:
CLR thread 1 holds a Writer lock on ReaderWriterLock 00000000023236c0
is waiting for a Writer lock on ReaderWriterLock 0000000002323680
CLR thread 3 holds a Writer lock on ReaderWriterLock 0000000002323680
is waiting for a Writer lock on ReaderWriterLock 00000000023236c0
CLR Thread 1 is waiting at Advanced.NET.Debugging.Chapter6.Deadlock.Main(System.String[])(+0x0 IL)(+0x0 Native)
CLR Thread 3 is waiting at Advanced.NET.Debugging.Chapter6.Deadlock.ThreadProc()(+0x0 IL)(+0x0 Native)
The mk command displays a call stack of the currently selected thread (including both managed and unmanaged frames). The command has now been extended to support the -a switch which outputs both the local variables as well as parameters (combination of -l and -p switches):
0:000> !mk -a
Thread 0:
ESP EIP
00:U 000000000022e278 00000000771e046a ntdll!ZwWaitForMultipleObjects+0xa
01:U 000000000022e280 000007fefd1a13a6 KERNELBASE!WaitForMultipleObjectsEx+0xe8
02:U 000000000022e380 0000000077093143 KERNEL32!WaitForMultipleObjectsExImplementation+0xb3
03:U 000000000022e410 000007fef83765f9 mscorwks!WaitForMultipleObjectsEx_SO_TOLERANT+0xc1
04:U 000000000022e4b0 000007fef837bac5 mscorwks!Thread::DoAppropriateAptStateWait+0x41
05:U 000000000022e510 000007fef83bbe9d mscorwks!Thread::DoAppropriateWaitWorker+0x191
06:U 000000000022e610 000007fef83975c0 mscorwks!Thread::DoAppropriateWait+0x5c
07:U 000000000022e680 000007fef8469afa mscorwks!CLREvent::WaitEx+0xbe
08:U 000000000022e730 000007fef8990407 mscorwks!CRWLock::RWWaitForSingleObject+0x57
09:U 000000000022e7e0 000007fef876695b mscorwks!CRWLock::StaticAcquireWriterLock+0x3a761f
0a:U 000000000022e840 000007fef8992446 mscorwks!CRWLock::StaticAcquireWriterLockPublic+0x106
0b:M 000000000022ea10 000007ff00170328 Advanced.NET.Debugging.Chapter6.Deadlock.Main(System.String[])
(+0x84 IL)(+0x208 Native) [C:\Zone\Deadlock\Deadlock\Program.cs, @ 51,13]
[A0]:args:0x00000000023235a0 (System.String[])
[L0]:newThread:0x0000000002323770 (System.Threading.Thread)
0c:U 000000000022eaa0 000007fef853d502 mscorwks!CallDescrWorker+0x82
0d:U 000000000022eaf0 000007fef83f9fd3 mscorwks!CallDescrWorkerWithHandler+0xd3
0e:U 000000000022eb90 000007fef840a3af mscorwks!MethodDesc::CallDescr+0x24f
0f:U 000000000022ede0 000007fef837dc7f mscorwks!ClassLoader::RunMain+0x22b
10:U 000000000022f040 000007fef8361c74 mscorwks!Assembly::ExecuteMainMethod+0xbc
11:U 000000000022f330 000007fef8399955 mscorwks!SystemDomain::ExecuteMainMethod+0x491
12:U 000000000022f900 000007fef84adb07 mscorwks!ExecuteEXE+0x47
13:U 000000000022f950 000007fef836855c mscorwks!_CorExeMain+0xac
14:U 000000000022f9b0 000007fef8d4253e MSCOREE!_CorExeMain+0x3e
15:U 000000000022f9e0 000000007708f56d KERNEL32!BaseThreadInitThunk+0xd
16:U 000000000022fa10 00000000771c3281 ntdll!RtlUserThreadStart+0x1d
The mdt command (nicely aligned with the native dt command) has also received a facelift by adding support for the following:
- Specify the recursion level by using the -r switch. For example, to specify a recursion level of 2 simply use the -r 2 switch.
- In addition to types, the mdt command now supports addressing individual fields using the dot notation. For example, specifying !mdt type1.field1 displays the field only. This part of the mdt command is incredibly useful when wanting to avoid navigating complicated hierarchies.
- In addition to "regular" types, the mdt command now understands how to traverse certain types of collections using the -e switch. More specifically, it has support for Array, ArrayList, List, HashTable and Dictionary.
The mx command (also nicely aligned with the native X command) now outputs far more information than previously including type specifics and auxiliary information. The generalized form of the mx output is shown below:
[type_specifics] <type_name> (<auxiliary_type_information)
The relationship between type speficics and auxiliary type information is detailed in Table 1.
Table 1: Relationship between type specifics and auxiliary type information
|
Type specifics |
Description |
Auxiliary type information |
|
T |
The item is a type |
|
|
VT |
The item is a value type |
Method table |
|
RT |
The item is a reference type |
Method table |
|
I |
The item is an interface |
|
|
F |
The item is a field |
Type of field |
|
M |
The item is a method |
Method descriptor |
|
SF |
The item is a static field |
Type of field |
|
SM |
The item is a static method |
Method descriptor |
New Commands
A finalizer is a very common way to properly release native resources. At a high level, an object that implements a finalizer goes on what is known as finalization queue that the CLR uses in order to know which objects have finalizers. Please note that an object with a finalizer (rooted or not), will be placed on the finalization queue. Once an object becomes rootless, the object is moved to another data structure called the f-reachable queue where it will live until the CLR invokes the objects finalize method and the object is considered dead (excluding resurrection scenarios). The ability to inspect both the finalization queue (i.e., knowing which objects have finalizers) as well as the f-reachable queue is extremely important when debugging memory related issues. SOSEX v4.0 introduces two new commands that can be used for this inspection.
The finq command (finalization queue) lists all the objects that are on the finalization queue. An example is shown below:
0:003> !finq Generation 0: Address Size Type --------------------------------------------------------- 00000000025a2b78 104 System.Threading.Thread 00000000025a36c0 24 Advanced.NET.Debugging.Chapter5.NativeEvent 00000000025a51b0 32 Microsoft.Win32.SafeHandles.SafeViewOfFileHandle 00000000025a51d0 32 Microsoft.Win32.SafeHandles.SafeFileMappingHandle 00000000025a53b0 32 Microsoft.Win32.SafeHandles.SafeFileHandle 00000000025a5978 32 Microsoft.Win32.SafeHandles.SafeViewOfFileHandle 00000000025a5998 32 Microsoft.Win32.SafeHandles.SafeFileMappingHandle 7 objects, 288 bytes Generation 1: Address Size Type --------------------------------------------------------- 0 objects, 0 bytes Generation 2: Address Size Type --------------------------------------------------------- 0 objects, 0 bytes TOTAL: 7 objects, 288 bytes
The output of the above command shows that we have 7 objects (total size of 288 bytes) on the finalization queue all belonging to generation 0. If you are only interested in the high level statistics (not on a per object basis), you can use the -stat switch. Alternatively, if you are only interested in a specific generation, you can simply specify the generation number as a parameter.
The frq command (f-reachable queue) on the other hand, lists all objects that are on the f-reachable queue as shown below:
0:003> !frq -stat
Freachable Queue:
Count Total Size Type
---------------------------------------------------------
1 32 Microsoft.Win32.SafeHandles.SafePEFileHandle
998 23952 TestFin.Fin
999 objects, 23984 bytes
Summary
In this article we took a look at the new release of the SOSEX managed code debugger extension. SOSEX contains a plethora of new powerful commands as well as extensions to the existing commands. Best of all, the latest version is now fully compatible with CLR v2.0 as well as CLR v4.0. While we only looked at some of the extended commands and some of the more commonly used new commands, there is more to the debugger extension and I urge the reader to take a closer look at some of the other commands it has to offer.