After discussing the following topics:
- What is a process's memory dump
- First Chance Exception vs Second Chance Exception
- The importance to collect a memory dump at right time
I believe it is right time to share with you how to collect a process memory dump properly. Why properly? Because there is not a single way to collect it: you have to act accordingly to your trouble.
The tool that allows us to collect a memory dumps is called DebugDiag. Please download the x86 version or the x64 version in according with your O.S.'s architecture http://www.microsoft.com/download/en/details.aspx?id=26798
Let’s start to analyse our scenarios:
Taking a dump in case of process's crash
The following rule allows us to collect a memory dump, in case of process's crash. We will not do any assumption on first chance exception, or heap corrupting and so on... We want to take a picture of our process before that it crashes.
Start DebugDiag. Select crash in the first interface and press the button called “next”:
- Select the item called “A specific process”. In case of web app problem, select “A specific IIS web application pool”
- Select process where the issue occurs or write its name with the extension exe. For web app issue, select Application Pool where your web application is working on.
- Configure the last interface as reported below:
- Create and active the rule.
In case that your process is not crashing but you observe that it closes itself in an unexpected way, please change the step 4 with the following one:
Basically, we will add a break point on our process as soon as it tries to close itself.
Hang scenarios: my process stops to respond but I do not know why
There are situations, where your process does not crash but for some unknown reasons it stops to do its work.
In these cases, we can collect a dump in the following way:
- Start DebugDiag and select the button called cancel in the first interface:
- Click on the tab called: “Processes”. DebugDiag shows the list of processes that are running on your machine.
- Right click on the process affected by the issue:
- Select the item: “Create Full Userdump”
In case, that you are troubleshooting an IIS issue, and you are not sure which application pool instance to dump you can have a look at http://blogs.msdn.com/b/carloc/archive/2007/04/13/find-which-w3wp-exe-instance-is-hosting-your-application.aspx to know which process is hosting the blocked application
Troubleshooting a fist chance exception
There are situations, especially working with IIS, where your application does not handle a particular exception. In this situation, it could be expected that hosting process (w3wp for web application) crashes. It is not completely true. I do not want to go in deep about this topic on this post (probably in a new one ) but let’s say that IIS is robust enough to handle the exceptions for us.
In this situation, there is no process's crash so we cannot use the rule mentioned on "Taking a dump in case of process's crash" section. Technically, we are interested on a fist chance exception or better we are interested to get a dump when a first chance exception come out. How to proceed?
Follow the steps mentioned on section "Taking a dump in case process's crash" but change the step 4 with this one:
This rule is valid only for web applications and we should use it in case that our web application is working in a slow way.
For example, typically a specific page MyPage.aspx answers in 5 seconds to final users. Sometimes, without having network issue, the same page is shown back to final users in 30 - 60 seconds. What it is going on! A dump will help us:
Run debugDiag and select the item: Performance
- After that, please select the item: HTTP Response Time. > Add UR
- DebugDiag will show the following interface:
- Set timeout to 30 seconds (or a proper value) and press O
Hope this help,