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...)
No comments:
Post a Comment