******************************************************************************************************
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:
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
Individual settings:
- 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
Windows 8 Consumer Preview Verifier tests:
Predefined settings:
- Standard settings
- Force pending I/O requests
- Low resources simulation
- IRP Logging
Individual settings:
- 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
- Concurrency
Stress Test Now is Power Framework Delay Fuzzing (changed from the Preview to the Release version)
- DDI compliance checking
New
tests listed here: http://msdn.microsoft.com/en-us/library/windows/hardware/hh698274%28v=vs.85%29.aspx
Windows
8.1 Verifier tests:
from: http://msdn.microsoft.com/en-us/library/windows/hardware/ff545470%28v=vs.85%29.aspx
These checks are always performed on a driver that is being verified, regardless of which options have been selected. If the driver uses memory at an improper IRQL, improperly calls or releases spin locks and memory allocations, improperly switches stacks, or frees memory pool without first removing timers, Driver Verifier will detect this behavior. When the driver is unloaded, Driver Verifier will check to see that it has properly released its resources.
When this option is active, Driver Verifier allocates most of the driver's memory requests from a special pool. This special pool is monitored for memory overruns, memory underruns, and memory that is accessed after it is freed.
When this option is active, Driver Verifier places extreme memory pressure on the driver by invalidating pageable code. If the driver attempts to access paged memory at the wrong IRQL or while holding a spin lock, Driver Verifier detects this behavior.
When this option is active, Driver Verifier randomly fails pool allocation requests and other resource requests. By injecting these allocation faults into the system, Driver Verifier tests the driver's ability to cope with a low-resource situation.
When this option is active, Driver Verifier checks to see if the driver has freed all its memory allocations when it is unloaded. This reveals memory leaks.
When this option is active, Driver Verifier allocates the driver's IRPs from a special pool, and monitors the driver's I/O handling. This detects illegal or inconsistent use of I/O routines.
(Windows XP and later) When this option is active, Driver Verifier monitors the driver's use of spin locks, mutexes, and fast mutexes. This detects if the driver's code has the potential for causing a deadlock at some point.
(Windows XP and later) When this option is active, Driver Verifier monitors the calls of several I/O Manager routines and performs stress testing of PnP IRPs, power IRPs and WMI IRPs. In Windows 7 and later versions of the Windows operating system, all the features of Enhanced I/O Verification are included as part of I/O Verification and it is no longer available nor necessary to select this option in Driver Verifier Manager or from the command line.
(Windows XP and later) When this option is active, Driver Verifier monitors the driver's use of DMA routines. This detects improper use of DMA buffers, adapters, and map registers.
(Windows Vista and later) When this option is active, Driver Verifier looks for common errors that can result in security vulnerabilities, such as a reference to user-mode addresses by kernel-mode routines.
(Windows Vista and later) When this option is active, Driver Verifier looks for common causes of driver crashes, such as the mishandling of freed memory.
(Windows Vista and later) When this option is active, Driver Verifier tests the driver's response to STATUS_PENDING return values by returning STATUS_PENDING for random calls to IoCallDriver.
(Windows Server 2003 and later) When this option is active, Driver Verifier monitors a driver's use of IRPs and creates a log of IRP use.
(Introduced in Windows Server 2003. Not available in Windows 7 and later.) When this option is active, Driver Verifier monitors hard disk access, and detects whether the disk is preserving its data correctly.
(Windows XP and later) When this option is active, Driver Verifier monitors a SCSI miniport driver for improper use of exported SCSI port routines, excessive delays, and improper handling of SCSI requests.
(Windows Vista and later) When this option is active, Driver Verifier monitors a Storport miniport driver for improper use of exported Storport routines, excessive delays, and improper handling of Storport requests.
(Starting with Windows 8) When this option is active, Driver Verifier randomizes thread schedules to help flush out concurrency errors in the drivers that use the power management framework (PoFx). This option is not recommended for drivers that do not directly utilize the power management framework (PoFx)..
(Starting with Windows 8) When this option is active, Driver Verifier applies a set of device driver interface (DDI) rules that check for the proper interaction between a driver and the kernel interface of the operating system.
(Starting with Windows 8) The Invariant MDL Checking for Stack option monitors how the driver handles invariant MDL buffers across the driver stack. Driver Verifier can detect illegal modification of invariant MDL buffers. To use this option, I/O Verification must be enabled on at least one driver.
(Starting with Windows 8) The Invariant MDL Checking for Driver option monitors how the driver handles invariant MDL buffers on a per-driver basis. This option detects illegal modification of invariant MDL buffers. To use this option, you must enable I/O Verification on at least one driver.
(Only available with Windows 8 and WDK 8) The Stack Based Failure Injection option injects resource failures in kernel mode drivers. This option uses a special driver, KmAutoFail.sys, in conjunction with Driver Verifier to penetrate driver error handling paths.
(Starting with Windows 8.1) The Systematic low resources simulation option injects resource failures in kernel mode drivers.
(Starting with Windows 8.1) When this option is active, Driver Verifier applies a set of NDIS and wireless LAN (WIFI) rules that check for the proper interaction between an NDIS miniport driver and the operating system kernel.
(Starting with Windows 8.1) This option randomizes thread schedules to help detect concurrency bugs in drivers.
(Starting with Windows 8.1) This option monitors filter drivers (extensible switch extensions) that run inside the Hyper-V Extensible Switch.