We seem to get a large number of emails to the list that ask, in essence,
"why is my driver crashing". Though I'd like to help (well, usually), I
often find myself frustrated at the lack of information provided by the
author. To assist similar questioners in the future, I thought I'd put
together some guidance on the kinds of information that I find helpful in
diagnosing the reason for a crash.
Crash analysis is non-trivial. But with the right information, it's usually
possible to at least determine why the system crashed, if not identify the
actual cause of the crash. Understand that these are different: The system
may crash due to dereferencing a bad pointer. That's WHY it crashed. The
pointer may be bad because some driver, that has been unloaded long ago,
trashed a data-structure in non-paged pool. That's the CAUSE of the crash.
To help in the analysis, please provide as much of the following information
as possible (note: This list is in approximate order of importance):
1) Please supply at least a symbolic strack trace, WITH THE CORRECT SYMBOLS
set up for your driver, the kernel, and the HAL. This is of primary
importance. If possible provide the stack trace (and all other details
more) from !Analyze -v from WinDbg. Post the output in the command window
starting with and including the line on which you typed !analyze -v, all the
way through the end of the output. If you can't be bothered getting and
posting a proper stack trace, I suggest you not expect the list members to
be bothered with diagnosing your crash.
2) Please look at the parts of the stack trace that appear to be within your
driver, and tell us what you're driver is doing at each location. If
possible, supply a few lines of code preceding each entry made for your
driver on the stack. This should be as simple as a double-clicking on your
driver's entries in the crash stack in WinDbg.
3) If this is your driver, crashing in your lab or on your test machine,
reproduce the problem with DriverVerifier running (with all options turned
on EXCEPT for low resource simulation), and using the checked kernel and
hal. Don't waste your time (or ours) trying to repro the problem on a
system running the free builds or without Verifier, UNLESS the problem ONLY
occurs on the free build or with Verifier off (and if this is the case, be
SURE to tell us).
4) Describe the scenario under which the crash is obtained, in as much
detail as you can manage. Bear in mind that the several thousand people who
read this list are not each intimately familiar with your project. So
please be clear.
5) If you have a suspicion about the case of the problem, by all means let
6) Monitor the list closely for follow-up questions. Even with all the
information above, you should expect there to be one or two more questions
about the problem.
Given the above, the people on this list can probably help identify just
about ANY crash problem you come across.