The following are three general scenarios that will typically require you to capture/collect a Windows process dump of a process:
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.
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.
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:
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:
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.
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.
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.
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.
For this, you need DebugDiag analysis tool.
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.
What can we do to improve this information (2000 or fewer characters)