For a new project I’ve been working on I was forced into working with the world of C++ and COM for a sizable portion of it. In my past life I’d previously worked on some large-ish projects involving COM (office interop in particular), but never on a fresh codebase from the ground up.
I was recently debugging an intermittent, brief hang (5-15 seconds) in an ASP.NET application that would occur once every few days. The application was fully precompiled (non-updatable) and running .NET 4.0.
I've compiled the latest build of SPT for x86. All functionality should be working fine, but since I don't do much x86 debugging it hasn't been as thoroughly tested as the x64 build. Let me know if you run into any issues.
This is actually a later build than the x86 version and has some enhanced features, like !findtimers to dump all the active timer objects in the process and enhanced output for some commands. I'll get the x64 version update posted soon as well.
Before I begin talking about how I've implemented some of the commands in SPT, I need to talk about some of the supporting methods that make doing things much easier. The IXCLRDataProcess/Dacp*Request API is not very user friendly and very verbose, by creating wrappers around them, we can spend more time building extensions and less time worrying about implementation.
The first thing we need to do is get an instance of an IXCLRDataProcess. This is the core interface we'll be using for everything. See my previous posts for more information on it. Conveniently, WinDBG has a semi-undocumented IoCtrl request to give us an instance of this object. It internally handles creating an ICLRDataTarget implementation, finding and loading the correct mscordacwks dll, and calling CLRDataCreateInstance for you. Using it is simple, the IoCtrl request code is documented, so we simply need to make a request and call Ioctl. (Note: Ioctl is defined in wdbgexts.h)
HRESULT InitIXCLRDataFromWinDBG(IXCLRDataProcess **ppDac)
{
WDBGEXTS_CLR_DATA_INTERFACE ixDataQuery;
ixDataQuery.Iid = &__uuidof(IXCLRDataProcess);
if (!Ioctl(IG_GET_CLR_DATA_INTERFACE, &ixDataQuery, sizeof(ixDataQuery)))
{
return E_FAIL;
}
*ppDac = (IXCLRDataProcess*)ixDataQuery.Iface;
return S_OK;
}
Update: I’ve written a newer/better version of this for .NET 4.5 and open sourced it, see later posts on my blog for more details. This version is legaacy and no longer maintained.
It logically makes sense, if threads could be aborted while they were inside catch or finally blocks, those constructs would be fairly useless. For example:
There are times when I’ve needed to find the managed thread object backing the native object output in !threads. The way I used to get it was to dump all thread objects (!dumpheap -mt <thread MT>) and match the managed thread Id field with the output from !threads. However, there’s a better way.
(Part 1 is here)
A project I’ve been working on recently is a tool to capture the stack trace of all running threads in a process. The tool is used in response to a monitoring event to gather information about the process at the time of the event firing. Gathering this information needs to be fast (sub-second, preferably < 100ms), so using CDB, loading SOS (or sosex) and running ~*e!clrstack or ~*e!mk or similar wasn’t an option, since it takes far too long. Also, as a secondary goal I wanted to be able to allow this to operate on a dump file as well as a live process, and also be as non-invasive as possible. That ruled out using the CLR profiling APIs or MDbg (as a side note, it seems like MDbg tends to randomly kill OS handles in the process it’s attached to).
