Posts Tagged ‘.NET’

The Debugger Extension, Part 5 - Manipulating Managed Types

The Debugger Extension

In the last post in this series, we succeeded in writing a working extension that searched memory for instances of a particular type. Trouble is, we haven't done anything useful yet. We've merely duplicated a very small subset of the functionality offered by SOS's !DumpHeap command, and poorly at that.

In the problem setup, we said we wanted to show statistics about a particular property of these instances–for the purposes of this example, we're calling that their "Color." A sensible step in this direction would be to write some utility C++ code to accompany the Colors enumeration that we wrote earlier in C#.

// Some definitions that correspond to the managed
// SampleApp.Colors enum.
typedef ULONG Color;
const Color COLOR_RED = 0;
const Color COLOR_GREEN = 1;
const Color COLOR_BLUE = 2;
const Color COLOR_PURPLE = 3;
const Color MAX_COLOR = COLOR_PURPLE;

PCSTR g_szColorNames[] = { "Red", "Green",
    "Blue", "Purple" };

bool IsColor(Color c)
{
    if( c <= MAX_COLOR )
    {
        return true;
    }
    return false;
}

PCSTR ColorName(Color c)
{
    if( !IsColor(c) )
    {
        return NULL;
    }
    return g_szColorNames[static_cast<int>(c)];
}

Part of the point of this series has been to develop a framework that deals with instances of .NET objects. To that end, we should try to write a generic base class that loads a managed instance in the debuggee into the debugger's process. This is my implementation of such a class.

// ------------------------------------------------------
// mtypes.h
//        Some base classes for dealing with instances
//        of managed objects.
//
#pragma once

template<class object_fields>
class ManagedInstance
{
protected:
    object_fields m_Fields;
    ULONG64 m_offset;
    bool m_valid;

    // Can be used by derived classes can to refer
    // to this class.
    typedef ManagedInstance<object_fields> base_t;

    // Constructor - pass the offset of the managed
    // object. Check the result of IsValid() before
    // using an instance derived from this class.
    ManagedInstance(ULONG64 offset) : m_Fields()
    {
        // Load the data for the fields from the
        // debugee process / memory dump
        IDebugDataSpaces* pData = g_Ext->m_Data;
        m_offset = offset;
        ULONG read = 0L;
        HRESULT hr = pData->ReadVirtual(
            m_offset,
            reinterpret_cast<void*>(&m_Fields),
            sizeof(object_fields),
            &read);
        m_valid = SUCCEEDED(hr) &&
            (read == sizeof(object_fields));
    }

    virtual ~ManagedInstance() {}

public:
    // Returns true if the object was successfully
    // read from the debugee. Doesn't validate that
    // it actually is a managed object of the desired
    // type, but overridden implementations should
    // do this.
    virtual bool IsValid() { return m_valid; }
};

// This can be used as a base class for classes used
// as the object_fields template parameter.
class ObjectFields
{
public:
    ULONG pMethodTable;
};

The template parameter for the ManagedInstance class takes a POD ("plain old data") type that should just list the fields in the instance. The constructor for ManagedInstance loads the data at the specified offset as those fields. I declared a virtual function that indicates whether or not the managed instance is valid. In this base class, all we can really say about that is whether or not we could read the data at the provided address.

I've also defined a base class for the fields of a managed object, and put the MethodTable address in it. Given these classes, it's not a lot of work to write the implementations for ArbitraryType.

// Represents the fields of a
// SampleApp.ArbitraryType instance.
class ArbitraryTypeFields
     : public ObjectFields
{
public:
    Color col;
    ULONG id;
};

// Represents a single ArbitraryType instance.
class ArbitraryType :
    public ManagedInstance<ArbitraryTypeFields>
{
public:
    ArbitraryType(ULONG64 offset)
        : base_t(offset) {}
    virtual bool IsValid();
    Color GetColor() { return m_Fields.col; }
};

// Returns true if the loaded data is a valid
// ArbitraryType instance.
bool ArbitraryType::IsValid()
{
    if( base_t::IsValid() &&
        IsColor(m_Fields.col) )
    {
        return true;
    }
    return false;
}

In the last post, the only criteria we used for finding ArbitraryType instances was that we had found a INT_PTR containing the address of its MethodTable. That's obviously going to result in false positives, because the CLR's execution engine will certainly have this pointer in several places in its own internal data structures. We can do a little better now by making sure that the Color field is within the range of expected values. While we're changing our HandleMatch function to implement this, we'll add an STL map to the mix to keep track of the colors we find.

