Skip Ribbon Commands
Skip to main content
Navigate Up
Sign In

Quick Launch

Average Rating:

(1 Rating)
facebook Twitter
Print Bookmark Alert me when this article is updated


HOW TO: Capture and analyze process dumps on Windows

The following are three general scenarios that will typically require you to capture/collect a Windows process dump of a process:

  • Process Hang
  • Poor performance
  • Process Crash


A process dump can be termed differently, ("Core dump", "Memory dump" and "User dump" - full userdump/mini userdump) however, they all mean the same,

There are multiple tools and means to collect a windows dump, however, this article primarily focuses on how to collect these dumps using DebugDiag. DebugDiag is a tool provided by Microsoft that can be used to create a rule on how and when to collect process related diagnostics (dumps/stacks) and can also be used to analyze these diagnostics to some extent.


In a hang scenario, you will need to know when exactly is the process stops processing and if the process is consistently stuck there and not just slowly moving.

Also, in a hang scenario, the process would be running actively, which means collecting a dump on the process is easier.

  1. Once you open DebugDiag Collection tool, it would show a pop up to “Select Rule Type”, hit cancel and go to DebugDiag home page.
  2. Select Processes tab (by default it lands on Rules tab).
  3. Right-click on the process you suspect to be hung and click on “Create Full UserDump”.

  4. This will show a pop up of where the dump was created. Make a note of it.

Another method to collect Full user dump is using Process Explorer. Use this technique ONLY IF, DebugDiag does not work OR for cannot be installed due to security reasons.

  1. Open process explorer.
  2. Find the process of which you would like to create the dump.
  3. Right Click on the process and select “Create Full Dump”.

  4. Make a note of where you save it. 

It is recommended that you collect multiple dumps (3 dumps at an interval of 3 minutes), to check if the process is hung OR is moving slowly.


Though there are different varieties of performance issues, a typical (but not limited to) issue we see is the slow performance of a service/job when benchmarked against a previous version/run of the product OR sudden/intermittent reduction in throughput OR jobs going to waiting state. In any case, you need to check the state of the process for the duration it is alive. This case is a little different from hang because in this case the process though slow still does its job. Hence, we would like to see the process’s state over a period. It is recommended to collect Full User dumps similar to HANG scenario except that, you may have to collect MULTIPLE dumps at regular intervals. For example, if the process is alive for 30 minutes, collect dumps every 10 minutes. If it is a server process like pmserver, pmrepagent – choose a sampling time, let us say 3 iterations with a 30-minute interval. There is a no single holy number for the number of dumps OR interval. The point is, choose wisely based on the lifetime of the process and definitely collect a minimum of 3 dumps. A single dump is NOT ENOUGH to troubleshoot a performance issue. 


A process crash on Windows, unlike Unix flavors does not inherently generate a core file. This leaves us with no option but to wait for another occurrence to collect crash dump. To understand why and how we configure DebugDiag to collect dumps, we need to first understand a little about the rules we could configure to generate dumps. To start with, there are 2 types of exceptions:

  1. First chance Exception
  2. Second chance Exception

We DO NOT NEED dumps created on First Chance Exception, not because they are useless, but, because they do not give the latest state before the crash, instead these dumps could be caused by a red herring. For enthusiasts, here are a couple of blogs from Microsoft that might help understand these exceptions better:

In most cases, we would need a dump on second Chance Exception.

