using KeWaitForxxx properly with verifier

Hi,

In my driver I have to acquire a mutex in a routine which gets called both
at PASSIVE_LEVEL as well as DISPATCH_LEVEL from a DPC routine.
The DDK doc says that it is okay to use KeWaitForMutexObject or
KeWaitForSingleObject at DISPATCH_LEVEL if a timeout of 0 is specified.

This goes fine, however when I put on Driver Verifier, I have to alter my
code to support the different IRQLs. I’m now acquiring my mutex in the
following routine:

void WaitForMutex(BOOLEAN fromDPC)
{
LARGE_INTEGER timeOut={0,0},*t;
if (fromDPC==TRUE) t=&timeOut; else t=NULL;
KeWaitForSingleObject(&MyMutex,Executive, KernelMode, FALSE, t);
}

It appears that the Driver Verifier won’t accept a timeout of NULL at
DISPATCH_LEVEL, but insists on an initialized variable containing 0 instead.

But this is not where the problems finishes. If I put on deadlock detection
in the verifier, these KeWaitForxxx functions sometimes fail just for the
fun of it, then the blue screen comes when trying to release a mutex which
was never acquired. This means I have to check the return values of these
KeWaitForxxx functions. However if I check the sample code from the DDK or
drivers written by the gurus they never check these return values.

The question is whether it is not silly to alter and compromise code which
is otherwise running perfectly well only to satisfy the verifier ?

Thanks,

Daniel in Resplendence

You can not wait on DPC level!
Using Timeout=0 means: look at the status now at return immediately.
Nothing is acquired.

Use spinlocks to synchronize your access. Not the mutex!

Norbert.

“The more original a discovery, the more obvious is seems afterwards.”
---- snip ----

Hi Deniel,

Simple Question Why u put Driver Verifier on ur driver? If you felt that there is a need to check with that and want to know more abt that then the results what you are getting shud be reactified according to the MS standard.

 

Good Luck,



From: “Daniel Terhell”

>Reply-To: “Windows System Software Devs Interest List”
>To: “Windows System Software Devs Interest List”
>Subject: [ntdev] using KeWaitForxxx properly with verifier
>Date: Thu, 11 Mar 2004 13:02:00 +0100
>
>Hi,
>
>In my driver I have to acquire a mutex in a routine which gets called both
>at PASSIVE_LEVEL as well as DISPATCH_LEVEL from a DPC routine.
>The DDK doc says that it is okay to use KeWaitForMutexObject or
>KeWaitForSingleObject at DISPATCH_LEVEL if a timeout of 0 is specified.
>
>This goes fine, however when I put on Driver Verifier, I have to alter my
>code to support the different IRQLs. I’m now acquiring my mutex in the
>following routine:
>
>void WaitForMutex(BOOLEAN fromDPC)
>{
> LARGE_INTEGER timeOut={0,0},*t;
> if (fromDPC==TRUE) t=&timeOut; else t=NULL;
> KeWaitForSingleObject(&MyMutex,Executive, KernelMode, FALSE, t);
>}
>
>It appears that the Driver Verifier won’t accept a timeout of NULL at
>DISPATCH_LEVEL, but insists on an initialized variable containing 0 instead.
>
>But this is not where the problems finishes. If I put on deadlock detection
>in the verifier, these KeWaitForxxx functions sometimes fail just for the
>fun of it, then the blue screen comes when trying to release a mutex which
>was never acquired. This means I have to check the return values of these
>KeWaitForxxx functions. However if I check the sample code from the DDK or
>drivers written by the gurus they never check these return values.
>
>The question is whether it is not silly to alter and compromise code which
>is otherwise running perfectly well only to satisfy the verifier ?
>
>
>Thanks,
>
>Daniel in Resplendence
>
>
>
>
>
>—
>Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com


Easiest Money Transfer to India . Send Money To 6000 Indian Towns. Easiest Way To Send Money Home!

You are right, I realize now it’s written here:
“If no Timeout is supplied, the calling thread remains in a wait state until
the Object is signaled.
A Timeout of zero allows the testing of a set of wait conditions and for the
conditional performance of any side effects if the wait can be immediately
satisfied, as in the acquisition of a mutex.”

I guess I’ve been taking too much vtooLSD lately. Sorry to bother you all.

Daniel in Resplendence

Hi Daniel,

Just read more about the synchronization mechanisms at various level, the documentation will tell you how to do that. For dispatch level synchronization u need to use Spinlocks or if you want to use other mechanism then you need to carefully take care of other things, like then time out and all.

 

Good Luck,



From: “Daniel Terhell”

>Reply-To: “Windows System Software Devs Interest List”
>To: “Windows System Software Devs Interest List”
>Subject: [ntdev] using KeWaitForxxx properly with verifier
>Date: Thu, 11 Mar 2004 13:02:00 +0100
>
>Hi,
>
>In my driver I have to acquire a mutex in a routine which gets called both
>at PASSIVE_LEVEL as well as DISPATCH_LEVEL from a DPC routine.
>The DDK doc says that it is okay to use KeWaitForMutexObject or
>KeWaitForSingleObject at DISPATCH_LEVEL if a timeout of 0 is specified.
>
>This goes fine, however when I put on Driver Verifier, I have to alter my
>code to support the different IRQLs. I’m now acquiring my mutex in the
>following routine:
>
>void WaitForMutex(BOOLEAN fromDPC)
>{
> LARGE_INTEGER timeOut={0,0},*t;
> if (fromDPC==TRUE) t=&timeOut; else t=NULL;
> KeWaitForSingleObject(&MyMutex,Executive, KernelMode, FALSE, t);
>}
>
>It appears that the Driver Verifier won’t accept a timeout of NULL at
>DISPATCH_LEVEL, but insists on an initialized variable containing 0 instead.
>
>But this is not where the problems finishes. If I put on deadlock detection
>in the verifier, these KeWaitForxxx functions sometimes fail just for the
>fun of it, then the blue screen comes when trying to release a mutex which
>was never acquired. This means I have to check the return values of these
>KeWaitForxxx functions. However if I check the sample code from the DDK or
>drivers written by the gurus they never check these return values.
>
>The question is whether it is not silly to alter and compromise code which
>is otherwise running perfectly well only to satisfy the verifier ?
>
>
>Thanks,
>
>Daniel in Resplendence
>
>
>
>
>
>—
>Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com


Get head-hunted by 10,000 recruiters. Post your CV on naukri.com today.

Truly, a dumb question. Any rational developer will have verifier on during
all the time of development. Most of the developers I respect have it on
with a checked build!


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting

“yatindra vaishnav” wrote in message
news:xxxxx@ntdev…
Hi Deniel,
Simple Question Why u put Driver Verifier on ur driver? If you felt that
there is a need to check with that and want to know more abt that then the
results what you are getting shud be reactified according to the MS
standard.
.

Well perhaps you are overstating the case Don. The checked build and driver
verifier are important tools (esp. verifier,) but I disagree with your
statement that they should be constantly in use during development. In fact
both verifier and the checked build create artificial execution environments
that are quite different from the actual production environment.
Consequently you must, at some well defined point in the development cycle,
switch over to testing your driver against the production environment rather
than against the checked build or with verifier.

The case for verifier can be better stated as: you aren’t going to pass whql
if DV and your driver are not compatible. Consequently, for any whql’d
driver, DV validation is a necessary step. Developers put off DV validation
until they need to whql at their and their company’s peril.

I generally don’t care much for the checked OS. Mostly I put strong checking
into the checked versions of my drivers, and do not rely at all on the
verification in the checked build. At best I might move some components from
the checked build onto a test system to help diagnose a specific problem,
but that is such a pain in the ass these days that quite frankly I can’t
remember the last time I resorted to this tactic.