class AtStatCmd : public SearchCommand
{
protected:
    typedef map<Color, int>  CountMap_t;
    CountMap_t m_counts;

public:
    virtual void ShowResults(int totalHits);
    virtual bool HandleMatch(ULONG64 offset);
    AtStatCmd();
};

bool AtStatCmd::HandleMatch(ULONG64 offset)
{
    ArbitraryType at(offset);
    if( at.IsValid() )
    {
        Color c = at.GetColor();
        g_Ext->Out("%08I64x : %s\n",
           offset, ColorName(c));
        m_counts[c]++;
        return true;
    }
    return false;
}

The output of the extension in WinDbg now looks like this:

    0:000> !atstat 009131b0
    Searching for ArbitraryTypes...
    --------------------------------------------
    Searching 00000000 to 7fffffff.
    009100cc : Red
    009130e0 : Red
    01271ce4 : Red
    01271d00 : Blue
    01271d1c : Red
    01271d38 : Blue
    01271d54 : Red
    --------------------------------------------
    Found 7 total instances.
    Totals:
      Red: 5
      Blue: 2

Incidentally, this is debugging the same sample code that, in the previous post, was declared to have 20 instances in memory. As you can see, adding some basic validation reduced the number of bogus hits considerably. A more complex object–one you might actually use, I suppose–could have an even smaller incidence of errors.

There's one obvious problem with this that I can think of, and that is the fact these objects are not necessarily alive (rooted) on the GC heap. They could very well be collected and sitting in freed memory. In my case, this is not a concern since I am interested mostly in debugging leaked memory. This may be an issue for other users, however.

Since the extension we set out to build is basically complete, I'll post the code now even though I have one more feature in mind for the next post. You can download the code here.

My Tentative Approval of Visual Studio 2005

Despite some initial bad press, my impression so far is that Visual Studio 2005 is a pretty nice product. I would qualify that by saying that I haven't yet used it to work on a massive web project, and as we all know web projects were definitely Visual Studio 2003 at its worst. (After two years, I will NOT use Visual Studio 2003 for web projects. I refuse. They were broken. I'm 100% text editor and NAnt from the command line now.)

I am loathe to be seen as a cheerleader, and rest assured I could point to many things about Visual Studio in general and VS2005 specifically that I can't stand. But somebody out there deserves some credit for the fact that startup performance seems to have been drastically improved. In my informal test ("One Mississippi .. two Mississippi"), VS 2005 outperforms 2003's startup by an order of magnitude. Two seconds compared to thirty seconds on the same machine. That's certainly nothing to sneeze at.

You click on the icon, it opens. All software should work this way. I'm looking directly at you, OpenOffice, Trillian, and every single product developed by Adobe. While I'm on the subject, never allowing your program to close is not an acceptable solution to this problem.

I am also a fan of this:

The "close all but this" button replaces these steps:

  1. Ctrl+Shift+S
  2. Ctrl+F4, hold for five seconds
  3. Find the original file and reopen it

The Debugger Extension, Part 4 - Searching Memory

The Debugger Extension

Now that we know how to solve our problem conceptually, we can put pen to paper. Metaphorically speaking, I suppose. As I said in the last post, our strategy will be to search memory for INT_PTRs matching the MethodTable for our ArbitraryType. When we find matches, we'll perform some further validation to reduce the likelihood of false positives.

It's not unreasonable to assume that if we're successful in writing an extension to look at this class, we might want to do something like it again in the future. So let's define an interface for commands that search through memory.

// ------------------------------------------------------
// SearchCommand.h
//        Defines the interface for extension commands
//        that search through memory.
//
#pragma once

class SearchCommand
{
public:
    // Called whenever the search pattern is encountered
    // at the provided offset. The method should return
    // true if the offset is a hit.
    virtual bool HandleMatch(ULONG64 offset)=0;

    // Called when the search is finished. The parameter
    // will contain the total number of matches found.
    virtual void ShowResults(int totalHits)=0;
};

This should give us some flexibility later on if we need it. We can also abstract the process of searching through memory. The DbgEng API that is available to us is the IDebugDataSpaces interface. This defines a SearchVirtual function, which we'll use to scan for the ArbitraryType's MethodTable. This is its definition.

HRESULT
  IDebugDataSpaces::SearchVirtual(
    IN ULONG64  Offset
    IN ULONG64  Length
    IN PVOID  Pattern
    IN ULONG  PatternSize
    IN ULONG  PatternGranularity
    OUT PULONG64  MatchOffset
    );

To make our algorithm generic, we'll add a templated function to our extension class.

