Home > Articles > Programming > Windows Programming

Debugging Tools for Windows: SOSEX Is Now CLR 4.0 Ready

  • Print
  • + Share This
  • 💬 Discuss
With the advent of CLR 4.0, Steve Johnson 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. Mario Hewardt details some of these new commands and how they work in relationship to a faulty application.

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:

  1. Specify the recursion level by using the -r switch. For example, to specify a recursion level of 2 simply use the -r 2 switch.
  2. 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.
  3. 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.

  • + Share This
  • 🔖 Save To Your Account

Discussions

comments powered by Disqus