- Part 1 of 4: Accessing memory mapped files from C#
- Part 2 of 4: Using MiniDumpReadDumpStream
- Part 3 of 4: Reading stream data (ModuleListStream) returned from MiniDumpReadDumpStream
- Part 4 of 4: Putting it all together
All code is available on my CodePlex project.
This is the last in a 4 part series on how to use MiniDumpReadDumpStream to read data streams contained within minidump files. The first article discussed how to access memory mapped files from c#, the second how to call MiniDumpReadDumpStream and the third how to interpret the data returned (using ModuleListStream as an example). This post wraps everything up and introduces the Minidump Explorer Windows Form application. The posts that follow this one will discuss each data stream as I work towards creating an application (Minidump Explorer is just a stepping stone) that will let you analyze and visualize minidumps of processes that were running the CLR.
Analyzing the information contained in minidumps is still going to take some time; that requires using an entirely different API and a lot more work. For now we’ll just look at the raw data contained in a minidump file and create an application that can view that data. We’ll use that as a stepping stone to something bigger. Given that, let me introduce the Minidump Explorer Windows Form application! Remember those Firefox crash dumps I found lying around in my first post? Well here’s our first look at the contents of those files:
You can see that I’m using the module stream information I spoke about in the previous article to display a list of modules that were loaded at the time of the crash. Some of this module information (e.g. the base address, timestamp, size & module name) is going to be vital to us in the future when we start trying to interpret the minidump i.e. trying to look at threads and calls stacks, or heaps and objects. That’s still a ways off, but I want to take a moment to explain the difference between looking at the raw minidump stream data and looking at what’s happening inside the application that crashed.
What is a minidump and how do we interpret them?
You’ll notice that I always mention analyzing minidumps of processes “running the CLR”. I’ve been very careful to deliberately word it that way. Minidumps are crash dumps of a process from an operating system point of view. By that I mean that from the operating system point of view, it was running a process; that process stopped working and a crash dump was created. The operating system doesn’t know what that process was, or what it was doing. It’s knows it had resources allocated to it, there were one or more threads and it had a list of instructions that it was executing. But it doesn’t know whether it was running a Python interpreter, a Java VM, the CLR or just a regular native application. From the operating system point of view everything is a native process. Think about it this way: the operating system is running the CLR, and the CLR is running your code.
When we look at a minidump we’re seeing what the operating system see’s i.e. the CLR. It has no knowledge of the data structures or workings of the CLR; it just does what it’s told to do.
For example: the operating system doesn’t know about CLR threads. It knows about threads that the CLR asks it to create, but it doesn’t know about threads created internally by the CLR. Did you know that CLR threads don’t necessarily match one-to-one with operating system threads? Just because you create a System.Threading.Thread object in your .Net code doesn’t mean the CLR will create a matching thread in the operating system. This is because the CLR sits on top of the operating system and manages itself and its own resources; just like the Java VM does.
What does this all mean? Well we don’t want to see what the operating was doing when the application crashed. If we looked from that point of view we’d see that the operating system was running the CLR. We want to know what was happening in our .Net code when it crashed, or rather what the CLR was doing. This means we need something that knows how the CLR works and can translate between what the operating system saw and what the CLR was doing, like this:
Hopefully that helps to illustrate where we’re heading towards. It’s a bit more technical than that, but it should help you understand.
Viewing module information
Back to Minidump Explorer! As I was saying: I’ve used the module stream to display the list of modules. You can also double click each module to get more detailed information:
By the way: I’m not picking on Firefox! It just happens to be one of the few applications that will create a minidump when something does go wrong. I’m sure the problem was probably Flash related 😉
I’ve also included the ability to capture crash dumps. I discussed that here. It’s a simple wizard that lets you select a process, choose what information you want captured and create the crash dump. The process will be unaffected once the dump has been created.
I’ve created a project on codeplex and uploaded all of the code I’ve done so far, you’ll find it at https://minidumps.codeplex.com. Have a look around, download the application and give some comments/suggestions, feedback is very welcome.
Now that the basics are done we should be able to add the other data streams fairly quickly. Next up: thread, memory/memory 64 and handle streams.