// ------------------------------------------------------
// dmext.h
//
#pragma once
#include "engextcpp.hpp"
#include "searchcommand.h"

class EXT_CLASS : public ExtExtension
{
protected:

   // Does a range search for the pattern, keeps track of the hits, and
   // calls methods matching the SearchCommand interface on an instance
   // of the search_command parameter.
   //
   template<class search_command>
   inline void Search(ULONG64 pattern, ULONG64 start, ULONG64 end)
   {
      if( start > end )
      {
         Err("The start cannot be after the end.\n");
         return;
      }

      search_command sc;
      Out("Searching %08I64x to %08I64x.\n", start, end);

      HRESULT hr = 0;
      int hits = 0;
      ULONG64 offs = start;
      do
      {
         hr = m_Data->SearchVirtual(offs,
            end - offs,
            &pattern,
            this->m_PtrSize,
            1,
            &offs);
         if( hr == S_OK )
         {
            if( sc.HandleMatch(offs) )
            {
               ++hits;
            }

            // Search again, starting at the the next
            // pointer-sized location.
            offs += m_PtrSize;
         }
       }
       while( hr == S_OK );
       sc.ShowResults(hits);
    }

    // Shortcut for an x86 without the /3GB switch.
    template<class search_command>
    inline void Search(ULONG64 pattern)
    {
       this->Search<search_command>(pattern, 0, 0x7fffffff);
    }

 public:
    EXT_CLASS();
    EXT_COMMAND_METHOD(atstat);
};

I also added a shortcut function that searches all of the virtual memory that is available to user mode. This function assumes that we're debugging on an Intel x86 machine, and that the process is not LARGEADDRESSAWARE–that is to say, it can't make use of more that 2 gigabytes of virtual memory.

(A brief aside: although I'm using ULONG64 addresses and other conventions, I'm making no sincere attempt to ensure that this extension will work properly with a 64-bit debuggee. That much should be obvious from my last shortcut. Where I can, I will try to make life easy for someone writing a port.)

We now have enough framework to implement the skeleton of our extension command. For now, we'll just spit out addresses when we think we have a match.

// ------------------------------------------------------
// atstat.cpp
//
#include "stdafx.h"
#include "dmext.h"

class AtStatCmd : public SearchCommand
{
public:
    virtual void ShowResults(int totalHits);
    virtual bool HandleMatch(ULONG64 offset);
    AtStatCmd();
};

AtStatCmd::AtStatCmd()
{
    g_Ext->Out("Searching for ArbitraryTypes...\n");
    g_Ext->Out("--------------------------------------------\n");
}

bool AtStatCmd::HandleMatch(ULONG64 offset)
{
    g_Ext->Out("%08I64x\n", offset);
    return true;
}

void AtStatCmd::ShowResults(int totalHits)
{
    g_Ext->Out("--------------------------------------------\n");
    g_Ext->Out("Found %d total instances.\n\n", totalHits);
}

EXT_COMMAND(atstat,
   "Displays statistics about ArbitraryType instances in memory.",
   "{;e;The MethodTable for SampleApp.ArbitraryType.}")
{
    ULONG64 mt = this->GetUnnamedArgU64(0);
    this->Search<AtStatCmd>(mt);
}

The !atstat command is defined using the EngExtCpp framework's macro; this will automatically parse any parameters and provide debugger help. Look in the engextcpp.hpp header for the definition of this macro–I'm not even going to try to explain it here. As you can see, I've simplified matters by assuming that we can just retrieve the MethodTable for our type by some other means and provide it to the extension.

Here's some output of what we have finished so far:

0:000> .load C:\src\samples\dmext\dmext\objfre_wnet_x86\i386\dmext ;
0:000> .load C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\SOS
0:000> !name2ee sampleapp!SampleApp.ArbitraryType
Module: 00912c14 (SampleApp.exe)
Token: 0x02000003
MethodTable: 009131b0
EEClass: 00911410
Name: SampleApp.ArbitraryType

0:000> !atstat 00912c14
Searching for ArbitraryTypes...
--------------------------------------------
Searching 00000000 to 7fffffff.
0012f560
0012f72c
00167628
0016832c
001685f4
0016860c
00168624
0016abec
0016ae28
009101c0
009101e8
009111f8
00911268
009112d0
00911414
00911478
00913058
00913118
009131c4
00c316b8
--------------------------------------------
Found 20 total instances.

In the next post, we'll work on trimming down false positives and accomplishing what we set out to do: showing statistics about the "colors" of the ArbitraryTypes.