To capture a dump on crashing process do the following:

  1. ​Select Crash and click Next:
  2. Select A specific process and click Next.
  3. Now select the process you would like to attach DebugDiag to. Here, we have 2 options:
    • Give the process name and DebugDiag would attach to all the processes forked with this process name.debugDiag6.png
    • Select a particular process from the running processes list and check “This process instance only”. In this case, DebugDiag would only attach to the particular process instance and would not attach to any other process with the same name. It would not re-attach to the process if the process crashes and restarts.debugDiag7.png
      NOTE: How do you choose one option over the other?
      Based on the lifespan of the process.
      If you have enough time to attach DebugDiag to a process after it starts and before it crashes – go with option (ii) else go with option (i).
      If you would like to get a crash dump of repository service process and you know that the crash happens on an operation. This gives you ample time to attach DebugDiag to a specific process instance and then perform the operation that replicates the crash. In this case, you go with option (ii).
      If you have a case where pmdtm crashes during initialization and you do not have time to choose the specific process, go with option(i) where you would give the process name and let it attach to all the pmdtm processes forked thereafter.
      You do not have to worry about too many pmdtms running and all of them creating dumps because not all the processes would hit second chance exceptions. Hence, you would only see the dumps created for the problematic pmdtm. In case you see more than one dump, check for the PID of pmdtm (or relevant process) in questions and accordingly collect the dump that is relevant.
  4. ​From this point, you again have multiple choices/options:
    • C​apture second chance exception.
    • Capture dump on child process exit.
    • Capture dump on process terminate.

A dump on second chance exception is the recommended approach to try first. If it fails to create a dump, this means the process dies even before it raises an exception. In which case, you would want to capture its state when it exits OR terminates. If you are unsure of which one to opt for, check with a product specialist or with a senior who could help.

Capturing second chance exception:

Unlike First chance exception, you do not have to set a rule to capture second chance exception dump. This is because debugdiag once attached to a process, automatically creates crash dump on Second Chance exception. This means, you only have to create an empty rule on a particular process to capture this dump.


Make sure you leave the Advanced configuration page as follows:

  • Action type for unconfigured first chance exceptions: NONE
  • Action limit for unconfigured first chance exceptions: 0
  • Maximum number of userdumps created by this rule: 1


Click Next, make a note of the Rule Output Location and activate the rule.

This will automatically collect a Full user dump on the Second Chance Exception.

Capture dump on child process exit:

On the Advanced Configuration screen, do the following:
  1. Click Events
  2. Then Add Event
  3. Select Child Process Exit

Action Type -> Full User Dump

Action Limit -> 1


Click OK, Save & Close and then next, make a note of the Rule Output Location and Activate the rule.

This will automatically collect a Full user dump when the process (that DebugDiag is attached to) exits.

Capture dump on process terminate:

On the Advanced Configuration screen, do the following:
  1. Click Breakpoints
  2. Then Add Breakpoint 
  3. Select Ntdll!ZwTerminateProcess

Action Type -> Full User Dump

Action Limit -> 1


Click OK, save & Close and then next, make a note of the Rule Output Location and Activate the rule.

This will automatically collect a Full user dump when the process (that DebugDiag is attached to) terminates.


If you have reached this point, you have learned how to configure DebugDiag to attach to a process and collect a User Dump for the scenario you are interested in.

Further on, we would be generating a report out of the dump we created.

DebugDiag Analysis report:

For this, you need DebugDiag analysis tool.

  1. Click Add Data File.
  2. Navigate to the location where the dump file is present. Select the relevant dump file and click Open.
  3. You would see the dump file/files loaded listed at the lower pane of DebugDiag analysis tool.
  4. Check the “CrashHangAnalysis” box present in the upper pane.
  5. Click Start Analysis.
  6. This should give you an HTML output containing Analysis summary and Details along with the stack trace.

At times the stack generated at customer’s end might not be good enough for understanding the process state because Windows stack could be misleading without symbol files. Hence, you may be asked to share the dump file with a product specialist. In this case, collect all the relevant dump files and share it with a product specialist for a thorough analysis.

This sums up generating Windows process dump and also collecting stack out of the dump. 

Tool can be downloaded from microsoft webiste.

e.g. ​​

More Information



Applies To
Product: PowerCenter; Data Quality
Problem Type: Performance; Stability; Crash/Hang
User Type: Administrator
Project Phase: Onboard; Optimize; Implement
Product Version:
Operating System:
Other Software:

Last Modified Date: 9/16/2020 9:33 AM ID: 522617
People who viewed this also viewed


Did this KB document help you?

What can we do to improve this information (2000 or fewer characters)