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