The Debugger Extension, Part 3 - A Crash Course in .NET Object Layout

The Debugger Extension

To write this extension, we need at least a cursory understanding of the way JIT-compiled objects are represented in memory. The basic structure on a 32-bit machine is:

  Offset
         +---------------------+
  +0x0   |  MethodTable*       |
         +---------------------+
  +0x4   |  Field 1            |
         +---------------------+
  +0x8   |  Field 2            |
         +---------------------+
         |  ...                |
         +---------------------+
  +0x4*N |  Field N            |
         +---------------------+

If you are wondering what the method table is, well, it is what it sounds like. It's a list of pointers to functions that the object defines. And some other stuff. If we wanted to dive deeper into the type metadata that supports Reflection and other magical CLR api's, the MethodTable is where we would start. But that is beyond the scope of this series.

The object's fields follow the MethodTable. Types derived from System.ValueType (structures) that are held as fields are inlined into the object instance. So if we have a class that has a DateTime field,

  Offset
         +---------------------+
  +0x0   |  MethodTable*       |
         +---------------------+
  +0x4   |  _dt.dateData       |
         |                     |
         +---------------------+
  +0xc   |  Field 2            |
         +---------------------+
         |  ...                |
         +---------------------+
+0x4*N+4 |  Field N            |
         +---------------------+

The datetime field would occupy two slots since it's a 64-bit value. Reference types (objects) that are held as fields are kept as pointer-sized handles.

The fields may not be in the same order as they are written in the source, but they should be stable from one process to the next. I'm not able to guarantee that since I don't work for Microsoft and I don't have access to the source for the CLR's JIT, but I've observed this consistency quite a bit. To view the field layout of any managed type, you can use the !do (DumpObject) command in the SOS extension, or !DumpClass in the same if you do not have an instance handy. Below is the output for an instance of the type we are using in this example, ArbitraryType. This instance has a _color field of zero (Colors.Red) and a _id field of 22.

0:000> !do 012723e4
Name: SampleApp.ArbitraryType
MethodTable: 009131b0
EEClass: 00911410
Size: 16(0x10) bytes
 (C:\src\samples\dmext\SampleApp\bin\Release\SampleApp.exe)
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
00913104  4000006        4         System.Int32  0 instance        0 _color
790fed1c  4000007        8         System.Int32  0 instance       22 _id

We can use the dd command to display the raw memory for the same instance. I've added comments here for the object's data.

0:000> dd /c1 012723e4 l3
012723e4  009131b0        ; MethodTable*
012723e8  00000000        ; _color = (int)Colors.Red = 0
012723ec  00000016        ; _id = 0x16 = 22

The MethodTable pointer will be the same for each instance of the type, but its value will be different every time you run the program. The constancy of this field enables a nice hack solution to our problem.

Rather than root through the CLR's internal structures to find ArbitraryType instances, we will simply search memory for DWORDs that look like they're pointers to the MethodTable for our type. This may result in some bogus hits, but they'll just be noise.

In the next post in this series, we will actually start coding the extension.

If you are interested in further reading on CLR internals, I recommend this MSDN article and the SSCLI codebase.

Nonblocking Pool Class

This is not an original idea but I thought I would post/explain it anyway. This is a generalized version of a pattern I have been using for a while. I'm not sure where I first picked it up but I've seen it used in several places.

The purpose of this class is to pool instances of a particular type in a server application. The assumptions I am making about the problem are:

  • It is both possible and worthwhile to reuse instances of a certain type. Types that may fit this criteria are large arrays of primitive types, types that hold unmanaged or scarce resources such as connections, et al. Not all types fit this criteria, obviously.
  • It is more undesirable to have a thread enter a waiting state (fail to acquire a lock, in other words) than it is to create a new instance of the type being reused. That would be the case if the instances are somewhat cheap but the average request or call time to your server is relatively long.

The nice thing about this pool class is that it handles the second case gracefully. It will reuse objects as much as possible, but it won't block a thread in the case that the attempt fails. If it didn't, you might end up introducing massive contention in your attempt to increase throughput with a different, locking pool.

