Doron,
Well, I agree with you mostly. I am in the habit of looking for specific
return values *first* and then checking the return class with NT_SUCCESS().
In particular, when a routine *cannot* by architecture return STATUS_PENDING
(because it must be syncronous) I generally ASSERT(status !=
STATUS_PENDING). This fell into that category.
So I applaud verifier for shaking up the return codes to catch folks looking
for STATUS_SUCCESS instead of NT_SUCCESS() but changing it to STATUS_PENDING
just seems wrong since that really does mean something other than
STATUS_SUCCESS (in other quarters).
Also, I could be wrong on this (probably, I’m just a NDIS guy 
) but
setting IoStatus.Status to STATUS_PENDING is illegal, right? Doesn’t
verifier blow up if you do that?
Thanks for the feedback. I have already pulled the overly defensive code
out of the driver and will happily accept any NT_SUCCESS() result from that
routine.
-dave
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Friday, May 11, 2007 2:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WdfFdoQueryForInterface() -> STATUS_PENDING when
verifier is enabled?
You should never be checking for specific success codes, you should always
use NT_SUCCESS. This is part of what verifier is doing in that it changes
STATUS_SUCCESS to other codes (like 0x2).
In this particular APIs case, if the call to IoCallDriver returns
STATUS_PENDING, we wait on completion of the PIRP and then use the final
status in the IRP (Irp->IoStatus.Status), so if the API is returning
STATUS_PENDING, this is verifier doings, not a KMDF bug. Verifier does
inject pending statuses on various pnp irps as well to make sure that upper
drivers properly wait for completion of the I/O.
d
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Friday, May 11, 2007 10:46 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WdfFdoQueryForInterface() -> STATUS_PENDING when verifier
is enabled?
Is it reasonable that the behavior of WdfFdoQueryForInterface() would change
from returning STATUS_SUCCESS to STATUS_PENDING when Driver Verifier is
enabled (with I/O and Enhanced I/O validation)?
I have been trying to find a problem in *my* drivers but all I can come up
with is that when Verifier is enabled, this routine goes from returning
STATUS_SUCCESS to STATUS_PENDING.
As far as I know the WDM rules are that IRP_MN_QUERY_INTERFACE cannot be
queued and so perhaps KMDF is not doing the full measure of WDM-isms and
checking for STATUS_PENDING, waiting for completion (which would have
already occured), etc. Does Verifier have the behavior of forcing
STATUS_PENDING on IRPs?
I realize, of course, that I can just ignore this little oddity and use
NT_SUCCESS(status) which will also test true for STATUS_PENDING and that it
is probably OK to do so given that I know IRP_MN_QUERY_INTERFACE is inside
WdfFdoQueryForInterface() *and* that the rules are it completes
syncronously. Moreover, I am going to do that very thing but I feel icky
doing so. STATUS_PENDING may be a ‘success’ code, but it sure does not
mean ‘done’; it just means ‘not yet failed or suceeded’. The note in the
KMDF docs for this routine states that ‘other return values are possible’
but it surely says STATUS_SUCCESS for when it succeeds!
Known issue? By design? Keep looking for bug in my code?
Thanks,
-dave
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer