Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.More Info on Driver Writing and Debugging
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
Is it possible to automatically turn off driver verifier after the reboot?
One problem I have with using driver verifier, is that if it catches a rare bug in a boot driver during boot, this will cause the machine to no longer boot up as it will always bugcheck during boot.
This is fine on test machines, but on customers machine this will obviously cause problems.
My question is, is there anyway to make the driver verifier stop after the first reboot, so it would no longer run on the second boot therefore the system could boot up?
Howdy, Stranger!
| Upcoming OSR Seminars | ||
|---|---|---|
| OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
| Internals & Software Drivers | 19-23 June 2023 | Live, Online |
| Writing WDF Drivers | 10-14 July 2023 | Live, Online |
| Kernel Debugging | 16-20 October 2023 | Live, Online |
| Developing Minifilters | 13-17 November 2023 | Live, Online |
Comments
kernel debugger: !verifier -disable
verifier.exe /bootmode resetonbootfailWhy are customer machines running driver verifier? I'm curious what the scenario is here
You should never have Driver Verifier turned on in a customer machine, unless you are actively debugging a problem. It blue screens on many issues
that are actually just warnings.
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
But what are the other options in case of a very rare kernel mode bug that only gets reproduced on a customer machine?
This is assuming that using usual tools such as poolmon we could not find the bug.
For example assume a very rare kernel pool corruption type of bug, that the normal kernel dumps wouldn't help to find the root cause of the problem, then in this case I assume running driver verifier there is the only option right?
Another example is double free of an IRP structure (IoFreeIrp) by ntoskrnl itself (!), and we are sure that we did not create or free this IRP, so how else can we find the root cause of it?
I suppose this seems reasonable, thanks
There are always weird exception cases.
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.