The development cycle is perhaps something like this:

  1. checked driver unit testing optionally against the checked OS.

  2. validation with verifier.

  3. your checked driver integration testing against the production OS,
    optionally with some checked OS components, and perhaps other related
    checked drivers in development.

  4. validation with verifier, preliminary whql testing.

  5. your production driver system testing against the production OS and
    production related components in development.

  6. whql certification/signing.

=====================
Mark Roddy

-----Original Message-----
From: Don Burn [mailto:xxxxx@acm.org]
Sent: Thursday, March 11, 2004 8:22 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] using KeWaitForxxx properly with verifier

Truly, a dumb question. Any rational developer will have
verifier on during all the time of development. Most of the
developers I respect have it on with a checked build!


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting

“yatindra vaishnav” wrote in message
> news:xxxxx@ntdev…
> Hi Deniel,
> Simple Question Why u put Driver Verifier on ur driver? If
> you felt that
> there is a need to check with that and want to know more abt
> that then the
> results what you are getting shud be reactified according to the MS
> standard.
> .
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@stratus.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Mark,

I didn’t mean to imply you never used the production environment, just
that during development you take advantage of all the capabilities you can.
I find it foolish not to take advantage of the checked build’s additional
debug output, and am uncomfortable with the mix and match approach of
checked/free components beyond the ntoskrnl/hal checked and the rest of the
world free. I know potentially that verifier can mask a problem but have
never seen it in practice. My cycle would be a little different than yours:

  1. Initial Driver Development

Compile check build driver with /W4 (with some pragma’s around
the DDK includes since the aren’t /W4 clean) and PreFast. Create INF file
and run it through ChkInf on creation or change. Debug driver on a checked
build with driver verifier turned on. I also at times use the Call Usage
Verifier, but not always since it can give annoying false positives. NOTE:
I consider anything from checked build or verifier to be a real bug.

  1. Driver testing phase I

I run the checked build driver with all the tests I can on the
checked build with verifier with code coverage when available.

  1. Driver testing phase II

I run the free build driver with all the tests on free build,
both uni-processor and multi-processor. Note: everything prior to this was
multi-processor.

  1. Driver tuning

I run performance test with profiling turned on to check for hot
spots.

  1. WHQL submission

Note: I am trying to run WHQL tests from step 2 on (actually
sometime as part of development testing so step 1), unfortunately I have
seen problems with WHQL on a checked build!

Don

“Roddy, Mark” wrote in message news:xxxxx@ntdev…
> Well perhaps you are overstating the case Don. The checked build and
driver
> verifier are important tools (esp. verifier,) but I disagree with your
> statement that they should be constantly in use during development. In
fact
> both verifier and the checked build create artificial execution
environments
> that are quite different from the actual production environment.
> Consequently you must, at some well defined point in the development
cycle,
> switch over to testing your driver against the production environment
rather
> than against the checked build or with verifier.
>
> The case for verifier can be better stated as: you aren’t going to pass
whql
> if DV and your driver are not compatible. Consequently, for any whql’d
> driver, DV validation is a necessary step. Developers put off DV
validation
> until they need to whql at their and their company’s peril.
>
> I generally don’t care much for the checked OS. Mostly I put strong
checking
> into the checked versions of my drivers, and do not rely at all on the
> verification in the checked build. At best I might move some components
from
> the checked build onto a test system to help diagnose a specific problem,
> but that is such a pain in the ass these days that quite frankly I can’t
> remember the last time I resorted to this tactic.
>
> The development cycle is perhaps something like this:
>
> 1. checked driver unit testing optionally against the checked OS.
>
> 2. validation with verifier.
>
> 3. your checked driver integration testing against the production OS,
> optionally with some checked OS components, and perhaps other related
> checked drivers in development.
>
> 4. validation with verifier, preliminary whql testing.
>
> 5. your production driver system testing against the production OS and
> production related components in development.
>
> 6. whql certification/signing.
>
>
> =====================
> Mark Roddy
>
>
> > -----Original Message-----
> > From: Don Burn [mailto:xxxxx@acm.org]
> > Sent: Thursday, March 11, 2004 8:22 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re:[ntdev] using KeWaitForxxx properly with verifier
> >
> > Truly, a dumb question. Any rational developer will have
> > verifier on during all the time of development. Most of the
> > developers I respect have it on with a checked build!
> >
> > –
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> >
> >
> > “yatindra vaishnav” wrote in message
> > news:xxxxx@ntdev…
> > Hi Deniel,
> > Simple Question Why u put Driver Verifier on ur driver? If
> > you felt that
> > there is a need to check with that and want to know more abt
> > that then the
> > results what you are getting shud be reactified according to the MS
> > standard.
> > .
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@stratus.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>

I would add to this cycle that you should use a code coverage tool during
testing. Don’t rely on WHQL tests and DriverVerifier as complete QA
testing. There could be untested code. You won’t really know unless you
use a code coverage tool that shows you what lines of code have been
executed.

If, after running the WHQL tests and/or using DriverVerifier, only 75% of
your code has been executed, then that’s 25% of code that could contain a
serious bug. Wouldn’t you want to know the risk of shipping your driver?
Wouldn’t you want to know which lines of code have been executed? Then you
alter your tests to execute those untested parts of the driver.

Blindly testing with WHQL and DriverVerifier is good. Using a code coverage
tool with it is better.

Sorry for the shameless plug = use TrueCoverage from Numega as a code
coverage tool during testing.

Steve Smith
www.compuware.com\products\driverstudio

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Don Burn
Sent: Thursday, March 11, 2004 9:30 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] using KeWaitForxxx properly with verifier

Mark,

I didn’t mean to imply you never used the production environment, just
that during development you take advantage of all the capabilities you can.
I find it foolish not to take advantage of the checked build’s additional
debug output, and am uncomfortable with the mix and match approach of
checked/free components beyond the ntoskrnl/hal checked and the rest of the
world free. I know potentially that verifier can mask a problem but have
never seen it in practice. My cycle would be a little different than yours:

  1. Initial Driver Development

Compile check build driver with /W4 (with some pragma’s around
the DDK includes since the aren’t /W4 clean) and PreFast. Create INF file
and run it through ChkInf on creation or change. Debug driver on a checked
build with driver verifier turned on. I also at times use the Call Usage
Verifier, but not always since it can give annoying false positives. NOTE:
I consider anything from checked build or verifier to be a real bug.

  1. Driver testing phase I

I run the checked build driver with all the tests I can on the
checked build with verifier with code coverage when available.

  1. Driver testing phase II

I run the free build driver with all the tests on free build,
both uni-processor and multi-processor. Note: everything prior to this was
multi-processor.

  1. Driver tuning

I run performance test with profiling turned on to check for hot
spots.

  1. WHQL submission

Note: I am trying to run WHQL tests from step 2 on (actually
sometime as part of development testing so step 1), unfortunately I have
seen problems with WHQL on a checked build!

Don

