Inspecting the Memory dump of a .NET Application

There are times when a .NET application crashes and what logging is in place is not enough. In this case, if you happen to have a memory dump of the application in a .dmp file, then the application's memory and stack trace of the application's threads can be investigated, with the right tools.

The Windows Debugger is the tool for investigating Windows memory dump files. Microsoft provides this tool to query the memory dump files, files with the .dmp extension. On its own, this tool cannot show the stack trace for .NET 2.0 applications, but with the extension PSSCore2, .NET stack traces can be viewed and a great level of detail gleamed from the stack trace. PSSCore2 replaces an older tool SOS. Most of the resources I've found refer to SOS instead of PSSCore2, though the commands for the most part are the same between the two systems.

Once both of these tools have been installed, open the memory dump file with Windows Debugger. After the memory dump file has been loaded, issue the command:

    .load clr10\psscore2

You may have to replace clr10 with the folder that you placed psscore2. If you place the psscore2 dll in the same folder as the Windows Debugger, then the command would simply be:

    .load psscore2

But how do you use the Windows Debugger once its been installed? This article details the basic steps for loading the old extensions, but it still contains some good references (just replace references to 'sos' with 'psscore2'). This blog post from MSDN outlines some of the most useful commands and how to use them. Also, this blog post provides a real world use case for the Windbg tool. Finally, this blog post contains numerous links and a few random tidbits about the tool.

This outlines most of the useful pages I've found on the web for loading the memory dump of a .NET application. The command “!help” will return the name of the various commands available for the psscore2 extension. In general, commands that start with “!” refer to the commands available in the loaded extension, while those starting with “.” are those available natively in the Windows debugger.