Driver Verifier always on during development ?

NTDEV
1

Driver Verifier is an indispensable tool for finding all kinds of problems
but I am getting more reluctant always put it on all the time throughout the
development stage because I found it can be my enemy as well.

It may be good practice for certain kinds of drivers, but if you wish to
test the logic and functionality of your driver it may become very unhandy
if small pool allocations fail and
all kinds of things that normally go right suddenly go wrong so you may
never get into the situation in which you are able to test the logic and
functionality of your driver because the rare case code paths you are
focusing on are never being reached. In the case you are testing a recursive
function for instance, because all kinds of simple things go wrong the
function is not called as often running under Verifier as without so you may
never reach the situation in which you run out of stack space. I just
realized this, wasting a lot of hours completely forgetting that Verifier
was still on. Drivers behave completely different under Verifier, also your
customers are running without it. My opinion is that one should not put it
on blindly and also never forget that it is on.

2

Daniel

I have the impression from your message that you might be using low
resources simulation of driver verifier a lot. I have found that it is best
not to have that option enabled all the time, but instead to use that option
just when you want to test the resilience of driver to low resource.

Cheers
Lyndon

“Daniel Terhell” wrote in message
news:xxxxx@ntdev…
> Driver Verifier is an indispensable tool for finding all kinds of problems
> but I am getting more reluctant always put it on all the time throughout
> the development stage because I found it can be my enemy as well.
>
> It may be good practice for certain kinds of drivers, but if you wish to
> test the logic and functionality of your driver it may become very unhandy
> if small pool allocations fail and
> all kinds of things that normally go right suddenly go wrong so you may
> never get into the situation in which you are able to test the logic and
> functionality of your driver because the rare case code paths you are
> focusing on are never being reached. In the case you are testing a
> recursive function for instance, because all kinds of simple things go
> wrong the function is not called as often running under Verifier as
> without so you may never reach the situation in which you run out of stack
> space. I just realized this, wasting a lot of hours completely forgetting
> that Verifier was still on. Drivers behave completely different under
> Verifier, also your customers are running without it. My opinion is that
> one should not put it on blindly and also never forget that it is on.
>
>
>

3

one possibility for you to consider is to create duplicate projects.
keep a master one that always has
verifier running on it, and the duplicate is the one where you conduct
code test.

“also your customers are running without it” - you better hope your
custermers don’t run with it; your
suppose too so they don’t have too. If THEY have too, watch out, they
ain’t going to be happy…

m.

Daniel Terhell wrote:

Driver Verifier is an indispensable tool for finding all kinds of problems
but I am getting more reluctant always put it on all the time throughout the
development stage because I found it can be my enemy as well.

It may be good practice for certain kinds of drivers, but if you wish to
test the logic and functionality of your driver it may become very unhandy
if small pool allocations fail and
all kinds of things that normally go right suddenly go wrong so you may
never get into the situation in which you are able to test the logic and
functionality of your driver because the rare case code paths you are
focusing on are never being reached. In the case you are testing a recursive
function for instance, because all kinds of simple things go wrong the
function is not called as often running under Verifier as without so you may
never reach the situation in which you run out of stack space. I just
realized this, wasting a lot of hours completely forgetting that Verifier
was still on. Drivers behave completely different under Verifier, also your
customers are running without it. My opinion is that one should not put it
on blindly and also never forget that it is on.

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

4

Your test processes should of course include a test phase where only
production software is being tested. Driver verifier, checked builds of
anything, etc. are not appropriate for this level of testing.

I tend to leave DV on with default settings for all developer run unit
testing and integration testing. It catches stupid code change induced
errors early. You do have to remember to turn it off when it is
inappropriate to be running though.

Also it is a good idea to get prefast integrated into your build process
and to spend the time to get a baseline clean prefast build. Once again,
by having this tool run automatically it will pick up new code change
errors before they become embedded in the code.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of MM
Sent: Monday, October 16, 2006 7:28 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Driver Verifier always on during development ?

one possibility for you to consider is to create duplicate projects.
keep a master one that always has
verifier running on it, and the duplicate is the one where you conduct
code test.

“also your customers are running without it” - you better hope your
custermers don’t run with it; your
suppose too so they don’t have too. If THEY have too, watch out, they
ain’t going to be happy…

m.

Daniel Terhell wrote:

Driver Verifier is an indispensable tool for finding all kinds of
problems
but I am getting more reluctant always put it on all the time
throughout the
development stage because I found it can be my enemy as well.

It may be good practice for certain kinds of drivers, but if you wish
to
test the logic and functionality of your driver it may become very
unhandy
if small pool allocations fail and
all kinds of things that normally go right suddenly go wrong so you may

never get into the situation in which you are able to test the logic
and
functionality of your driver because the rare case code paths you are
focusing on are never being reached. In the case you are testing a
recursive
function for instance, because all kinds of simple things go wrong the
function is not called as often running under Verifier as without so
you may
never reach the situation in which you run out of stack space. I just
realized this, wasting a lot of hours completely forgetting that
Verifier
was still on. Drivers behave completely different under Verifier, also
your
customers are running without it. My opinion is that one should not put
it
on blindly and also never forget that it is on.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

Low Resource Simulation is an option that should be turned on only when the
code is complete and you think it is ready. You have to have all the error
recovery implemented and testable. If you run windbg, verifier shows a
string when your driver is loaded that indicates verifier is running on it.

“Daniel Terhell” wrote in message
news:xxxxx@ntdev…
> Driver Verifier is an indispensable tool for finding all kinds of problems
> but I am getting more reluctant always put it on all the time throughout
> the development stage because I found it can be my enemy as well.
>
> It may be good practice for certain kinds of drivers, but if you wish to
> test the logic and functionality of your driver it may become very unhandy
> if small pool allocations fail and
> all kinds of things that normally go right suddenly go wrong so you may
> never get into the situation in which you are able to test the logic and
> functionality of your driver because the rare case code paths you are
> focusing on are never being reached. In the case you are testing a
> recursive function for instance, because all kinds of simple things go
> wrong the function is not called as often running under Verifier as
> without so you may never reach the situation in which you run out of stack
> space. I just realized this, wasting a lot of hours completely forgetting
> that Verifier was still on. Drivers behave completely different under
> Verifier, also your customers are running without it. My opinion is that
> one should not put it on blindly and also never forget that it is on.
>
>
>

6

You shouldn’t really routinely run with Low Resource Simulation on. It’s
intended as a means to force allocation failures so you can either verify
your mechanism for ensuring forward progress, or that you fail gracefully.
Enable it, verify that your contingency code works, then turn it off.
Check your contingency code again once in a while.

All the other options should be good all the time except when you are
performance (throughput and/or latency) testing.

Phil

Philip D. Barila

Seagate Technology LLC

(720) 684-1842

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of “Daniel Terhell”


Sent: Monday, October 16, 2006 4:56 AM

To: “Windows System Software Devs Interest List”

Subject: [ntdev] Driver Verifier always on during development ?

Driver Verifier is an indispensable tool for finding all kinds of problems

but I am getting more reluctant always put it on all the time throughout
the

development stage because I found it can be my enemy as well.

It may be good practice for certain kinds of drivers, but if you wish to

test the logic and functionality of your driver it may become very unhandy

if small pool allocations fail and

^^^^^^^ This should only happen if Low Resource Sim is on.

all kinds of things that normally go right suddenly go wrong so you may

never get into the situation in which you are able to test the logic and

functionality of your driver because the rare case code paths you are

focusing on are never being reached.

[snip]

7

Also keep in mind that Driver Verifier slows down the whole system and not
only the currently verified driver(s). I see about 2x-3x slowdown in my build
times (large build using GNU make & MS cl) when Driver Verifier is enabled
for my driver but the driver is idle. IMO, it is a major deficiency in Driver
Verifier that frequently precludes using it on customer’s systems.

Dmitriy Budko
VMware

8

Gosh, I dont run driver verifier on our build servers, and I dont run driver
verifier on my development desktop, no thanks to that, but I do run driver
verifier on my test systems.

“Dmitriy Budko” wrote in message news:xxxxx@ntdev…
Also keep in mind that Driver Verifier slows down the whole system and not
only the currently verified driver(s). I see about 2x-3x slowdown in my
build
times (large build using GNU make & MS cl) when Driver Verifier is enabled
for my driver but the driver is idle. IMO, it is a major deficiency in
Driver
Verifier that frequently precludes using it on customer’s systems.

Dmitriy Budko
VMware