I don’t know how many of you noticed that on XP when you enable your
driver under verifier, a filter driver gets inserted every where (above
and below your function and filter device objects) in the stack to do
some more sanity checking. In some cases (don’t know the details) the
verifier changes the STATUS_SUCCESS value to flush out following bugs:
-
To catch lack of NT_SUCCESS(status) checks in drivers. Many PnP IRPs
(like IRP_MN_QUERY_STOP) have multiple success codes. So you should
always use this macro to check for success.
-
To catch broken IRP code such as:
Irp->IoStatus.Status = STATUS_SUCCESS;
IoCallDriver(…);
return STATUS_SUCCESS;
It is definitely a confusing that the verifier uses 1,2,3,…
(STATUS_WAIT_1, STATUS_WAIT_2, …) as status values instead of
something more straight-forward like STATUS_VERIFIER_SUCCESS_1, etc. 
I will make sure that this gets documented in the DDK.
-Eliyas
-----Original Message-----
From: Montalvo, Robinson [mailto:xxxxx@virata.com]
Sent: Friday, July 20, 2001 11:29 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Question about XP RC1 w/verifier ON
Michal,
I am very glad you brought up this point. I am also interested
in hearing the response to that question as I have also been
looking for the answer to it myself.
Regards,
Rob
-----Original Message-----
From: Michal Vodicka [mailto:xxxxx@veridicom.cz.nospam]
Sent: Friday, July 20, 2001 1:32 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Question about XP RC1 w/verifier ON
Gary,
do you want to say returing STATUS_WAIT_2 from IoCallDriver is correct
thing? I believed that status should give caller some meaningful info
about
result of requested operation; what does this status mean? From
ntstatus.h:
// The success status codes 0 - 63 are reserved for wait completion
status.
NT_SUCCESS macro just check if the severity of the status isn’t error or
warning. Right, it should be the first thing which caller test but next
it
should test real status code at least for pending status. How it should
handle such nonsense? Quietly ignore? I’m just confused and haven’t
found
anything about NT_SUCCESS macro in the docs (searching XP DDK on OSR
site).
Best regards,
Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.com]
From: Gary G. Little[SMTP:xxxxx@inland.net]
Reply To: NT Developers Interest List
Sent: Friday, July 20, 2001 9:27 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Question about XP RC1 w/verifier ON
In other words, the proper way to test for a successful completion is
to
use
the NT_SUCCESS macro provided by the DDK. Verifier tests for proper
handling
of successful but non 0 status. A 2 is a successful status, and you
never
know when someone might inject themselves below you and return such.
Gary
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@interactivesi.com
Sent: Friday, July 20, 2001 12:38 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Question about XP RC1 w/verifier ON
This is the expected behaviour of driver verifier. Suppose there was a
filter driver below your driver that was returning some status code
that
was actually successful but not STATUS_SUCCESS – does your driver
deal
with this situation correctly? This is what driver verifier is trying
to
catch. A lot of people check only for STATUS_SUCCESS instead of
NT_SUCCESS() which is incorrect.
-jordan
On 07/19/01, ““Montalvo, Robinson” ” wrote:
> > Tim and Gary,
> >
> > Thank you for the insight.
> >
> > Unfortunately, that does not seem to be the problem.
> > In fact, the problem becomes evident ONLY when
> > driver verifier is enabled. I don’t know if I have
> > made this clear, but, just to make sure, I don’t get
> > bugchecked or any messages at all. The system seems
> > to be happy but I certainly I’m not since our bus
> > driver never creates the PDOs it needs to create to
> > cause the system to load the function drivers for
> > the corresponding ports.
> >
> > I am in the process of opening a problem report with
> > MS on this issue. It may be that our implementation
> > has a very subtle bug in it and we are just seeing
> > the effects of that. Unfortunately (or fortunately),
> > the same code works fine on Win2K, Win 98SE, ME and
> > even on XP RC1, as long as I don’t enable driver
> > verifier against it.
> >
> > Any more thoughts/ideas are always welcome.
> >
> > Regards,
> > Rob
> >
>
> —
> You are currently subscribed to ntdev as: xxxxx@inland.net
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rkk.cz
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
—
You are currently subscribed to ntdev as: xxxxx@virata.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