“Roddy, Mark” wrote in message news:xxxxx@ntdev…
> Well perhaps you are overstating the case Don. The checked build and
driver
> verifier are important tools (esp. verifier,) but I disagree with your
> statement that they should be constantly in use during development. In
fact
> both verifier and the checked build create artificial execution
environments
> that are quite different from the actual production environment.
> Consequently you must, at some well defined point in the development
cycle,
> switch over to testing your driver against the production environment
rather
> than against the checked build or with verifier.
>
> The case for verifier can be better stated as: you aren’t going to pass
whql
> if DV and your driver are not compatible. Consequently, for any whql’d
> driver, DV validation is a necessary step. Developers put off DV
validation
> until they need to whql at their and their company’s peril.
>
> I generally don’t care much for the checked OS. Mostly I put strong
checking
> into the checked versions of my drivers, and do not rely at all on the
> verification in the checked build. At best I might move some components
from
> the checked build onto a test system to help diagnose a specific problem,
> but that is such a pain in the ass these days that quite frankly I can’t
> remember the last time I resorted to this tactic.
>
> The development cycle is perhaps something like this:
>
> 1. checked driver unit testing optionally against the checked OS.
>
> 2. validation with verifier.
>
> 3. your checked driver integration testing against the production OS,
> optionally with some checked OS components, and perhaps other related
> checked drivers in development.
>
> 4. validation with verifier, preliminary whql testing.
>
> 5. your production driver system testing against the production OS and
> production related components in development.
>
> 6. whql certification/signing.
>
>
> =====================
> Mark Roddy
>
>
> > -----Original Message-----
> > From: Don Burn [mailto:xxxxx@acm.org]
> > Sent: Thursday, March 11, 2004 8:22 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re:[ntdev] using KeWaitForxxx properly with verifier
> >
> > Truly, a dumb question. Any rational developer will have
> > verifier on during all the time of development. Most of the
> > developers I respect have it on with a checked build!
> >
> > –
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> >
> >
> > “yatindra vaishnav” wrote in message
> > news:xxxxx@ntdev…
> > Hi Deniel,
> > Simple Question Why u put Driver Verifier on ur driver? If
> > you felt that
> > there is a need to check with that and want to know more abt
> > that then the
> > results what you are getting shud be reactified according to the MS
> > standard.
> > .
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@stratus.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>


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

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

See my step 2! Of course I use Ccover from http://www.bullseye.com/ but
then I never could justify the cost of DriverStudio for the few tools I
would use.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting

“Smith, Steve” wrote in message
news:xxxxx@ntdev…
> I would add to this cycle that you should use a code coverage tool during
> testing. Don’t rely on WHQL tests and DriverVerifier as complete QA
> testing. There could be untested code. You won’t really know unless you
> use a code coverage tool that shows you what lines of code have been
> executed.
>
> If, after running the WHQL tests and/or using DriverVerifier, only 75% of
> your code has been executed, then that’s 25% of code that could contain a
> serious bug. Wouldn’t you want to know the risk of shipping your driver?
> Wouldn’t you want to know which lines of code have been executed? Then
you
> alter your tests to execute those untested parts of the driver.
>
> Blindly testing with WHQL and DriverVerifier is good. Using a code
coverage
> tool with it is better.
>
> Sorry for the shameless plug = use TrueCoverage from Numega as a code
> coverage tool during testing.
>
> Steve Smith
> www.compuware.com\products\driverstudio
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Don Burn
> Sent: Thursday, March 11, 2004 9:30 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] using KeWaitForxxx properly with verifier
>
>
> Mark,
>
> I didn’t mean to imply you never used the production environment,
just
> that during development you take advantage of all the capabilities you
can.
> I find it foolish not to take advantage of the checked build’s additional
> debug output, and am uncomfortable with the mix and match approach of
> checked/free components beyond the ntoskrnl/hal checked and the rest of
the
> world free. I know potentially that verifier can mask a problem but have
> never seen it in practice. My cycle would be a little different than
yours:
>
> 1. Initial Driver Development
>
> Compile check build driver with /W4 (with some pragma’s around
> the DDK includes since the aren’t /W4 clean) and PreFast. Create INF file
> and run it through ChkInf on creation or change. Debug driver on a
checked
> build with driver verifier turned on. I also at times use the Call Usage
> Verifier, but not always since it can give annoying false positives.
NOTE:
> I consider anything from checked build or verifier to be a real bug.
>
> 2. Driver testing phase I
>
> I run the checked build driver with all the tests I can on the
> checked build with verifier with code coverage when available.
>
> 3. Driver testing phase II
>
> I run the free build driver with all the tests on free build,
> both uni-processor and multi-processor. Note: everything prior to this
was
> multi-processor.
>
> 4. Driver tuning
>
> I run performance test with profiling turned on to check for
hot
> spots.
>
> 5. WHQL submission
>
> Note: I am trying to run WHQL tests from step 2 on (actually
> sometime as part of development testing so step 1), unfortunately I have
> seen problems with WHQL on a checked build!
>
> Don
>
> “Roddy, Mark” wrote in message
news:xxxxx@ntdev…
> > Well perhaps you are overstating the case Don. The checked build and
> driver
> > verifier are important tools (esp. verifier,) but I disagree with your
> > statement that they should be constantly in use during development. In
> fact
> > both verifier and the checked build create artificial execution
> environments
> > that are quite different from the actual production environment.
> > Consequently you must, at some well defined point in the development
> cycle,
> > switch over to testing your driver against the production environment
> rather
> > than against the checked build or with verifier.
> >
> > The case for verifier can be better stated as: you aren’t going to pass
> whql
> > if DV and your driver are not compatible. Consequently, for any whql’d
> > driver, DV validation is a necessary step. Developers put off DV
> validation
> > until they need to whql at their and their company’s peril.
> >
> > I generally don’t care much for the checked OS. Mostly I put strong
> checking
> > into the checked versions of my drivers, and do not rely at all on the
> > verification in the checked build. At best I might move some components
> from
> > the checked build onto a test system to help diagnose a specific
problem,
> > but that is such a pain in the ass these days that quite frankly I can’t
> > remember the last time I resorted to this tactic.
> >
> > The development cycle is perhaps something like this:
> >
> > 1. checked driver unit testing optionally against the checked OS.
> >
> > 2. validation with verifier.
> >
> > 3. your checked driver integration testing against the production OS,
> > optionally with some checked OS components, and perhaps other related
> > checked drivers in development.
> >
> > 4. validation with verifier, preliminary whql testing.
> >
> > 5. your production driver system testing against the production OS and
> > production related components in development.
> >
> > 6. whql certification/signing.
> >
> >
> > =====================
> > Mark Roddy
> >
> >
> > > -----Original Message-----
> > > From: Don Burn [mailto:xxxxx@acm.org]
> > > Sent: Thursday, March 11, 2004 8:22 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: Re:[ntdev] using KeWaitForxxx properly with verifier
> > >
> > > Truly, a dumb question. Any rational developer will have
> > > verifier on during all the time of development. Most of the
> > > developers I respect have it on with a checked build!
> > >
> > > –
> > > Don Burn (MVP, Windows DDK)
> > > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > >
> > >
> > > “yatindra vaishnav” wrote in message
> > > news:xxxxx@ntdev…
> > > Hi Deniel,
> > > Simple Question Why u put Driver Verifier on ur driver? If
> > > you felt that
> > > there is a need to check with that and want to know more abt
> > > that then the
> > > results what you are getting shud be reactified according to the MS
> > > standard.
> > > .
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@stratus.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
>

This sounds like a bonafied bug in a static analysis !!!

What could the DV do, if I declare a variable, and set it to zero. It would
have to ply thru and find the value of a variable, if zero then let it pass,
otherwise raise a flag.

This variable’s value can change anywhere !. So it is tough here !

-prokash

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Daniel Terhell
Sent: Thursday, March 11, 2004 4:02 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] using KeWaitForxxx properly with verifier

Hi,

In my driver I have to acquire a mutex in a routine which gets called both
at PASSIVE_LEVEL as well as DISPATCH_LEVEL from a DPC routine.
The DDK doc says that it is okay to use KeWaitForMutexObject or
KeWaitForSingleObject at DISPATCH_LEVEL if a timeout of 0 is specified.

This goes fine, however when I put on Driver Verifier, I have to alter my
code to support the different IRQLs. I’m now acquiring my mutex in the
following routine:

