How to collect a memory dump properly

After discussing the following topics:

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

Let’s start to analyse our scenarios:

Taking a dump in caseof 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.

  1. Start DebugDiag. Select crash in the first interface and press the button called “next”:


  2. Select the item called “A specific process”. In case of web app problem, select  “A specific IIS web application pool”

  3. 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.

  4. Configure the last interface as reported below:

  5. 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:

  1. Start DebugDiag and select the button called cancel in the first interface:

  2. Click on the tab called: “Processes”. DebugDiag shows the list of processes that are running on your machine.

  3. Right click on the process affected by the issue:


  4. 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 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 Smile ) 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:


Performance issues

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:

  1. Run debugDiag and select the item: Performance


  2. After that, please select the item: HTTP Response Time. > Add UR

  3. DebugDiag will show the following interface:

    • Set timeout to 30 seconds (or a proper value) and press O
  4. Press next and “Add dump target”

  5. Please select application pool affected by the issue.

  6. Configure the last interface as showed below:


Hope this help,