The class provides very lightweight synchronization using atomic operations - there's no use of critical sections (the lock keyword).

  /// <summary>
  /// Provides and reuses objects of type <typeparamref name="T"/>.
  /// </summary>
  /// <typeparam name="T">
  /// The type that is pooled. Must provide a default constructor.
  /// </typeparam>
  public class NonBlockingPool<T>
     where T : new()
  {
     // Contains the pooled items.
     private Stack<T> _stack;

     // The maximum size of _stack.
     private int _max;

     // This reference is used to ensure that only one thread
     // calls methods on _stack at a time.
     private object _lock = new object();

     /// <summary>
     /// Gets or sets the maximum size of the pool.
     /// </summary>
     public int MaximumSize
     {
        get { return _max; }
        set { _max = value; }
     }

     /// <summary>
     /// Gets a pooled instance of type <typeparamref name="T"/>,
     /// or yields a new instance.
     /// </summary>
     public T Get()
     {
        // If two threads enter this method at the same time,
        // only one will acquire _lock (the other will be given
        // null). The caller that fails to acquire _lock will
        // be returned a new instance of T.
        T ret = default(T);
        object obj = Interlocked.Exchange(ref _lock, null);
        try
        {
           if (obj != null && _stack.Count > 0)
           {
              ret = _stack.Pop();
           }
           else
           {
              ret = new T();
           }
        }
        finally
        {
           if (obj != null)
           {
              _lock = obj;
           }
        }
        return ret;
     }

     /// <summary>
     /// Reuses an instance of type <paramref name="T"/> in a
     /// subsequent request or call whenever possible.
     /// </summary>
     public void Reuse(T t)
     {
        // If two threads enter this method at the same time,
        // only one will acquire _lock (the other will be given
        // a null reference). The instance of T provided by
        // the losing thread will just be collected and not
        // reused.
        object obj = Interlocked.Exchange(ref _lock, null);
        try
        {
           if (obj != null && _stack.Count < _max)
           {
              _stack.Push(t);
           }
        }
        finally
        {
           if (obj != null)
           {
              _lock = obj;
           }
        }
     }

     /// <summary>
     /// Constructor.
     /// </summary>
     /// <param name="max">
     /// The maximum number of instances of
     /// <typeparamref name="T"/> to hold in the pool.
     /// </param>
     public NonBlockingPool(int max)
     {
        if (max < 0)
        {
           throw new ArgumentOutOfRangeException("max");
        }
        _stack = new Stack<T>(max);
        _max = max;
     }
  }

Here's a (contrived) minimal example of a consumer of such a pool. This server class makes a context object available to each thread for the duration of each request. This object is stored in a slot unique to each thread (specified with the ThreadStaticAttribute) while a ProcessRequest function is called. The instance is returned to the pool in a finally block after that call is finished.

  public class SampleServer
  {
     [ThreadStatic]
     private static ServerContext _context;

     private NonBlockingPool<ServerContext> _pool;

     public static ServerContext Context
     {
        get { return _context; }
     }

     internal void ProcessRequest(IServerApp app)
     {
        try
        {
           _context = _pool.Get();
           app.ProcessRequest();
        }
        finally
        {
           if (_context != null)
           {
              _context.Reset();
              _pool.Reuse(_context);

              // We want the context to be collected if it isn't
              // actually reused by the pool.
              _context = null;
           }
        }
     }
  }

A more concrete example might be an IHttpModule or a remoting server channel sink. As I said once already, it's important to consider 1) the type of resource you are pooling and 2) the amount of load your application is expecting before committing yourself to a pattern such as this one.

A Positively Negative Meditation on Sloppy Code

A few years ago, my reaction to encountering code like this was very predictable. You could set your watch to it:

public XmlDocument FooBar()
{
    XmlDocument doc = new XmlDocument();
    doc.LoadXml("<foo/>");
    XmlElement bar1 = doc.CreateElement("bar");
    doc.AppendChild(bar1);
    bar1.SetAttribute("id", "1");
    bar1.SetAttribute("value", "bar1");
    XmlElement bar2 = doc.CreateElement("bar");
    doc.AppendChild(bar2);
    bar2.SetAttribute("id", "2");
    bar2.SetAttribute("value", "bar2");
    // ...
    XmlElement bar30 = doc.CreateElement("bar");
    doc.AppendChild(bar30);
    bar30.SetAttribute("id", "30");
    bar30.SetAttribute("value", "bar30");
    return doc;
}

The problem with that should be obvious to anyone, and—if The Daily WTF is any indication—I think this is a common mistake. Times have changed, however.

These days, if I had to name my single biggest issue in dealing with code written by others I would have to give an example like this:

public Hashtable Batman(Hashtable ht)
{
    // ...
}