void WaitForMutex(BOOLEAN fromDPC)
{
LARGE_INTEGER timeOut={0,0},*t;
if (fromDPC==TRUE) t=&timeOut; else t=NULL;
KeWaitForSingleObject(&MyMutex,Executive, KernelMode, FALSE, t);
}

It appears that the Driver Verifier won’t accept a timeout of NULL at
DISPATCH_LEVEL, but insists on an initialized variable containing 0 instead.

But this is not where the problems finishes. If I put on deadlock detection
in the verifier, these KeWaitForxxx functions sometimes fail just for the
fun of it, then the blue screen comes when trying to release a mutex which
was never acquired. This means I have to check the return values of these
KeWaitForxxx functions. However if I check the sample code from the DDK or
drivers written by the gurus they never check these return values.

The question is whether it is not silly to alter and compromise code which
is otherwise running perfectly well only to satisfy the verifier ?

Thanks,

Daniel in Resplendence


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

You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Well I’m not sure where the “static analysis” comes in, since driver
verifier is a set of addtional run-time checking built into the system.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Prokash Sinha” wrote in message news:xxxxx@ntdev…
> This sounds like a bonafied bug in a static analysis !!!
>
> What could the DV do, if I declare a variable, and set it to zero. It
would
> have to ply thru and find the value of a variable, if zero then let it
pass,
> otherwise raise a flag.
>
> This variable’s value can change anywhere !. So it is tough here !
>
> -prokash
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Daniel Terhell
> Sent: Thursday, March 11, 2004 4:02 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] using KeWaitForxxx properly with verifier
>
>
> Hi,
>
> In my driver I have to acquire a mutex in a routine which gets called both
> at PASSIVE_LEVEL as well as DISPATCH_LEVEL from a DPC routine.
> The DDK doc says that it is okay to use KeWaitForMutexObject or
> KeWaitForSingleObject at DISPATCH_LEVEL if a timeout of 0 is specified.
>
> This goes fine, however when I put on Driver Verifier, I have to alter my
> code to support the different IRQLs. I’m now acquiring my mutex in the
> following routine:
>
> void WaitForMutex(BOOLEAN fromDPC)
> {
> LARGE_INTEGER timeOut={0,0},*t;
> if (fromDPC==TRUE) t=&timeOut; else t=NULL;
> KeWaitForSingleObject(&MyMutex,Executive, KernelMode, FALSE, t);
> }
>
> It appears that the Driver Verifier won’t accept a timeout of NULL at
> DISPATCH_LEVEL, but insists on an initialized variable containing 0
instead.
>
> But this is not where the problems finishes. If I put on deadlock
detection
> in the verifier, these KeWaitForxxx functions sometimes fail just for the
> fun of it, then the blue screen comes when trying to release a mutex which
> was never acquired. This means I have to check the return values of these
> KeWaitForxxx functions. However if I check the sample code from the DDK or
> drivers written by the gurus they never check these return values.
>
> The question is whether it is not silly to alter and compromise code which
> is otherwise running perfectly well only to satisfy the verifier ?
>
>
> Thanks,
>
> Daniel in Resplendence
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>

I might be wrong !. But how does it do it ? My guess would be that it is
another instrumentation. Now w/o looking at the DDK header file, it sounds
like that KeWait*() is not a macro ( for example KdPrint() is ), if it were
a macro, and it dispatches to different real kernel routines (including
possibly null routine) based on the value
of the variable, then instrumentation takes only to the functions that are
just supposed to work at below DISPATCH level …

-prokash

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Don Burn
Sent: Thursday, March 11, 2004 7:09 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] using KeWaitForxxx properly with verifier

Well I’m not sure where the “static analysis” comes in, since driver
verifier is a set of addtional run-time checking built into the system.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Prokash Sinha” wrote in message news:xxxxx@ntdev…
> This sounds like a bonafied bug in a static analysis !!!
>
> What could the DV do, if I declare a variable, and set it to zero. It
would
> have to ply thru and find the value of a variable, if zero then let it
pass,
> otherwise raise a flag.
>
> This variable’s value can change anywhere !. So it is tough here !
>
> -prokash
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Daniel Terhell
> Sent: Thursday, March 11, 2004 4:02 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] using KeWaitForxxx properly with verifier
>
>
> Hi,
>
> In my driver I have to acquire a mutex in a routine which gets called both
> at PASSIVE_LEVEL as well as DISPATCH_LEVEL from a DPC routine.
> The DDK doc says that it is okay to use KeWaitForMutexObject or
> KeWaitForSingleObject at DISPATCH_LEVEL if a timeout of 0 is specified.
>
> This goes fine, however when I put on Driver Verifier, I have to alter my
> code to support the different IRQLs. I’m now acquiring my mutex in the
> following routine:
>
> void WaitForMutex(BOOLEAN fromDPC)
> {
> LARGE_INTEGER timeOut={0,0},*t;
> if (fromDPC==TRUE) t=&timeOut; else t=NULL;
> KeWaitForSingleObject(&MyMutex,Executive, KernelMode, FALSE, t);
> }
>
> It appears that the Driver Verifier won’t accept a timeout of NULL at
> DISPATCH_LEVEL, but insists on an initialized variable containing 0
instead.
>
> But this is not where the problems finishes. If I put on deadlock
detection
> in the verifier, these KeWaitForxxx functions sometimes fail just for the
> fun of it, then the blue screen comes when trying to release a mutex which
> was never acquired. This means I have to check the return values of these
> KeWaitForxxx functions. However if I check the sample code from the DDK or
> drivers written by the gurus they never check these return values.
>
> The question is whether it is not silly to alter and compromise code which
> is otherwise running perfectly well only to satisfy the verifier ?
>
>
> Thanks,
>
> Daniel in Resplendence
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>


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

You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Driver verifier works by overriding the kernel system call with a wrapper
that checks for particular scenarios that are common causes of bugs.

It also “messes” with the memory allocation such that when a memory region
is freed, it’s also de-allocated from the memory completely, so that if you
access the region, it’s guaranteed to page-fault, rather than the normal
method which uses a lazy method of only freeing memory when needed.

I believe Driver Verifier also takes into account IRQL changes, and forcibly
pages out any region that is pageable if it’s going to IRQL that doesn’t
support paging, to catch any problems with pageable memory being paged out
(which of course will only happen sometimes if you run without driver
verifier and have plenty of memory in the machine).

In short, it adds extra testing features to system calls.

Unfortunately, if you have code that frequently allocates and de-allocates
memory, driver verifier can be quite an addition in timing, compared to the
standard system call.

I personally use driver verifier once in a while, but I find it very useful
when testing new code that deals with memory allocations (as it usually
catches when you do bad things). For display drivers, that’s the most useful
things, IRP’s are very rare in display drivers, as is any variety of
synchronization calls (as GDI will enforce the synchronization whether you
want it or not).


Mats

-----Original Message-----
From: Prokash Sinha [mailto:xxxxx@garlic.com]
Sent: Thursday, March 11, 2004 3:25 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] using KeWaitForxxx properly with verifier

I might be wrong !. But how does it do it ? My guess would be
that it is
another instrumentation. Now w/o looking at the DDK header
file, it sounds
like that KeWait*() is not a macro ( for example KdPrint() is
), if it were
a macro, and it dispatches to different real kernel routines
(including
possibly null routine) based on the value
of the variable, then instrumentation takes only to the
functions that are
just supposed to work at below DISPATCH level …

-prokash

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Don Burn
Sent: Thursday, March 11, 2004 7:09 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] using KeWaitForxxx properly with verifier

