Crash Dumps for Dummies (Part 6)

Bugtation No. 73:
Crash “must be distinguished from” hang “with which it is often confounded.”
Sydney Smith

In part 4 I highlighted the difference between crashes and hangs. In this part I will elaborate on this terminology a bit further. First of all, we have to unify them as manifestations of a functional failure. Considering computer as a system of components having certain functions we shall subdivide failures into system and component failures. Of course, systems may be components in some larger hierarchy, like in the case of virtualization. Application and service process failures fall under component failures category. Blue screen and server freezes fall under system failures category. Now it is obvious why most computer users confuse crashes and hangs. They are just failures and often the distinction between them is blurred from user perspective.

Software developers tend to make sharp distinction between crash and hang terms because they consider a situation when a computer accesses wrong memory or gets and executes an invalid instruction as a crash. However, after such situation a computer system may or may not terminate that application or service. 

Therefore, I propose to consider crashes as situations when a system or a component is not observed anymore. For example, a running application or service disappears from Task Manager, computer system shows blue screen or reboots. In hang situations we can observe that existence of a failed component in Task Manager or a computer system doesn’t reboot automatically and shows some screen image different from BSOD or panic message. The so called sluggish behavior or long response time can also be considered as hang situations.

Here is a simple rough diagram I devised to illuminate the proposed terminological difference:

Based on the clarification above the task of collecting memory or crash dumps is much simpler and clearer.

In the case of a system crash or hang we need to setup correct crash dump options in Advanced System Settings in Control Panel and check page file size in case of the complete memory dump option. A system crash will save the dump automatically. For system hangs we need to actively trigger crash dump saving procedure using either standard keyboard method, SystemDump tool or live system debugging.   

In the case of an application crash we need to set up a postmortem debugger, get WER report or attach a debugger to a component and wait for a failure to happen. In the case of a hang we save a memory dump manually either by using process dumpers like userdump.exe or attaching a debugger.

Links to some dump collection techniques can be found in the previously published part 3 (crashes explained) and part 4 (hangs explained). Forthcoming Windows® Crash Dump Analysis book will discuss all memory dump collection methods thoroughly and in detail.

- Dmitry Vostokov @ DumpAnalysis.org -

6 Responses to “Crash Dumps for Dummies (Part 6)”

  1. Marc Sherman Says:

    The link for “TOC for Windows® Crash Dump Analysis” is broken.

  2. Dmitry Vostokov Says:

    Thanks! I’ve corrected it.

  3. Crash Dump Analysis » Blog Archive » Five golden rules of troubleshooting Says:

    […] - What had happened or had been observed? Crash or hang, for […]

  4. Crash Dump Analysis » Blog Archive » Dictionary of Debugging: Hang Says:

    […] References: Hangs explained, The difference between crashes and hangs explained […]

  5. Crash Dump Analysis » Blog Archive » Dictionary of Debugging: Crash Says:

    […] References: Crashes explained, The difference between crashes and hangs explained […]

  6. Crash Dump Analysis » Blog Archive » Old Mental Dumps from June 24th Says:

    […] • Dictionary of Debugging: Crash - posts that explain the difference between crashes and hangs: http://www.dumpanalysis.org/blog/index.php/2006/11/19/dumps-for-dummies-part-4/ and http://www.dumpanalysis.org/blog/index.php/2007/10/16/crash-dumps-for-dummies-part-6/ […]

Leave a Reply