The problem here is not as obvious to your average first-year programmer, but I would summarize the difference like this:

  • It’s not well-defined what is going in.
  • It’s not well-defined what happening inside the function.
  • It’s not well-defined what is coming out (and this may vary depending on #1).

While these kinds of problems are often found together, it seems to be possible to find code that avoids one pitfall but not the other.

The main factor in my attitude shift, you could say, would be what I am personally working on. When the first example bothered me the most, I was only responsible for enhancing functionality created by others and/or fixing bugs in code of the same quality. It was easy to cite examples of bugs that would not have occurred—or at least would have been easier to fix—if the cut & paste keys had not been so liberally employed.

I spend most of my time now gluing together components in the large, working on architectural things that many developers will never know or care about, and debugging oddball problems. With that background it’s easy for me to say that a cut-and-paster with a thoughtful interface definition has done a good (or even very good) job.

Lack of functional abstraction doesn’t seem as reprehensible to me as it once did. You can always encapsulate it in some functional abstraction. Many great books have been written in prison, and many great software packages have been put together from pieces of spaghetti code.

The second example (the chaos point with no type safety) is another matter. This portends systemic instability. When I find this with the intention of encapsulating-and-never-speaking-of-it-again, it’s very difficult or impossible to locate all of the dependencies. I will usually cut my losses and start from scratch after encountering a few “function Batmans.”

I admit that this insouciance towards Ctrl+C/Ctrl+V is entirely the byproduct of self-interest. It's not that I think it's a good idea, it's just that I can't muster the energy to get upset about it. If a passionate new programmer were to vocally find fault with it I would wholeheartedly agree.

Using WinDbg to Log Exceptions, Part II

In my last post, I asked you to explain how to derive this command:

0:000> bp mscorwks!JIT_Throw "du poi(@ecx+10)+c; !clrstack; g"

The purpose of which is to print out the exception text when a CLR exception occurs.

Finding the Function

The first question here might be, how did I know to break on this function? This is the easiest part to get. If we break on kernel32!RaiseException and examine the unmanaged stack, we can see that this is the first function called from managed code when an exception is thrown.

0:000> k
ChildEBP RetAddr
0012f5a8 79238b7d KERNEL32!RaiseException
0012f600 792f0d05 mscorwks!RaiseTheException+0xa0
0012f66c 02e000a0 mscorwks!JIT_Throw+0x4d
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012f69c 791d94bc 0x2e000a0
0012f6a4 791ed194 mscorwks!CallDescrWorker+0x30
…

I have one important note about the JIT_Throw function. I’ve shown it here in the mscorwks module. This is the workstation CLR. If you are working on a server application, you should change all references to that to mscosvr, which is the server version of the CLR.

The more interesting part, of course, is how I figured out how to use du poi(@ecx+10)+c to print out the exception text.

Finding the Exception

If we actually break on JIT_Throw, we can locate the address of the current managed exception using the DumpStackObjects command in the SOS extension.

0:000> !dso
Thread 0
ESP/REG    Object     Name
ecx        0x00aaabfc System.Exception
0x0012f680 0x00aaabfc System.Exception
0x0012f688 0x00aaab6c System.Object[]
…

Notice that !dso gives us an additional piece of information: at the start of this call to the JIT_Throw function, the address of the current exception is in the ECX register. Can we rely on that to be true in every case? It turns out that we can, and I think it is instructive to explain why this is so.

Some of you will already know why ECX is special here, and if we take a look at the prologue of this function in assembly it might confirm your suspicions.

mscorwks!JIT_Throw:
792f0cb8 55               push    ebp
792f0cb9 8bec             mov     ebp,esp
792f0cbb 83ec58           sub     esp,0x58
792f0cbe 56               push    esi
792f0cbf 8bf1             mov     esi,ecx

The last two instructions are a common sight when working with functions declared with the __fastcall calling convention. This convention places the first two arguments to the function in the ECX and EDX registers.

For the sake of completeness I should say that you will also see the same kind of prologue if a C++ member function is being called (__thiscall). However, we know that this is not the case here.

Taking a quick look at the assembly here would be enough proof, but we can confirm that __fastcall is actually being used by reading the comments in fcall.h in the SSCLI, and then looking up the definition of JIT_Throw in jitinterface.cpp.

To summarize, as long as we are running on an x86 machine, we can always grab a pointer to the current exception at this breakpoint from the ECX register.

The Home Stretch (Finding the Exception Text)

Now that we can locate the managed Exception, we can take a stab at finding the text to go along with it. Take a look at the output when we dump the Exception object (using the DumpObject command in SOS):

0:000> !do @ecx
Name: System.Exception
MethodTable 0x79b947ac
EEClass 0x79b94850
Size 64(0x40) bytes
GC Generation: 0
mdToken: 0x02000012  (c:\windows\microsoft.net\framework\v1.1.4322\mscorlib.dll)
FieldDesc*: 0x79b948b4
    MT      Field     Offset          Type   Attr     Value       Name
0x79b947ac 0x400001d     0x4         CLASS   instance 0x00000000  _className
0x79b947ac 0x400001e     0x8         CLASS   instance 0x00000000  _exceptionMethod
0x79b947ac 0x400001f     0xc         CLASS   instance 0x00000000  _exceptionMethodString
0x79b947ac 0x4000020    0x10         CLASS   instance 0x00aaab7c  _message
0x79b947ac 0x4000021    0x14         CLASS   instance 0x00000000  _innerException
0x79b947ac 0x4000022    0x18         CLASS   instance 0x00000000  _helpURL
0x79b947ac 0x4000023    0x1c         CLASS   instance 0x00000000  _stackTrace
0x79b947ac 0x4000024    0x20         CLASS   instance 0x00000000  _stackTraceString
0x79b947ac 0x4000025    0x24         CLASS   instance 0x00000000  _remoteStackTraceString
0x79b947ac 0x4000026    0x2c  System.Int32   instance 0           _remoteStackIndex
0x79b947ac 0x4000027    0x30  System.Int32   instance -2146233088 _HResult
0x79b947ac 0x4000028    0x28         CLASS   instance 0x00000000  _source
0x79b947ac 0x4000029    0x34  System.Int32   instance 0           _xptrs
0x79b947ac 0x400002a    0x38  System.Int32   instance -532459699  _xcode
-----------------
Exception 00aaabfc in MT 79b947ac: System.Exception
_message: You stink!

The third column, Offset, is what is important to us right now. This tells us the address of each field relative to the base address of the object. If we want the System.String object instance for the _message field, we can refer to that like this:

0:000> ? poi(@ecx+10)
Evaluate expression: 11185020 = 00aaab7c

(The poi keyword in this expression returns a pointer-sized variable at the specified address. It is the same as “*(pException+0x10)” would be in C or C++).

We can use the same kind of procedure on the String instance to get the actual characters.

0:000> !do poi(@ecx+10)
Name: System.String
…
FieldDesc*: 0x79b92978
     MT      Field     Offset                 Type       Attr  Value  Name
0x79b925c8 0x4000013      0x4         System.Int32   instance     11  m_arrayLength
0x79b925c8 0x4000014      0x8         System.Int32   instance     10  m_stringLength
0x79b925c8 0x4000015      0xc          System.Char   instance   0x59  m_firstChar
…

The first character in the string is at 0xC relative to the base of the object. We know that the CLR uses Unicode to represent strings internally, so we can use the du command (display memory, Unicode) to print it out.

0:000> du poi(@ecx+10)+c
00aaab88  "You stink!"

Conclusion

Well, there you have it. With a little elbow grease, WinDbg is a tremendously powerful tool. I hope you’ve found this particular odyssey entertaining.

Using WinDbg to Log Exceptions

Since I discovered that I am currently—and quite inexplicably—the #1 Google Blog Search result for the term “WinDbg,” I decided that I would attempt to actually produce some WinDbg content.

If you are not familiar with WinDbg, check it out with the rest of the Debugging Tools for Windows here.

To get things started, I thought I would post some examples that I’ve found useful lately.

Introduction

I use this technique quite a bit when I’m doing QA work on an application. I can think of a bunch of other scenarios where it might be useful, but one chore in particular that is well suited for this is finding ASP.NET page compilation exceptions.

There isn’t really a good way to clean up page compilation exceptions in a massive ASP.NET application. Why would you bother? Well, there are a few reasons.

  1. They encourage you to disable break-on-exceptions in a debugger like VS.NET, since you’ll be inundated with a lot of other people’s exceptions when trying to attach to the worker process. If you do that, you might miss swallowed exceptions or exceptions on background threads that you would have otherwise noticed and fixed.
  2. They might indicate a problem in the HTML being sent back to the user.
  3. They cause your application to take longer to start up.
  4. Some of us are just sticklers for the details, ok?

So, one good way to trim them down to a bearable amount is to log all of the exceptions that happen when the app starts.

Getting Started

The first thing you need to do is open up a log:

0:003> .logopen c:\temp\exceptions.txt
Opened log file 'c:\temp\exceptions.txt'

And if this is managed code you’ll want to load the SOS extension:

.load clr10\sos

We’ll use a breakpoint with a custom command to print out the stack when the exception occurs.

0:003> bp kernel32!RaiseException "!clrstack; g"

The !clrstack command will print out the stack, and g (go) resumes execution. If the application is unmanaged, you will want to replace !clrstack with one of the k (display stack) commands. Both managed and unmanaged code will use the same underlying call to the kernel32!RaiseException function.

Once you have this set up, you’ll see a trickle or a flood of stacks, depending on the relative health of your app. They’ll probably be more interesting than this:

(848.d18): CLR exception - code e0434f4d (first chance)
Thread 0
ESP         EIP
0x0012f648  0x7c81eae1 [FRAME: HelperMethodFrame]
0x0012f674  0x02e000a0 [DEFAULT] Void CsConsoleApp.Program.Main(SZArray String)
  at [+0x48] [+0xf] c:\src\scratch\csconsoleapp\class2.cs:26
0x0012f8b0  0x791d94bc [FRAME: GCFrame]
0x0012f9b0  0x791d94bc [FRAME: GCFrame]
0x0012fa94  0x791d94bc [FRAME: GCFrame]

But you get the idea.

Adding More Information

Now, notice that in the case of a managed exception, WinDbg didn’t give us much information, other than the fact that it occurred:

(848.d18): CLR exception - code e0434f4d (first chance)

It would be nice to get the exception text, right? You can do that by changing the breakpoint to this:

0:000> bp mscorwks!JIT_Throw "du poi(@ecx+10)+c; !clrstack; g"

Homework: explain this command and how I came up with it. I will post the answer soon.

Now we’ll get something more useful:

(848.d18): CLR exception - code e0434f4d (first chance)
00aaab88  "You stink!"

Other Mods

One thing you might want to do in the case of rarer exceptions is create a dump of the process. This is especially useful if your issue only happens in production. The simplest way to do that is very similar to what we just did:

0:003> bp kernel32!RaiseException ".dump /ma /o c:\\temp\\myapp.dmp; g"
breakpoint 0 redefined

The /ma switch produces a full dump. I set this breakpoint to overwrite a single dump file.

More homework: modify the breakpoint to create a series of dumps. The answer will be posted in the near future.

A Word for OllyDbg

OllyDbg is a very nice tool for debugging other people’s code. While I definitely still prefer WinDbg in most situations, OllyDbg is great for stepping through assembly.

OllyDbg

I had a good reason to use it last week. I have an old VB6 application that needs to interop with new .NET applications. The VB6 code is using an ancient COM library for encryption; this library is fairly opaque in regards to what it is actually doing.

Without giving away too many details, there’s no way I can move the old code to over to anything else. I wish the original author had just imported the advapi32 Crypt* functions, but it’s too late for that now.

So, needing to decrypt data coming from the VB6 side, I was left with a few choices. I could just use COM Interop and reference the old library in my new code. But I wasn’t really happy with that, mostly because of the complexity that it adds to deployment.

I was familiar enough with the Crypto API to know that the COM library couldn’t be doing anything too complicated. This is where OllyDbg comes in.

I stepped through the library call in assembly, stopping when it made Crypt* calls. I got the parameters from the stack, and wrote them all down.

From there, I wrote a quick C++ console app to test out recreating the calls and decrypting some sample data. As it turned out, the specific algorithms that the COM library was using weren’t exposed in System.Security.Cryptography, so the C# version I ended up with had to use P/Invoke with advapi32.

But anyway, I got rid of an annoying dependency. A very satisfying hack. You can read about an even better one here—Lee Holmes uses OllyDbg to crack a program to run as a non-admin.

Does ANYONE Comprehend ASP.NET Web Projects?

Once every few weeks I find myself wrestling with these foul beasts. And each time, I find the following phrase echoing in the empty space between my ears.

Mit der Dummheit kämpfen Götter selbst vergebens.

I have been making every attempt to avoid dealing with them. For the most part, a series of NAnt scripts have insulated me. But now and then I need to get one working for the sake of helping one of the many lost souls who depend on them.

Last time, I took screenshots.

The first step was to try to add the project to a solution.

Creating an ASP.NET web project - Step 1

It wants me to enter the URL of the project, so far so good…

Creating an ASP.NET web project - Step 2

Now we have the first sign of trouble. The URL bit appears to have punted to a standard file open dialog.

Creating an ASP.NET web project - Step 3

I faithfully yet skeptically select the file, but I have the sinking feeling of having been here before.

Creating an ASP.NET web project - Step 4

Ah yes, I remember now.

Creating an ASP.NET web project - Step 5

So there you have it: web projects are an ouroboros; they are a maddening riddle, answered only by another question.