 |
John Carrona Windows Expert - Consumer |
| Most Popular Pages: BSOD Index Driver Reference Hard Drive Diagnostics Memory Diagnostics |
Quick
Links to the different sections: Family BSOD Registry Diagnostics Boot Memory Windows Misc |
|
John Carrona Windows Expert - Consumer |
| Most Popular Pages: BSOD Index Driver Reference Hard Drive Diagnostics Memory Diagnostics |
Quick
Links to the different sections: Family BSOD Registry Diagnostics Boot Memory Windows Misc |
******************************************************************************************************
Some notes on the above "canned" speech:
- The purpose of testing all 3rd party drivers is to see
if they are the problem. Most BSOD's are caused by issues with
3rd party drivers - so that's why we test them.
- If there are no
BSOD's within 36 hours (my estimate), then it's most likely that you
either have a Windows problem or a hardware problem. To rule out
Windows drivers - run Driver Verifier on all Windows (aka Microsoft)
drivers. If still no errors, then try a clean install without any
extra programs (but all updates).
- If you're testing 3rd party
drivers and you get a Driver Verifier BSOD that mentions Windows
drivers - then (again) it's most likely a hardware issue or a Windows
issue.
****************************************************************************************************** ****************************************************************************************************** http://www.microsoft.com/whdc/DevTools/tools/DrvVerifier.mspx
MORE NOTES....
[COLOR=Green]THEORY[/COLOR] behind this method:
Driver Verifier marks drivers to be verified early in the Boot Process.
Any BSOD's that occur before this are, therefore, just plain-old BSOD's.
Once operational, BSOD's will be Verifier Enabled if they "trip" the special requirements laid out by Driver Verifier.
You can have non-Verifier Enabled memory dumps even when Driver Verifier is enabled.
It just means that the Driver Verifier conditions weren't "tripped"
Mark Russinovich spoke at TechEd 2006 about crash analysis and laid out the method that I use.
It performs all possible tests on all possible 3rd party drivers.
So, if the 3rd party driver is at fault, then Driver Verifier should catch it with one of the enabled tests.
Not using all of the tests or not verifying all of the 3rd party driver
results in an analysis that has missed some of the possible causes.
Since we've encountered situations where crashes do not occur under Driver Verifier, I adopted the 36 hour rule.
Simply run Driver Verifier for 36 hours - if it doesn't crash, then you can assume it's done all that it'll do.
Why 36 hours? It's a guess that I made :0)
Finally, what about the situation where a driver is stable under normal
conditions - but continues to crash under Driver Verifier?
This results in a hard choice for the user to make:
- could it be a minor hardware fault?
- could it be a fault in the driver?
- could it be a fault in another program that causes the fault in the driver?
There's lot's of things that this could be - so my suggestion is to NOT
use Driver Verifier unless you have a memory dump that indicates that
it might trip Driver Verifier tests.
Drivers have different degrees of stability - so testing a driver without a previous BSOD isn't a valid test IMO.
[COLOR=Green]RESULTS[/COLOR] analysis:
There are 2 possible results from Driver Verifier:
- no BSOD crash
- a BSOD crash
All you can attribute to the absence of a crash is that nothing "tripped" Driver Verifier.
This tells us that the 3rd party drivers aren't likely to be the problem.
If you get a BSOD crash, you may or may not get a memory dump.
So it's important to read all the info on the BSOD screen
If you don't have a memory dump, then it's gonna be very difficult without a driver name from the BSOD itself
If you do have a memory dump, then it may be a bit easier
You'll either have a memory dump that's Verifier Enabled, or one that's not.
If it's not Verifier Enabled - then it's something that has to be fixed before we can re-run Driver Verifier
If it's Verifier Enabled - it'll either point to a 3rd party driver, or not
If it's a 3rd party driver - remove it or fix it (it may be corrupted)
If it's not - then we've got more work to do (you told it to verify 3rd party drivers - but there's wasn't an issue with one).
This is similar to the dump files that aren't Verifier Enabled
Most often it's a hardware problem - but it can also be a compatibility issue or a Windows problem.
(remember the hardware rule - a lot of different BSOD's with a lot of
different errors and causes are usually hardware/compatibility problems)
XP
Verifier tests: Individual
settings: Individual
settings: Windows
7 Verifier tests: Individual
settings:
Predefined settings:
- Standard settings
- Rigorous but possibly excessive or spurious tests
- Low resource simulation
- Special pool
- Pool tracking
- Force IRQL checking
- I/O verification
- Enhanced I/O verification - Not in Win7
- Deadlock detection
- DMA checking
- Low resources simulation
Vista Verifier tests:
Predefined settings:
- Standard settings
- Disk integrity checking - not in Win7
- Enhanced I/O verification - not in Win7
- Force pending I/O requests
- Low resources simulation
- IRP Logging
- Special pool
- Pool tracking
- Force IRQL checking
- I/O verification
- Enhanced I/O verification - Not in Win7
- Deadlock detection
- DMA checking
- Security checks
- Force pending I/O requests
- Low resources simulation
- IRP Logging
- Disk integrity checking - Not in Win7
- Miscellaneous checks
Predefined settings:
- Standard settings
- Force pending I/O requests
- Low resources simulation
- IRP Logging
- Special pool
- Pool tracking
- Force IRQL checking
- I/O verification
- Deadlock detection
- DMA checking
- Security checks
- Force pending I/O requests
- Low resources simulation
- IRP Logging
- Miscellaneous checks