Well I’m not sure where the “static analysis” comes in, since driver
verifier is a set of addtional run-time checking built into
the system.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Prokash Sinha” wrote in message
> news:xxxxx@ntdev…
> > This sounds like a bonafied bug in a static analysis !!!
> >
> > What could the DV do, if I declare a variable, and set it
> to zero. It
> would
> > have to ply thru and find the value of a variable, if zero
> then let it
> pass,
> > otherwise raise a flag.
> >
> > This variable’s value can change anywhere !. So it is tough here !
> >
> > -prokash
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of
> Daniel Terhell
> > Sent: Thursday, March 11, 2004 4:02 AM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] using KeWaitForxxx properly with verifier
> >
> >
> > Hi,
> >
> > In my driver I have to acquire a mutex in a routine which
> gets called both
> > at PASSIVE_LEVEL as well as DISPATCH_LEVEL from a DPC routine.
> > The DDK doc says that it is okay to use KeWaitForMutexObject or
> > KeWaitForSingleObject at DISPATCH_LEVEL if a timeout of 0
> is specified.
> >
> > This goes fine, however when I put on Driver Verifier, I
> have to alter my
> > code to support the different IRQLs. I’m now acquiring my
> mutex in the
> > following routine:
> >
> > void WaitForMutex(BOOLEAN fromDPC)
> > {
> > LARGE_INTEGER timeOut={0,0},*t;
> > if (fromDPC==TRUE) t=&timeOut; else t=NULL;
> > KeWaitForSingleObject(&MyMutex,Executive, KernelMode, FALSE, t);
> > }
> >
> > It appears that the Driver Verifier won’t accept a timeout
> of NULL at
> > DISPATCH_LEVEL, but insists on an initialized variable containing 0
> instead.
> >
> > But this is not where the problems finishes. If I put on deadlock
> detection
> > in the verifier, these KeWaitForxxx functions sometimes
> fail just for the
> > fun of it, then the blue screen comes when trying to
> release a mutex which
> > was never acquired. This means I have to check the return
> values of these
> > KeWaitForxxx functions. However if I check the sample code
> from the DDK or
> > drivers written by the gurus they never check these return values.
> >
> > The question is whether it is not silly to alter and
> compromise code which
> > is otherwise running perfectly well only to satisfy the verifier ?
> >
> >
> > Thanks,
> >
> > Daniel in Resplendence
> >
> >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@garlic.com
> > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> >
> >
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Huh?

Driver Verifier does NO static analysis. It consist of extra checking
code in the implementations of the WDM DDIs.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Prokash Sinha
Sent: Thursday, March 11, 2004 7:25 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] using KeWaitForxxx properly with verifier

I might be wrong !. But how does it do it ? My guess would be that it is
another instrumentation. Now w/o looking at the DDK header file, it
sounds
like that KeWait*() is not a macro ( for example KdPrint() is ), if it
were
a macro, and it dispatches to different real kernel routines (including
possibly null routine) based on the value
of the variable, then instrumentation takes only to the functions that
are
just supposed to work at below DISPATCH level …

-prokash

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Don Burn
Sent: Thursday, March 11, 2004 7:09 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] using KeWaitForxxx properly with verifier

Well I’m not sure where the “static analysis” comes in, since driver
verifier is a set of addtional run-time checking built into the system.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Prokash Sinha” wrote in message
news:xxxxx@ntdev…
> This sounds like a bonafied bug in a static analysis !!!
>
> What could the DV do, if I declare a variable, and set it to zero. It
would
> have to ply thru and find the value of a variable, if zero then let it
pass,
> otherwise raise a flag.
>
> This variable’s value can change anywhere !. So it is tough here !
>
> -prokash
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Daniel Terhell
> Sent: Thursday, March 11, 2004 4:02 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] using KeWaitForxxx properly with verifier
>
>
> Hi,
>
> In my driver I have to acquire a mutex in a routine which gets called
both
> at PASSIVE_LEVEL as well as DISPATCH_LEVEL from a DPC routine.
> The DDK doc says that it is okay to use KeWaitForMutexObject or
> KeWaitForSingleObject at DISPATCH_LEVEL if a timeout of 0 is
specified.
>
> This goes fine, however when I put on Driver Verifier, I have to alter
my
> code to support the different IRQLs. I’m now acquiring my mutex in the
> following routine:
>
> void WaitForMutex(BOOLEAN fromDPC)
> {
> LARGE_INTEGER timeOut={0,0},*t;
> if (fromDPC==TRUE) t=&timeOut; else t=NULL;
> KeWaitForSingleObject(&MyMutex,Executive, KernelMode, FALSE, t);
> }
>
> It appears that the Driver Verifier won’t accept a timeout of NULL at
> DISPATCH_LEVEL, but insists on an initialized variable containing 0
instead.
>
> But this is not where the problems finishes. If I put on deadlock
detection
> in the verifier, these KeWaitForxxx functions sometimes fail just for
the
> fun of it, then the blue screen comes when trying to release a mutex
which
> was never acquired. This means I have to check the return values of
these
> KeWaitForxxx functions. However if I check the sample code from the
DDK or
> drivers written by the gurus they never check these return values.
>
> The question is whether it is not silly to alter and compromise code
which
> is otherwise running perfectly well only to satisfy the verifier ?
>
>
> Thanks,
>
> Daniel in Resplendence
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>


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

You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Oh!, there is no denial that it is a very valueable tool. But we all face
the situation(s) like this that we call “afterthought”. The wrapper is
nothing but instrumentation, and if I could recall, those KeWait*() routines
first checks the current irql, and raise the flags before even go for stack
setup, invoking scheduler(dispatcher) etc…

My point was that, those routines are sort of coupled with the dispatch
levels
and that is where it is burfing…

-prokash

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@3Dlabs.com
Sent: Thursday, March 11, 2004 7:39 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] using KeWaitForxxx properly with verifier

Driver verifier works by overriding the kernel system call with a wrapper
that checks for particular scenarios that are common causes of bugs.

It also “messes” with the memory allocation such that when a memory region
is freed, it’s also de-allocated from the memory completely, so that if you
access the region, it’s guaranteed to page-fault, rather than the normal
method which uses a lazy method of only freeing memory when needed.

I believe Driver Verifier also takes into account IRQL changes, and forcibly
pages out any region that is pageable if it’s going to IRQL that doesn’t
support paging, to catch any problems with pageable memory being paged out
(which of course will only happen sometimes if you run without driver
verifier and have plenty of memory in the machine).

In short, it adds extra testing features to system calls.

Unfortunately, if you have code that frequently allocates and de-allocates
memory, driver verifier can be quite an addition in timing, compared to the
standard system call.

I personally use driver verifier once in a while, but I find it very useful
when testing new code that deals with memory allocations (as it usually
catches when you do bad things). For display drivers, that’s the most useful
things, IRP’s are very rare in display drivers, as is any variety of
synchronization calls (as GDI will enforce the synchronization whether you
want it or not).


Mats

-----Original Message-----
From: Prokash Sinha [mailto:xxxxx@garlic.com]
Sent: Thursday, March 11, 2004 3:25 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] using KeWaitForxxx properly with verifier

I might be wrong !. But how does it do it ? My guess would be
that it is
another instrumentation. Now w/o looking at the DDK header
file, it sounds
like that KeWait*() is not a macro ( for example KdPrint() is
), if it were
a macro, and it dispatches to different real kernel routines
(including
possibly null routine) based on the value
of the variable, then instrumentation takes only to the
functions that are
just supposed to work at below DISPATCH level …

-prokash

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Don Burn
Sent: Thursday, March 11, 2004 7:09 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] using KeWaitForxxx properly with verifier

