A dump has so many uses

I’d been meaning to write a blog post about Windows dump files for a while now. I’ve used them at work a number of times. For example, when I worked on the CLR profilers, a dump file was a natural way to debug issues when there were problems with the COM component that we would inject into the profiled process. With the appropriate symbols, which you ought to have saved away to an internal symbol server, this was a good way of getting information on the issue.

I’ve used dump files in other scenarios too. When our cloud application seemed to be taking too much CPU when in production use, it was easy to take a dump of the process – the dump stalls the process only for a short amount of time so it is often possible to take a dump when an application is in production use. Better still, utilities like procdump from Sysinternals allow you to take a dump of a managed process when interesting events happen, so we can take a dump when a first chance exception happens for example and capture the state of the process when the exception is thrown.

I’ve used Windbg to load and study such files in the past, though Visual Studio supports them pretty well these days. Moreover, Microsoft have recently released a managed .NET library, ClrMD, which allows you to programmatically open and process such files, and the source is now open

Anyway, I was reminded of all of this when I came across a recent talk by Sasha Goldshtein, where he summarises the uses of dump files and shows some examples of the types of automated processing you could do using ClrMD. The talk also covers the many issues that dump files help you to debug (though you need to be slightly careful as the dump file may also contain sensitive data from the user’s process).

The Visual Studio experience when you open a dump file is quite impressive. The normal debugging windows are all available, so you can see the threads and the locals of the various methods. One thing that has anyways impressed me is that the locals window manages to display the property values of the various objects.


I’d read in the past that this is possible because the VS code contains an IL interpreter, and wanted to prove this. I took the source code shown about and modified the property getter to throw an exception. Then, attaching WinDbg to the Visual Studio process and breaking on exceptions, I managed to stop at the following stack trace.


So indeed, Visual Studio contains code to allow the programming environment to simulate the execution of a property getter. That is rather cool!

Since I haven’t blogged for a while, I’d also like to point out some interesting articles I’ve read over Xmas. On the C# front there’s a good article on when you should avoid using async/await and another on the difference between rethrow and rethrow ex;

I’ve also been watching a load of Virtual Machine Summer School  and Smalltalk videos, and never fail to be impressed with the work that Smalltalk did to get VM technology into the mainstream. There’s this interesting talk on the history of VMs and advice from someone who has implemented many Java runtimes (and if you like the idea of a managed OS then this talk on COSMOS is also very interesting), plus a load of talks on improving the VMs performance and the many contributions of Smalltalk.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s