Driver Verifier, low resources testing

[Gary G. Little]

When testing low resources response, does verifier at any point "free"
resources to permit the driver to function or does it just hog them? Or ...
what needs to be done to "free" Verifier garnished resources. Case in point:
I set a 5 retry loop to map a user buffer for kernel mode using
MmProbeandLock pages. With LR enabled in Verifier the loop would iterate 5
times and the driver return an error status. Is 5 retries sufficient? 100?
200? When/or how does Verifier "free" the resources it stole?

How do I know it was Verifier? Users without Verifier enabled for LR were
not seeing the same status returned.

 

[Maxim S. Shatskih]

When testing low resources response, does verifier at any point "free"

resources to permit the driver to function or does it just hog them?

It just fails some ExAllocatePoolWithTag and other allocation calls at random.

 

[Gary G. Little]

But how does it unfail them? Can you repeatedly request the resource until
Verifier releases the resource, or it will it always fail that request until
some kind of "reset". If so then how do you do that "reset"? Change IRQL?
Return from the driver and let the application retry?

 

[Doron Holan [MS]]

you gracefully fail. what graceful means to your driver is up to you. in
all the drivers i have written, i just return STATUS_INSUFFICIENT_RESOURCES.
if you require the resources for forward progress, you need to create a
lmiited cache of what you need and fall back onto that cache when you can't
dynamically allocate the required structures.

d

 

[Tim Roberts]

But how does it unfail them? Can you repeatedly request the resource until
Verifier releases the resource, or it will it always fail that request until
some kind of "reset".

You aren't supposed to recover/retry. That defeats the whole purpose. The
point of the "low resource simulation" is to see whether your driver
gracefully fails when memory really IS low, as opposed to just exploding.

If so then how do you do that "reset"? Change IRQL?
Return from the driver and let the application retry?

As Don suggested, you return a reasonable error. The application will
presumably die, the instance will be closed, and your driver will have the
chance to clean itself up.

I hope it is obvious that the "low resource simulation" is not intended to
be enabled on a production machine.

 

[Gary G. Little]

Well, I am failing it gracefully, though I am doing a retry to see if
resources are released before failing the IRP. I had actually forgotten I
had LR testing turned on, so I originally was addressing why the driver was
failing a transfer. Once I realized it was Verifier "doin' it's thang" I
realized the driver was functioning properly, but wanted it to recover in
the retry loop. If that is going to happen it will have to be on a request
to retry from the application with a new IRP.

Thanks for the assist gentlemen ...

--
Gary G. Little
Seagate Technologies, LLC

you gracefully fail. what graceful means to your driver is up to you. in
all the drivers i have written, i just return STATUS_INSUFFICIENT_RESOURCES.
if you require the resources for forward progress, you need to create a
lmiited cache of what you need and fall back onto that cache when you can't
dynamically allocate the required structures.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Dan Mihai [MSFT]]

Please start by reading the WDK doc at
http://msdn.microsoft.com/library/d..._e8445302-19ca-4048-b1f0-a36a70f03008.xml.asp.

For Windows Server 2003 and earlier Windows versions, the probability of
failing any supported APIs was approximately 6%. These failures get injected
randomly so 5 retries might be sufficient but that's not sure. It's all
random.

For Vista, Low Resources Simulation is more flexible. You can customize its
behavior. The doc I mentioned above has information about those Vista
changes. The doc from
http://www.microsoft.com/whdc/DevTools/tools/vistaverifier.mspx has
information too.



For any version of the OS, let's assume you chose to enable Special Pool and
Low Resources Simulation together. That would be Verifier flags 0x5, e.g.

verifier.exe /flags 0x5 /driver mydriver.sys

At any point during testing, you can turn off Low Resource Simulation, to
give your driver a break from failures:

verifier.exe /volatile /flags 0x1

Later on, you can re-start injecting faults with:

verifier.exe /volatile /flags 0x5



You can check if you have had any faults injected by Verifier by using
!verifier in a kernel debugger, e.g.

kd> !verifier

....

Pool Allocations Failed 0x5a <<<- some
allocations did fail

Resource Allocations Failed Deliberately 0x0 <<<- However Verifier
did NOT inject failures

Or you can use verifier.exe /query to check out run time statistics, e.g.:

C:\>verifier.exe /query

....

AllocationsFailed: 0
<<<- no allocation failures

AllocationsFailedDeliberately: 0 <<<-
Verifier didn't inject any failures

....

Dan