Well I’m not sure where the “static analysis” comes in, since driver
verifier is a set of addtional run-time checking built into
the system.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Prokash Sinha” wrote in message
> news:xxxxx@ntdev…
> > This sounds like a bonafied bug in a static analysis !!!
> >
> > What could the DV do, if I declare a variable, and set it
> to zero. It
> would
> > have to ply thru and find the value of a variable, if zero
> then let it
> pass,
> > otherwise raise a flag.
> >
> > This variable’s value can change anywhere !. So it is tough here !
> >
> > -prokash
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of
> Daniel Terhell
> > Sent: Thursday, March 11, 2004 4:02 AM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] using KeWaitForxxx properly with verifier
> >
> >
> > Hi,
> >
> > In my driver I have to acquire a mutex in a routine which
> gets called both
> > at PASSIVE_LEVEL as well as DISPATCH_LEVEL from a DPC routine.
> > The DDK doc says that it is okay to use KeWaitForMutexObject or
> > KeWaitForSingleObject at DISPATCH_LEVEL if a timeout of 0
> is specified.
> >
> > This goes fine, however when I put on Driver Verifier, I
> have to alter my
> > code to support the different IRQLs. I’m now acquiring my
> mutex in the
> > following routine:
> >
> > void WaitForMutex(BOOLEAN fromDPC)
> > {
> > LARGE_INTEGER timeOut={0,0},*t;
> > if (fromDPC==TRUE) t=&timeOut; else t=NULL;
> > KeWaitForSingleObject(&MyMutex,Executive, KernelMode, FALSE, t);
> > }
> >
> > It appears that the Driver Verifier won’t accept a timeout
> of NULL at
> > DISPATCH_LEVEL, but insists on an initialized variable containing 0
> instead.
> >
> > But this is not where the problems finishes. If I put on deadlock
> detection
> > in the verifier, these KeWaitForxxx functions sometimes
> fail just for the
> > fun of it, then the blue screen comes when trying to
> release a mutex which
> > was never acquired. This means I have to check the return
> values of these
> > KeWaitForxxx functions. However if I check the sample code
> from the DDK or
> > drivers written by the gurus they never check these return values.
> >
> > The question is whether it is not silly to alter and
> compromise code which
> > is otherwise running perfectly well only to satisfy the verifier ?
> >
> >
> > Thanks,
> >
> > Daniel in Resplendence
> >
> >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@garlic.com
> > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> >
> >
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Does it really make sense to you, that passing zero wait should cause
driver verifier to raise a flag ?

Not to me !

-prokash

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Peter Wieland
Sent: Thursday, March 11, 2004 7:45 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] using KeWaitForxxx properly with verifier

Huh?

Driver Verifier does NO static analysis. It consist of extra checking
code in the implementations of the WDM DDIs.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Prokash Sinha
Sent: Thursday, March 11, 2004 7:25 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] using KeWaitForxxx properly with verifier

I might be wrong !. But how does it do it ? My guess would be that it is
another instrumentation. Now w/o looking at the DDK header file, it
sounds
like that KeWait*() is not a macro ( for example KdPrint() is ), if it
were
a macro, and it dispatches to different real kernel routines (including
possibly null routine) based on the value
of the variable, then instrumentation takes only to the functions that
are
just supposed to work at below DISPATCH level …

-prokash

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Don Burn
Sent: Thursday, March 11, 2004 7:09 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] using KeWaitForxxx properly with verifier

Well I’m not sure where the “static analysis” comes in, since driver
verifier is a set of addtional run-time checking built into the system.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Prokash Sinha” wrote in message
news:xxxxx@ntdev…
> This sounds like a bonafied bug in a static analysis !!!
>
> What could the DV do, if I declare a variable, and set it to zero. It
would
> have to ply thru and find the value of a variable, if zero then let it
pass,
> otherwise raise a flag.
>
> This variable’s value can change anywhere !. So it is tough here !
>
> -prokash
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Daniel Terhell
> Sent: Thursday, March 11, 2004 4:02 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] using KeWaitForxxx properly with verifier
>
>
> Hi,
>
> In my driver I have to acquire a mutex in a routine which gets called
both
> at PASSIVE_LEVEL as well as DISPATCH_LEVEL from a DPC routine.
> The DDK doc says that it is okay to use KeWaitForMutexObject or
> KeWaitForSingleObject at DISPATCH_LEVEL if a timeout of 0 is
specified.
>
> This goes fine, however when I put on Driver Verifier, I have to alter
my
> code to support the different IRQLs. I’m now acquiring my mutex in the
> following routine:
>
> void WaitForMutex(BOOLEAN fromDPC)
> {
> LARGE_INTEGER timeOut={0,0},*t;
> if (fromDPC==TRUE) t=&timeOut; else t=NULL;
> KeWaitForSingleObject(&MyMutex,Executive, KernelMode, FALSE, t);
> }
>
> It appears that the Driver Verifier won’t accept a timeout of NULL at
> DISPATCH_LEVEL, but insists on an initialized variable containing 0
instead.
>
> But this is not where the problems finishes. If I put on deadlock
detection
> in the verifier, these KeWaitForxxx functions sometimes fail just for
the
> fun of it, then the blue screen comes when trying to release a mutex
which
> was never acquired. This means I have to check the return values of
these
> KeWaitForxxx functions. However if I check the sample code from the
DDK or
> drivers written by the gurus they never check these return values.
>
> The question is whether it is not silly to alter and compromise code
which
> is otherwise running perfectly well only to satisfy the verifier ?
>
>
> Thanks,
>
> Daniel in Resplendence
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>


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

You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Well, if you prefer to spend your money $800 at a time, hey, more power to
you ! But it doesn’t take that many $800s to get up to the price of
DriverStudio.

As for the tool itself, consider that TrueCoverage is a binary coverage
tool: it acts on your real piece of code, not on a version of it that’s
doctored at compile time to explicitly support coverage. So, TrueCoverage
allows you to do coverage analysis on the real executable that’s going to be
shipping, it doesn’t need source code, and it can easily be performed by QA
people. TrueCoverage is, again, a binary coverage tool - it will take
advantage of symbols and source code if they’re available, but you don’t
need them.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Don Burn
Sent: Thursday, March 11, 2004 9:48 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] using KeWaitForxxx properly with verifier

See my step 2! Of course I use Ccover from http://www.bullseye.com/ but
then I never could justify the cost of DriverStudio for the few tools I
would use.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting

“Smith, Steve” wrote in message
news:xxxxx@ntdev…
> I would add to this cycle that you should use a code coverage tool during
> testing. Don’t rely on WHQL tests and DriverVerifier as complete QA
> testing. There could be untested code. You won’t really know unless you
> use a code coverage tool that shows you what lines of code have been
> executed.
>
> If, after running the WHQL tests and/or using DriverVerifier, only 75% of
> your code has been executed, then that’s 25% of code that could contain a
> serious bug. Wouldn’t you want to know the risk of shipping your driver?
> Wouldn’t you want to know which lines of code have been executed? Then
you
> alter your tests to execute those untested parts of the driver.
>
> Blindly testing with WHQL and DriverVerifier is good. Using a code
coverage
> tool with it is better.
>
> Sorry for the shameless plug = use TrueCoverage from Numega as a code
> coverage tool during testing.
>
> Steve Smith
> www.compuware.com\products\driverstudio
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Don Burn
> Sent: Thursday, March 11, 2004 9:30 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] using KeWaitForxxx properly with verifier
>
>
> Mark,
>
> I didn’t mean to imply you never used the production environment,
just
> that during development you take advantage of all the capabilities you
can.
> I find it foolish not to take advantage of the checked build’s additional
> debug output, and am uncomfortable with the mix and match approach of
> checked/free components beyond the ntoskrnl/hal checked and the rest of
the
> world free. I know potentially that verifier can mask a problem but have
> never seen it in practice. My cycle would be a little different than
yours:
>
> 1. Initial Driver Development
>
> Compile check build driver with /W4 (with some pragma’s around
> the DDK includes since the aren’t /W4 clean) and PreFast. Create INF file
> and run it through ChkInf on creation or change. Debug driver on a
checked
> build with driver verifier turned on. I also at times use the Call Usage
> Verifier, but not always since it can give annoying false positives.
NOTE:
> I consider anything from checked build or verifier to be a real bug.
>
> 2. Driver testing phase I
>
> I run the checked build driver with all the tests I can on the
> checked build with verifier with code coverage when available.
>
> 3. Driver testing phase II
>
> I run the free build driver with all the tests on free build,
> both uni-processor and multi-processor. Note: everything prior to this
was
> multi-processor.
>
> 4. Driver tuning
>
> I run performance test with profiling turned on to check for
hot
> spots.
>
> 5. WHQL submission
>
> Note: I am trying to run WHQL tests from step 2 on (actually
> sometime as part of development testing so step 1), unfortunately I have
> seen problems with WHQL on a checked build!
>
> Don
>
> “Roddy, Mark” wrote in message
news:xxxxx@ntdev…
> > Well perhaps you are overstating the case Don. The checked build and
> driver
> > verifier are important tools (esp. verifier,) but I disagree with your
> > statement that they should be constantly in use during development. In
> fact
> > both verifier and the checked build create artificial execution
> environments
> > that are quite different from the actual production environment.
> > Consequently you must, at some well defined point in the development
> cycle,
> > switch over to testing your driver against the production environment
> rather
> > than against the checked build or with verifier.
> >
> > The case for verifier can be better stated as: you aren’t going to pass
> whql
> > if DV and your driver are not compatible. Consequently, for any whql’d
> > driver, DV validation is a necessary step. Developers put off DV
> validation
> > until they need to whql at their and their company’s peril.
> >
> > I generally don’t care much for the checked OS. Mostly I put strong
> checking
> > into the checked versions of my drivers, and do not rely at all on the
> > verification in the checked build. At best I might move some components
> from
> > the checked build onto a test system to help diagnose a specific
problem,
> > but that is such a pain in the ass these days that quite frankly I can’t
> > remember the last time I resorted to this tactic.
> >
> > The development cycle is perhaps something like this:
> >
> > 1. checked driver unit testing optionally against the checked OS.
> >
> > 2. validation with verifier.
> >
> > 3. your checked driver integration testing against the production OS,
> > optionally with some checked OS components, and perhaps other related
> > checked drivers in development.
> >
> > 4. validation with verifier, preliminary whql testing.
> >
> > 5. your production driver system testing against the production OS and
> > production related components in development.
> >
> > 6. whql certification/signing.
> >
> >
> > =====================
> > Mark Roddy
> >
> >
> > > -----Original Message-----
> > > From: Don Burn [mailto:xxxxx@acm.org]
> > > Sent: Thursday, March 11, 2004 8:22 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: Re:[ntdev] using KeWaitForxxx properly with verifier
> > >
> > > Truly, a dumb question. Any rational developer will have
> > > verifier on during all the time of development. Most of the
> > > developers I respect have it on with a checked build!
> > >
> > > –
> > > Don Burn (MVP, Windows DDK)
> > > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > >
> > >
> > > “yatindra vaishnav” wrote in message
> > > news:xxxxx@ntdev…
> > > Hi Deniel,
> > > Simple Question Why u put Driver Verifier on ur driver? If
> > > you felt that
> > > there is a need to check with that and want to know more abt
> > > that then the
> > > results what you are getting shud be reactified according to the MS
> > > standard.
> > > .
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@stratus.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
>


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

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

Among other things, calling KeWaitForSingleObject with a NULL timeout is
equivalent to calling it for an infinite wait. This is illegal at
dispatch level since the thread cannot block and the verifier should be
throwing an error.

On the flip side - if you do a wait with any timeout you MUST check the
status value returned to see if you got the object. If there are
samples that do this incorrect please point them out so they can get
fixed. You can’t just assume that you’re going to be the one to acquire
the object and then blindly free it.

The answer to the original question is that the code you write was not
“functioning perfectly” given the problems you list. You had a serious
bug (blocking at DISPATCH_LEVEL) and then an insufficient fix for that
where you just assumed you would be the one to acquire the mutex. You
can surely choose not to fix these problems in your code, or to wave
them off by saying you’ve seen samples that also had bugs in them, but
I’d hate to have to explain that decision to someone using one of my
drivers.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Prokash Sinha
Sent: Thursday, March 11, 2004 7:53 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] using KeWaitForxxx properly with verifier

Oh!, there is no denial that it is a very valueable tool. But we all
face
the situation(s) like this that we call “afterthought”. The wrapper is
nothing but instrumentation, and if I could recall, those KeWait*()
routines
first checks the current irql, and raise the flags before even go for
stack
setup, invoking scheduler(dispatcher) etc…

My point was that, those routines are sort of coupled with the dispatch
levels
and that is where it is burfing…

-prokash

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@3Dlabs.com
Sent: Thursday, March 11, 2004 7:39 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] using KeWaitForxxx properly with verifier

Driver verifier works by overriding the kernel system call with a
wrapper
that checks for particular scenarios that are common causes of bugs.

It also “messes” with the memory allocation such that when a memory
region
is freed, it’s also de-allocated from the memory completely, so that if
you
access the region, it’s guaranteed to page-fault, rather than the normal
method which uses a lazy method of only freeing memory when needed.

I believe Driver Verifier also takes into account IRQL changes, and
forcibly
pages out any region that is pageable if it’s going to IRQL that doesn’t
support paging, to catch any problems with pageable memory being paged
out
(which of course will only happen sometimes if you run without driver
verifier and have plenty of memory in the machine).

In short, it adds extra testing features to system calls.

Unfortunately, if you have code that frequently allocates and
de-allocates
memory, driver verifier can be quite an addition in timing, compared to
the
standard system call.

I personally use driver verifier once in a while, but I find it very
useful
when testing new code that deals with memory allocations (as it usually
catches when you do bad things). For display drivers, that’s the most
useful
things, IRP’s are very rare in display drivers, as is any variety of
synchronization calls (as GDI will enforce the synchronization whether
you
want it or not).


Mats

-----Original Message-----
From: Prokash Sinha [mailto:xxxxx@garlic.com]
Sent: Thursday, March 11, 2004 3:25 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] using KeWaitForxxx properly with verifier

I might be wrong !. But how does it do it ? My guess would be
that it is
another instrumentation. Now w/o looking at the DDK header
file, it sounds
like that KeWait*() is not a macro ( for example KdPrint() is
), if it were
a macro, and it dispatches to different real kernel routines
(including
possibly null routine) based on the value
of the variable, then instrumentation takes only to the
functions that are
just supposed to work at below DISPATCH level …

-prokash

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Don Burn
Sent: Thursday, March 11, 2004 7:09 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] using KeWaitForxxx properly with verifier

