Debugging an Application Crash 101

Ask the Performance Team - Basic Debugging of an Application Crash

"One of our common issues is troubleshooting application crashes (for example, the Print Spooler or a third-party application).  These crashes usually result in the infamous Dr. Watson error. 

First, let's discuss terminology.  A crash is when something experiences a fault and has no choice but to exit.  In the case of an user mode process that generally means a Dr. Watson popup and application exit, and in the case of the kernel, a Bugcheck.  A crash can be caused by something as simple as a value being set to zero when a function is expecting a non-zero response, or trying to access a section in memory that has either become damaged or that belongs to another process.

Determining the cause of an application crash can be very simple, or extremely complicated - depending on the failure.  You can do something as simple as viewing the Dr. Watson log, or you can do a full debug.  Debugging is very much an art, and a complicated one at that, so we are only going to touch on the really basic concepts in this discussion.  First, let’s go the easy route.

..."

I thought this was a great "Intro to Hunting Down the Crash" post... There's some information I KNOW I will need (for example when I need to hunt down a rare, and impossible to reproduce so far, print spooler crash that gets reported to me every 6 months or so...)