> Yet now my curiosity is aroused, what would actually happen if a
DISPATCH_LEVEL piece of driver code issued a call to KeWaitForSingleObject
with a NULL timeout pointer ? We know now that DriverVerifier barfs at it,
and maybe BoundsChecker should, too, but it’d still be good to know the
exact behavior of the OS in such an eventuality.
Having inadvertently done it in the past I can assure you that if a
wait is required the system bug checks.
From what I understand the ‘dispatcher’ runs when the IRQL drops from
DISPATCH_LEVEL or higher to PASSIVE_LEVEL or APC_LEVEL. The
‘dispatcher’ then picks a thread that is ready to run and is the highest
priority and oldest within identical priorities (rough description).
Calling one of the ‘wait’ requests, other than KeDelayExecutionThread()
has a thread ‘wait’ on some activity by another thread. Many IRPs and
system calls require the ability to wait for something to happen. So if
you call one of these at DISPATCH_LEVEL the wait cannot be done since
the thread that will satisfy the wait condition cannot be run by the
‘dispatcher’. I think the triple use of ‘dispatch’ is a problem when
trying to understand how the system works: 1) dispatch routine(s) in
drivers that process various IRPs, 2) the OS ‘dispatcher’ logic that
runs the thread that should be run next, 3) IRQL of DISPATCH_LEVEL. You
would almost think from the names that they are related, but only 2 & 3
have any relationship. One way to think about DISPATCH_LEVEL is that it
is really DONT_DO_DISPATCHING_OF_THREADS_LEVEL.
You cannot yield when at DISPATCH_LEVEL or higher and even APC_LEVEL has
some problems associated with it if you are trying to do some I/O such
as reading or writing to the hard drive. The correct way to handle
those cases is to schedule a ‘worker thread’ to process the request
from that point onward. With some of the power and PnP requests, even
that is not acceptable all the time. Read and understand Walter Oney’s
WDM 2nd Edition book and then this becomes easier. DriverWorks has a
good framework that can help someone write a driver, but it can have
problems if you don’t understand how the system works since you won’t
know what the limits may be for non-standard activities. The new
framework Microsoft is implementing should be another way to help
beginners and even more experienced programmers get it correct, but I
think you will not be able to do things ‘outside the box’ unless you
understand how it all fits together. Documenting the things that can
and should be done in each piece of the driver’s code will be critical
to helping us get it correct, but as a general rule we all seem to avoid
the docs until we have problems.
It took Walter a long time to get his power/PnP logic working and he
provides it in a driver DLL so you can just use it or you can
incorporate the code within your driver if you prefer. Even Microsoft
has most of the PnP & power logic for DISK.SYS in the CLASSPNP.SYS
driver. It also provides these services to other drivers in the same
storage ‘class’ including tape and cdrom.
PC/SC uses SMCLIB.SYS as a driver DLL/miniport to keep SmartCard request
much simpler than if you had to implement the full ISO spec Too bad
that after all that work on PC/SC so little use is made of it in the
U.S.
“Ivan Bublikov” wrote in message
news:xxxxx@ntdev…
> Yes, the big picture of DISPATCH_LEVEL seems to be that whoever raises
the
> IRQL to that level effectively tells everybody (whoever he is going to
call
> afterwards, or the system dispatcher, or the virtual memory page-fault
> handler) that he can’t tolerate yielding the CPU to another thread. As
a
> consequence, if he mistakenly invokes some code that knows about
itself that
> it can yield, the code (if it is courteous enough) will immediately
point
> that out by bugchecking.
>
> Therefore, if it was you who raised to DISPATCH_LEVEL and you now want
to
> yield, just drop it back and then yield. If it was not you, but some
other
> guy you don’t know called you at DISPATCH_LEVEL, you can not yield,
because
> you would let that guy down.
>
> “Moreira, Alberto” wrote in message
> news:xxxxx@ntdev…
> > I don’t know. It looks to me like while a thread running at dispatch
level
> > cannot be preempted by anyone running at a lower level, that doesn’t
mean
> it
> > cannot voluntarily yield control by calling KeWaitForSingleObject:
when
> that
> > happens, the thread effectively leaves the ready state, and other
threads
> > will be running normally, even in the same processor. When the
object is
> > released, the dispatch level thread will get control back, and then
it
> won’t
> > be preemptable by anyone running at lower levels, but still, if it
again
> > waits on a busy mutex, it’s going to release control.
> >
> > Unless of course I misunderstand the nature of the WinNT dispatcher
?
> Which
> > is quite possible, every once in a while I learn something new about
the
> > system from NTDEV posters !
> >
> > Alberto.
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Peter Wieland
> > Sent: Thursday, March 11, 2004 12:04 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] using KeWaitForxxx properly with verifier
> >
> >
> > sorry
> >
> > add “at dispatch level” after “and is indeed invalid”.
> >
> > -p
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Moreira,
Alberto
> > Sent: Thursday, March 11, 2004 8:30 AM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] using KeWaitForxxx properly with verifier
> >
> > From the doc:
> >
> > ===================
> > 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.
> > ===================
> >
> > The parameter is optional, hence it should probably be quite ok to
pass
> > a NULL value on that pointer ? And notice the semantic difference
> > between no timeout and a timeout of zero.
> >
> > Alberto.
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Peter Wieland
> > Sent: Thursday, March 11, 2004 11:23 AM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] using KeWaitForxxx properly with verifier
> >
> >
> > No, that wouldn’t make sense. That’s also not what the OP wrote.
> >
> > He wrote that passing a NULL pointer to the timeout value at
dispatch
> > level caused the verifier to raise an error. This is specifying no
> > timeout (not zero timeout) and is indeed invalid.
> >
> > If you want to do a zero timeout you need to pass in a pointer to a
> > LARGE_INTEGER value that contains 0.
> >
> > -p
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Prokash Sinha
> > Sent: Thursday, March 11, 2004 8:00 AM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] using KeWaitForxxx properly with verifier
> >
> > 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
> >
> >
> >
> >
> > —
> > 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@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@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@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.
> >
> >
>
>
Mats,
No you are not wrong. I just meant to say the samething as you meant. Lot of
time
I tend to think wrapper means compiletime, and insturmentation mean runtime
:). Hey
the otherday I was looking thru the Telecommunication and data communication
dictionary,
I mean the handbook, and it has hundred pages of definition. As I say I’ve
2K memory, so
you know…
-pro
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@3Dlabs.com
Sent: Thursday, March 11, 2004 8:24 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] using KeWaitForxxx properly with verifier
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 verifierOh!, 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 verifierDriver 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
—
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
> 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
In top-important code like my own AVL tree implementation, I used this
“doctoring” manually by inserting macros in any possibly path. Then tested up
to 100% coverage.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> from that point onward. With some of the power and PnP requests, even
that is not acceptable all the time. Read and understand Walter Oney’s
All PnP requests come in on PASSIVE_LEVEL.
As about power requests - you must never block in them, even if they come on
PASSIVE_LEVEL.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Hi Don,
This was not for you. It was jut to let the guy know that the significance of the Driver Verifier and not for any expert comments.
Good luck,
From: “Don Burn”
>Reply-To: “Windows System Software Devs Interest List”
>To: “Windows System Software Devs Interest List”
>Subject: Re:[ntdev] using KeWaitForxxx properly with verifier
>Date: Thu, 11 Mar 2004 08:22:24 -0500
>
>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@hotmail.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
Post Classifieds on MSN classifieds. Buy and Sell on MSN Classifieds.
“Don Burn” wrote in message news:xxxxx@ntdev…
> 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:
>
I agree with, and VERY strongly advocate, Don’s development cycle with three
small alterations:
1) Do your ALL your development testing on a system with the checked KERNEL
AND HAL (only) and with Driver Verifier enabled (see below). Personally, I
have no use at all for the full checked build – it’s too slow. Setting up
individual checked drivers that reside in the same stack as your driver can
also be extremely helpful.
2) When using Driver Verifier, turn on ALL the options EXCEPT low resource
simulation. Low resource simulation should be a separate activity.
3) I recommend building your driver at least once and running it with CUV
during testing. I have seen innumerable cases where CUV has found errors,
even in shipping drivers.
I can’t see any reason why a dev wouldn’t want to know about errors in their
driver as soon as possible. That’s the whole point of tools like Driver
Verifier – If ya’ just leave it enabled on your driver, it’ll catch all
sorts of shite that you might otherwise initially miss and later spend hours
tracking down. And starting in XP and forward, as long as you have a
debugger hooked up, Verifier won’t bugcheck when it finds an error (rather,
it’ll let you continue and ignore errors on which it would ordinarily
bugcheck).
Please don’t think even for a minute that Verifier is a tool that enforces
random Microsoft rules or that it’s only useful for WHQL preparation. Driver
Verifier only whines about things that are real problems (with the POSSIBLE
exception of the tests specifically labelled as “speculative”, obviously).
Personally, I would never ship a driver without testing it extensively on
the checked kernel and HAL. But I agree that’s a matter of personal
preference.
On the other hand, if you don’t test a driver (to which Driver Verifier
applies) with Driver Verifier enabled before you ship your driver, you are
being professionally negligent. Full stop.
Peter
OSR
Thanks, Peter, good stuff.
What’s the best way to get just the checked Kernel and HAL? Are their files
well-defined?
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Viscarola
Sent: Saturday, March 13, 2004 2:26 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] using KeWaitForxxx properly with verifier
“Don Burn” wrote in message news:xxxxx@ntdev…
> 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:
>
I agree with, and VERY strongly advocate, Don’s development cycle with three
small alterations:
1) Do your ALL your development testing on a system with the checked KERNEL
AND HAL (only) and with Driver Verifier enabled (see below). Personally, I
have no use at all for the full checked build – it’s too slow. Setting up
individual checked drivers that reside in the same stack as your driver can
also be extremely helpful.
2) When using Driver Verifier, turn on ALL the options EXCEPT low resource
simulation. Low resource simulation should be a separate activity.
3) I recommend building your driver at least once and running it with CUV
during testing. I have seen innumerable cases where CUV has found errors,
even in shipping drivers.
I can’t see any reason why a dev wouldn’t want to know about errors in their
driver as soon as possible. That’s the whole point of tools like Driver
Verifier – If ya’ just leave it enabled on your driver, it’ll catch all
sorts of shite that you might otherwise initially miss and later spend hours
tracking down. And starting in XP and forward, as long as you have a
debugger hooked up, Verifier won’t bugcheck when it finds an error (rather,
it’ll let you continue and ignore errors on which it would ordinarily
bugcheck).
Please don’t think even for a minute that Verifier is a tool that enforces
random Microsoft rules or that it’s only useful for WHQL preparation. Driver
Verifier only whines about things that are real problems (with the POSSIBLE
exception of the tests specifically labelled as “speculative”, obviously).
Personally, I would never ship a driver without testing it extensively on
the checked kernel and HAL. But I agree that’s a matter of personal
preference.
On the other hand, if you don’t test a driver (to which Driver Verifier
applies) with Driver Verifier enabled before you ship your driver, you are
being professionally negligent. Full stop.
Peter
OSR
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com
I generally have both versions of the OS installed, checked and free, for
the various flavors I am testing against. Then copy the checked kernel and
hal into the free system directory, call them something different so you
don’t overwrite the free versions. Then in your boot.ini specify a separate
startup line with the parameters which specify the checked kernel and hal.
This way you can selectively boot the different bases.
Refer to the doc’s on the boot.ini parameters for using different kernel and
hal modules.
Pete
Peter Scott
xxxxx@KernelDrivers.com
www.KernelDrivers.com
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-169944-
xxxxx@lists.osr.com] On Behalf Of Ken Cross
Sent: Saturday, March 13, 2004 9:48 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] using KeWaitForxxx properly with verifierThanks, Peter, good stuff.
What’s the best way to get just the checked Kernel and HAL? Are their
files
well-defined?Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Viscarola
Sent: Saturday, March 13, 2004 2:26 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] using KeWaitForxxx properly with verifier“Don Burn” wrote in message news:xxxxx@ntdev…
> > 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:
> >
>
> I agree with, and VERY strongly advocate, Don’s development cycle with
> three
> small alterations:
>
> 1) Do your ALL your development testing on a system with the checked
> KERNEL
> AND HAL (only) and with Driver Verifier enabled (see below). Personally,
> I
> have no use at all for the full checked build – it’s too slow. Setting
> up
> individual checked drivers that reside in the same stack as your driver
> can
> also be extremely helpful.
>
> 2) When using Driver Verifier, turn on ALL the options EXCEPT low resource
> simulation. Low resource simulation should be a separate activity.
>
> 3) I recommend building your driver at least once and running it with CUV
> during testing. I have seen innumerable cases where CUV has found errors,
> even in shipping drivers.
>
> I can’t see any reason why a dev wouldn’t want to know about errors in
> their
> driver as soon as possible. That’s the whole point of tools like Driver
> Verifier – If ya’ just leave it enabled on your driver, it’ll catch all
> sorts of shite that you might otherwise initially miss and later spend
> hours
> tracking down. And starting in XP and forward, as long as you have a
> debugger hooked up, Verifier won’t bugcheck when it finds an error
> (rather,
> it’ll let you continue and ignore errors on which it would ordinarily
> bugcheck).
>
> Please don’t think even for a minute that Verifier is a tool that enforces
> random Microsoft rules or that it’s only useful for WHQL preparation.
> Driver
> Verifier only whines about things that are real problems (with the
> POSSIBLE
> exception of the tests specifically labelled as “speculative”, obviously).
>
> Personally, I would never ship a driver without testing it extensively on
> the checked kernel and HAL. But I agree that’s a matter of personal
> preference.
>
> On the other hand, if you don’t test a driver (to which Driver Verifier
> applies) with Driver Verifier enabled before you ship your driver, you are
> being professionally negligent. Full stop.
>
> Peter
> OSR
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@comcast.net
> 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@kerneldrivers.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
Specifically the files are ntoskrnl.exe for the kernel and hal.dll for the
hal.
Pete
Peter Scott
xxxxx@KernelDrivers.com
www.KernelDrivers.com
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-169944-
xxxxx@lists.osr.com] On Behalf Of Ken Cross
Sent: Saturday, March 13, 2004 9:48 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] using KeWaitForxxx properly with verifierThanks, Peter, good stuff.
What’s the best way to get just the checked Kernel and HAL? Are their
files
well-defined?Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Viscarola
Sent: Saturday, March 13, 2004 2:26 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] using KeWaitForxxx properly with verifier“Don Burn” wrote in message news:xxxxx@ntdev…
> > 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:
> >
>
> I agree with, and VERY strongly advocate, Don’s development cycle with
> three
> small alterations:
>
> 1) Do your ALL your development testing on a system with the checked
> KERNEL
> AND HAL (only) and with Driver Verifier enabled (see below). Personally,
> I
> have no use at all for the full checked build – it’s too slow. Setting
> up
> individual checked drivers that reside in the same stack as your driver
> can
> also be extremely helpful.
>
> 2) When using Driver Verifier, turn on ALL the options EXCEPT low resource
> simulation. Low resource simulation should be a separate activity.
>
> 3) I recommend building your driver at least once and running it with CUV
> during testing. I have seen innumerable cases where CUV has found errors,
> even in shipping drivers.
>
> I can’t see any reason why a dev wouldn’t want to know about errors in
> their
> driver as soon as possible. That’s the whole point of tools like Driver
> Verifier – If ya’ just leave it enabled on your driver, it’ll catch all
> sorts of shite that you might otherwise initially miss and later spend
> hours
> tracking down. And starting in XP and forward, as long as you have a
> debugger hooked up, Verifier won’t bugcheck when it finds an error
> (rather,
> it’ll let you continue and ignore errors on which it would ordinarily
> bugcheck).
>
> Please don’t think even for a minute that Verifier is a tool that enforces
> random Microsoft rules or that it’s only useful for WHQL preparation.
> Driver
> Verifier only whines about things that are real problems (with the
> POSSIBLE
> exception of the tests specifically labelled as “speculative”, obviously).
>
> Personally, I would never ship a driver without testing it extensively on
> the checked kernel and HAL. But I agree that’s a matter of personal
> preference.
>
> On the other hand, if you don’t test a driver (to which Driver Verifier
> applies) with Driver Verifier enabled before you ship your driver, you are
> being professionally negligent. Full stop.
>
> Peter
> OSR
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@comcast.net
> 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@kerneldrivers.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
That is what they are after the install. Before, they may have varying
names depending on the machine type.
Loren
Specifically the files are ntoskrnl.exe for the kernel and hal.dll for the
hal.
There is expand utility that comes with the checked build, that you can
use get those two kernel files expaned. As usual there is an excellent
article in Nt Insider ( though you might have to track to get, that explains
it all. From the osronline you should be able to get it. there might also be
a MS KB article(s). Once you have those file(s) expanded to your private
directory, you can do the rest to configure it…
-pro
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Ken Cross
Sent: Saturday, March 13, 2004 11:48 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] using KeWaitForxxx properly with verifier
Thanks, Peter, good stuff.
What’s the best way to get just the checked Kernel and HAL? Are their files
well-defined?
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Viscarola
Sent: Saturday, March 13, 2004 2:26 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] using KeWaitForxxx properly with verifier
“Don Burn” wrote in message news:xxxxx@ntdev…
> 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:
>
I agree with, and VERY strongly advocate, Don’s development cycle with three
small alterations:
1) Do your ALL your development testing on a system with the checked KERNEL
AND HAL (only) and with Driver Verifier enabled (see below). Personally, I
have no use at all for the full checked build – it’s too slow. Setting up
individual checked drivers that reside in the same stack as your driver can
also be extremely helpful.
2) When using Driver Verifier, turn on ALL the options EXCEPT low resource
simulation. Low resource simulation should be a separate activity.
3) I recommend building your driver at least once and running it with CUV
during testing. I have seen innumerable cases where CUV has found errors,
even in shipping drivers.
I can’t see any reason why a dev wouldn’t want to know about errors in their
driver as soon as possible. That’s the whole point of tools like Driver
Verifier – If ya’ just leave it enabled on your driver, it’ll catch all
sorts of shite that you might otherwise initially miss and later spend hours
tracking down. And starting in XP and forward, as long as you have a
debugger hooked up, Verifier won’t bugcheck when it finds an error (rather,
it’ll let you continue and ignore errors on which it would ordinarily
bugcheck).
Please don’t think even for a minute that Verifier is a tool that enforces
random Microsoft rules or that it’s only useful for WHQL preparation. Driver
Verifier only whines about things that are real problems (with the POSSIBLE
exception of the tests specifically labelled as “speculative”, obviously).
Personally, I would never ship a driver without testing it extensively on
the checked kernel and HAL. But I agree that’s a matter of personal
preference.
On the other hand, if you don’t test a driver (to which Driver Verifier
applies) with Driver Verifier enabled before you ship your driver, you are
being professionally negligent. Full stop.
Peter
OSR
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@comcast.net
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
> Please don’t think even for a minute that Verifier is a tool that enforces
random Microsoft rules or that it’s only useful for WHQL preparation. Driver
Agree completely. It catches a lot of bugs with memory accesses beyound the
allocated block, IRP mishandling (including the power IRPs), and so on.
In fact, it contains the most of BoundsChecker functionality for free.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
It is just a personal thought, nothing technical within the bounds of this
list, so pls don’t let it catch a fire :-).
Everything is fine and dandy, except the free. I dont think, it is free,
and most of us dont know “What is the
meaning of Price of goods”. Cost of goods are easily calculable, not the
price. This is really the domain of Micro and
Macro Economics.
So it would be nice, if we just go for a tecnical evaluation, product A does
this this and this, product B does that that and
those. And completely stay out of the business of price.
-pro
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Sunday, March 14, 2004 1:20 AM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] using KeWaitForxxx properly with verifier
Please don’t think even for a minute that Verifier is a tool that enforces
random Microsoft rules or that it’s only useful for WHQL preparation.
Driver
Agree completely. It catches a lot of bugs with memory accesses beyound the
allocated block, IRP mishandling (including the power IRPs), and so on.
In fact, it contains the most of BoundsChecker functionality for free.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.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
> Everything is fine and dandy, except the free. I dont think, it is free,
Driver Verifier is included in Windows. Even not in the DDK.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Sorry, I can’t agree with this. While in this case bound checker is
relatively low price, it is still expensive enough for me to have decided
it’s cost vs benfit ratio was too low. But lets take a more extreme case,
years ago I had the opportunity to use an incredibily powerful compiler with
all kinds of intelligent checking. You could dump a programming project in
and it would find hundreds of bugs that normally would require many days of
debugging. By your criteria I should have worried that in the late 80’s the
compiler and the machine to run it on cost a low 3.5 million dollars per
developer!
–
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…
> It is just a personal thought, nothing technical within the bounds of this
> list, so pls don’t let it catch a fire :-).
>
> Everything is fine and dandy, except the free. I dont think, it is free,
> and most of us dont know “What is the
> meaning of Price of goods”. Cost of goods are easily calculable, not the
> price. This is really the domain of Micro and
> Macro Economics.
>
> So it would be nice, if we just go for a tecnical evaluation, product A
does
> this this and this, product B does that that and
> those. And completely stay out of the business of price.
>
> -pro
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
> Sent: Sunday, March 14, 2004 1:20 AM
> To: Windows System Software Devs Interest List
> Subject: Re: Re:[ntdev] using KeWaitForxxx properly with verifier
>
>
> > Please don’t think even for a minute that Verifier is a tool that
enforces
> > random Microsoft rules or that it’s only useful for WHQL preparation.
> Driver
>
> Agree completely. It catches a lot of bugs with memory accesses beyound
the
> allocated block, IRP mishandling (including the power IRPs), and so on.
>
> In fact, it contains the most of BoundsChecker functionality for free.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.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, I did not mean thatway. Probably the samething people from the linux
world would say, heck for my purpose Linux is free, and windows aren’t. Then
there
would be some like me, and will say no nothing is free.
There are plenty of examples about freeness —
My point is that for a company like MS, lot of infrastructure could be free.
Couple years ago, Bill gates even touted think about the days when
“Bandwidth for telcos, and data are free”. Hey, that would be really great,
but please dont comeback and say BTW, you will have to buy the services from
us, and probably you would hardly have any choice(s)
In the area of personal computing, when it comes to software, Microsoft can
make almost anything free, but not everything free. And dont think it is
just for MS, any big cos (IBM, ATT) have the same history.
To me nothing is free. It’s this word free does not make anysense to me.
Sure it’s upto the people who deals with their day2day development to choose
between different tools, sw, etc., etc based on their budget(s), ways of
calcualting development cost(s) and what not after weighing all the factors
they can think of.
-prokash
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Don Burn
Sent: Sunday, March 14, 2004 9:19 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:using KeWaitForxxx properly with verifier
Sorry, I can’t agree with this. While in this case bound checker is
relatively low price, it is still expensive enough for me to have decided
it’s cost vs benfit ratio was too low. But lets take a more extreme case,
years ago I had the opportunity to use an incredibily powerful compiler with
all kinds of intelligent checking. You could dump a programming project in
and it would find hundreds of bugs that normally would require many days of
debugging. By your criteria I should have worried that in the late 80’s the
compiler and the machine to run it on cost a low 3.5 million dollars per
developer!
–
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…
> It is just a personal thought, nothing technical within the bounds of this
> list, so pls don’t let it catch a fire :-).
>
> Everything is fine and dandy, except the free. I dont think, it is free,
> and most of us dont know “What is the
> meaning of Price of goods”. Cost of goods are easily calculable, not the
> price. This is really the domain of Micro and
> Macro Economics.
>
> So it would be nice, if we just go for a tecnical evaluation, product A
does
> this this and this, product B does that that and
> those. And completely stay out of the business of price.
>
> -pro
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
> Sent: Sunday, March 14, 2004 1:20 AM
> To: Windows System Software Devs Interest List
> Subject: Re: Re:[ntdev] using KeWaitForxxx properly with verifier
>
>
> > Please don’t think even for a minute that Verifier is a tool that
enforces
> > random Microsoft rules or that it’s only useful for WHQL preparation.
> Driver
>
> Agree completely. It catches a lot of bugs with memory accesses beyound
the
> allocated block, IRP mishandling (including the power IRPs), and so on.
>
> In fact, it contains the most of BoundsChecker functionality for free.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.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@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
>
- Do your ALL your development testing on a system with the
checked KERNEL AND HAL (only) and with Driver Verifier
enabled (see below). Personally, I have no use at all for
the full checked build – it’s too slow. Setting up
individual checked drivers that reside in the same stack as
your driver can also be extremely helpful.
That really depends on what you mean by ‘development testing’. If you mean
‘unit testing’ then I have no argument.
As I said earlier in this thread, you really should not use either DV or
checked kernels throughout all of the development process as they are not
part of the production platform. At some point in your integration test
phase you really should convert over to no checked anythings, and certainly
your system test phase must be strictly using a production environment. DV
testing, for similar reasons, certainly ought to be exit/entrance criteria
for both integration/system test, but cannot be part of the standard
execution environment in your system test phase.
Please don’t think even for a minute that Verifier is a tool
that enforces random Microsoft rules or that it’s only useful
for WHQL preparation. Driver Verifier only whines about
things that are real problems (with the POSSIBLE exception of
the tests specifically labelled as “speculative”, obviously).
I don’t know if this was in response to what I said about DV and WHQL. My
point was that whatever you think of the merits of DV, you aren’t going to
get through WHQL without it, so if you are going to WHQL your product you
are going to test with DV and you should do this sooner rather than later
and you better build DV testing and repair into your schedule.
Yes but …
Driver Verifier is a must, unless you’re at the point where you want to
smoke test release code and get some timing information. As to the checked
builds of the kernel and HAL — they are not always available. Case in
point, the current version of XP I am using is SP2 Beta, build 2082 (the
last one offered for down load). I kinna find the checked builds for that
one laddie. No, I cannot go back to XP gold or even SP1, since the driver I
am working on depends upon ATAPI fixes that exist only for SP2. Even the
hot- I have talked about here does not have the latest fixes found in SP2
Beta.
Now it certainly would be nice if certain people who have the ears of
certain developers, would let those developers know that a drop of the beta
kernel and hal checked builds would be really really nice. It may be that
these critters are available and they simply disappeared in my trifocal
cracks when I was looking for them.
–
Gary G. Little
Seagate Technologies, LLC
“Peter Viscarola” wrote in message news:xxxxx@ntdev…
>
> “Don Burn” wrote in message news:xxxxx@ntdev…
> > 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:
> >
>
> I agree with, and VERY strongly advocate, Don’s development cycle with
three
> small alterations:
>
> 1) Do your ALL your development testing on a system with the checked
KERNEL
> AND HAL (only) and with Driver Verifier enabled (see below). Personally,
I
> have no use at all for the full checked build – it’s too slow. Setting
up
> individual checked drivers that reside in the same stack as your driver
can
> also be extremely helpful.
>
> 2) When using Driver Verifier, turn on ALL the options EXCEPT low resource
> simulation. Low resource simulation should be a separate activity.
>
> 3) I recommend building your driver at least once and running it with CUV
> during testing. I have seen innumerable cases where CUV has found errors,
> even in shipping drivers.
>
> I can’t see any reason why a dev wouldn’t want to know about errors in
their
> driver as soon as possible. That’s the whole point of tools like Driver
> Verifier – If ya’ just leave it enabled on your driver, it’ll catch all
> sorts of shite that you might otherwise initially miss and later spend
hours
> tracking down. And starting in XP and forward, as long as you have a
> debugger hooked up, Verifier won’t bugcheck when it finds an error
(rather,
> it’ll let you continue and ignore errors on which it would ordinarily
> bugcheck).
>
> Please don’t think even for a minute that Verifier is a tool that enforces
> random Microsoft rules or that it’s only useful for WHQL preparation.
Driver
> Verifier only whines about things that are real problems (with the
POSSIBLE
> exception of the tests specifically labelled as “speculative”, obviously).
>
> Personally, I would never ship a driver without testing it extensively on
> the checked kernel and HAL. But I agree that’s a matter of personal
> preference.
>
> On the other hand, if you don’t test a driver (to which Driver Verifier
> applies) with Driver Verifier enabled before you ship your driver, you are
> being professionally negligent. Full stop.
>
> Peter
> OSR
>
>
>
>
>
I concur with Peter’s tuning’s to my method and actually do these already
(though I find for much of my testing the full checked build is not a major
pain and is easier than getting the right collection of drivers).
On the checked build and beta’s two things people should be aware of:
In the latest DDK beta, Microsoft shipped the checked HAL and NTOS with the
DDK. Now this only applies to the build number the DDK matches but is
better than nothing.
If don’t like the lack of Checked Builds in Beta’s file a bug report! I
always do and the answer I get back is there aren’t enough people
complaining to justify it. So start complaining, and maybe we can fix this!
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
“Gary G. Little” wrote in message
news:xxxxx@ntdev…
> Yes but …
>
> Driver Verifier is a must, unless you’re at the point where you want to
> smoke test release code and get some timing information. As to the checked
> builds of the kernel and HAL — they are not always available. Case in
> point, the current version of XP I am using is SP2 Beta, build 2082 (the
> last one offered for down load). I kinna find the checked builds for that
> one laddie. No, I cannot go back to XP gold or even SP1, since the driver
I
> am working on depends upon ATAPI fixes that exist only for SP2. Even the
> hot- I have talked about here does not have the latest fixes found in SP2
> Beta.
>
> Now it certainly would be nice if certain people who have the ears of
> certain developers, would let those developers know that a drop of the
beta
> kernel and hal checked builds would be really really nice. It may be that
> these critters are available and they simply disappeared in my trifocal
> cracks when I was looking for them.
>
> –
> Gary G. Little
> Seagate Technologies, LLC
>
> “Peter Viscarola” wrote in message news:xxxxx@ntdev…
> >
> > “Don Burn” wrote in message news:xxxxx@ntdev…
> > > 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:
> > >
> >
> > I agree with, and VERY strongly advocate, Don’s development cycle with
> three
> > small alterations:
> >
> > 1) Do your ALL your development testing on a system with the checked
> KERNEL
> > AND HAL (only) and with Driver Verifier enabled (see below).
Personally,
> I
> > have no use at all for the full checked build – it’s too slow. Setting
> up
> > individual checked drivers that reside in the same stack as your driver
> can
> > also be extremely helpful.
> >
> > 2) When using Driver Verifier, turn on ALL the options EXCEPT low
resource
> > simulation. Low resource simulation should be a separate activity.
> >
> > 3) I recommend building your driver at least once and running it with
CUV
> > during testing. I have seen innumerable cases where CUV has found
errors,
> > even in shipping drivers.
> >
> > I can’t see any reason why a dev wouldn’t want to know about errors in
> their
> > driver as soon as possible. That’s the whole point of tools like Driver
> > Verifier – If ya’ just leave it enabled on your driver, it’ll catch all
> > sorts of shite that you might otherwise initially miss and later spend
> hours
> > tracking down. And starting in XP and forward, as long as you have a
> > debugger hooked up, Verifier won’t bugcheck when it finds an error
> (rather,
> > it’ll let you continue and ignore errors on which it would ordinarily
> > bugcheck).
> >
> > Please don’t think even for a minute that Verifier is a tool that
enforces
> > random Microsoft rules or that it’s only useful for WHQL preparation.
> Driver
> > Verifier only whines about things that are real problems (with the
> POSSIBLE
> > exception of the tests specifically labelled as “speculative”,
obviously).
> >
> > Personally, I would never ship a driver without testing it extensively
on
> > the checked kernel and HAL. But I agree that’s a matter of personal
> > preference.
> >
> > On the other hand, if you don’t test a driver (to which Driver Verifier
> > applies) with Driver Verifier enabled before you ship your driver, you
are
> > being professionally negligent. Full stop.
> >
> > Peter
> > OSR
> >
> >
> >
> >
> >
>
>
>