Well I’m not sure where the “static analysis” comes in, since driver
verifier is a set of addtional run-time checking built into
the system.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Prokash Sinha” wrote in message
> news:xxxxx@ntdev…
> > This sounds like a bonafied bug in a static analysis !!!
> >
> > What could the DV do, if I declare a variable, and set it
> to zero. It
> would
> > have to ply thru and find the value of a variable, if zero
> then let it
> pass,
> > otherwise raise a flag.
> >
> > This variable’s value can change anywhere !. So it is tough here !
> >
> > -prokash
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of
> Daniel Terhell
> > Sent: Thursday, March 11, 2004 4:02 AM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] using KeWaitForxxx properly with verifier
> >
> >
> > Hi,
> >
> > In my driver I have to acquire a mutex in a routine which
> gets called both
> > at PASSIVE_LEVEL as well as DISPATCH_LEVEL from a DPC routine.
> > The DDK doc says that it is okay to use KeWaitForMutexObject or
> > KeWaitForSingleObject at DISPATCH_LEVEL if a timeout of 0
> is specified.
> >
> > This goes fine, however when I put on Driver Verifier, I
> have to alter my
> > code to support the different IRQLs. I’m now acquiring my
> mutex in the
> > following routine:
> >
> > void WaitForMutex(BOOLEAN fromDPC)
> > {
> > LARGE_INTEGER timeOut={0,0},*t;
> > if (fromDPC==TRUE) t=&timeOut; else t=NULL;
> > KeWaitForSingleObject(&MyMutex,Executive, KernelMode, FALSE, t);
> > }
> >
> > It appears that the Driver Verifier won’t accept a timeout
> of NULL at
> > DISPATCH_LEVEL, but insists on an initialized variable containing 0
> instead.
> >
> > But this is not where the problems finishes. If I put on deadlock
> detection
> > in the verifier, these KeWaitForxxx functions sometimes
> fail just for the
> > fun of it, then the blue screen comes when trying to
> release a mutex which
> > was never acquired. This means I have to check the return
> values of these
> > KeWaitForxxx functions. However if I check the sample code
> from the DDK or
> > drivers written by the gurus they never check these return values.
> >
> > The question is whether it is not silly to alter and
> compromise code which
> > is otherwise running perfectly well only to satisfy the verifier ?
> >
> >
> > Thanks,
> >
> > Daniel in Resplendence
> >
> >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@garlic.com
> > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> >
> >
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Then your definition and mine of what “instrumentation” means are different.

In my regular use of the term instrumentation would mean that some sort of
code is injected into my source code or my binary. This is how I interpret
instrumentation. I may be wrong…

Driver Verifier “instruments” the OS kernel routines so that they make
checks for not necesarily immediately fatal errors, or that the OS kernel
itself would have a hard time detecting.

It’s also interacting with the memory subsystem such that things that MAY be
paged out, is certainly paged out, for instance. This goes well beyond what
I’d expect from the traditional meaning of instrumentation.

But what the heck, as long as we understand that it’s a tool, it may help us
find bugs in certain scenarios, but it will it’s not the sole and only way
to avoid bugs…


Mats

-----Original Message-----
From: Prokash Sinha [mailto:xxxxx@garlic.com]
Sent: Thursday, March 11, 2004 3:53 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] using KeWaitForxxx properly with verifier

Oh!, there is no denial that it is a very valueable tool. But
we all face
the situation(s) like this that we call “afterthought”. The wrapper is
nothing but instrumentation, and if I could recall, those
KeWait*() routines
first checks the current irql, and raise the flags before
even go for stack
setup, invoking scheduler(dispatcher) etc…

My point was that, those routines are sort of coupled with
the dispatch
levels
and that is where it is burfing…

-prokash

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@3Dlabs.com
Sent: Thursday, March 11, 2004 7:39 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] using KeWaitForxxx properly with verifier

Driver verifier works by overriding the kernel system call
with a wrapper
that checks for particular scenarios that are common causes of bugs.

It also “messes” with the memory allocation such that when a
memory region
is freed, it’s also de-allocated from the memory completely,
so that if you
access the region, it’s guaranteed to page-fault, rather than
the normal
method which uses a lazy method of only freeing memory when needed.

I believe Driver Verifier also takes into account IRQL
changes, and forcibly
pages out any region that is pageable if it’s going to IRQL
that doesn’t
support paging, to catch any problems with pageable memory
being paged out
(which of course will only happen sometimes if you run without driver
verifier and have plenty of memory in the machine).

In short, it adds extra testing features to system calls.

Unfortunately, if you have code that frequently allocates and
de-allocates
memory, driver verifier can be quite an addition in timing,
compared to the
standard system call.

I personally use driver verifier once in a while, but I find
it very useful
when testing new code that deals with memory allocations (as
it usually
catches when you do bad things). For display drivers, that’s
the most useful
things, IRP’s are very rare in display drivers, as is any variety of
synchronization calls (as GDI will enforce the
synchronization whether you
want it or not).


Mats

> -----Original Message-----
> From: Prokash Sinha [mailto:xxxxx@garlic.com]
> Sent: Thursday, March 11, 2004 3:25 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] using KeWaitForxxx properly with verifier
>
>
> I might be wrong !. But how does it do it ? My guess would be
> that it is
> another instrumentation. Now w/o looking at the DDK header
> file, it sounds
> like that KeWait*() is not a macro ( for example KdPrint() is
> ), if it were
> a macro, and it dispatches to different real kernel routines
> (including
> possibly null routine) based on the value
> of the variable, then instrumentation takes only to the
> functions that are
> just supposed to work at below DISPATCH level …
>
> -prokash
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Don Burn
> Sent: Thursday, March 11, 2004 7:09 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] using KeWaitForxxx properly with verifier
>
>
> Well I’m not sure where the “static analysis” comes in, since driver
> verifier is a set of addtional run-time checking built into
> the system.
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
> “Prokash Sinha” wrote in message
> > news:xxxxx@ntdev…
> > > This sounds like a bonafied bug in a static analysis !!!
> > >
> > > What could the DV do, if I declare a variable, and set it
> > to zero. It
> > would
> > > have to ply thru and find the value of a variable, if zero
> > then let it
> > pass,
> > > otherwise raise a flag.
> > >
> > > This variable’s value can change anywhere !. So it is tough here !
> > >
> > > -prokash
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com]On Behalf Of
> > Daniel Terhell
> > > Sent: Thursday, March 11, 2004 4:02 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: [ntdev] using KeWaitForxxx properly with verifier
> > >
> > >
> > > Hi,
> > >
> > > In my driver I have to acquire a mutex in a routine which
> > gets called both
> > > at PASSIVE_LEVEL as well as DISPATCH_LEVEL from a DPC routine.
> > > The DDK doc says that it is okay to use KeWaitForMutexObject or
> > > KeWaitForSingleObject at DISPATCH_LEVEL if a timeout of 0
> > is specified.
> > >
> > > This goes fine, however when I put on Driver Verifier, I
> > have to alter my
> > > code to support the different IRQLs. I’m now acquiring my
> > mutex in the
> > > following routine:
> > >
> > > void WaitForMutex(BOOLEAN fromDPC)
> > > {
> > > LARGE_INTEGER timeOut={0,0},*t;
> > > if (fromDPC==TRUE) t=&timeOut; else t=NULL;
> > > KeWaitForSingleObject(&MyMutex,Executive, KernelMode,
> FALSE, t);
> > > }
> > >
> > > It appears that the Driver Verifier won’t accept a timeout
> > of NULL at
> > > DISPATCH_LEVEL, but insists on an initialized variable
> containing 0
> > instead.
> > >
> > > But this is not where the problems finishes. If I put on deadlock
> > detection
> > > in the verifier, these KeWaitForxxx functions sometimes
> > fail just for the
> > > fun of it, then the blue screen comes when trying to
> > release a mutex which
> > > was never acquired. This means I have to check the return
> > values of these
> > > KeWaitForxxx functions. However if I check the sample code
> > from the DDK or
> > > drivers written by the gurus they never check these return values.
> > >
> > > The question is whether it is not silly to alter and
> > compromise code which
> > > is otherwise running perfectly well only to satisfy the verifier ?
> > >
> > >
> > > Thanks,
> > >
> > > Daniel in Resplendence
> > >
> > >
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@garlic.com
> > > To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> > >
> > >
> > >
> > >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@garlic.com
> > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com