Personal: Wdm driver ioCalling Wdf driver looking for STATUS_SUCCE

if the WDF driver [callee] does WDFCompleteWithInfo(SUCCESS, . .)
why does WDM driver [caller] get STATUS_PENDING ? ? ?
tom

Eliyas
Fri Aug 24 09:11:00 CDT 2007

This is because framework always marks the IRP pending and returns
STATUS_PENDING even when the request is completed synchronously by the
driver. What is your concern?

-Eliyas

TomPicard
Fri Aug 24 09:26:03 CDT 2007

at dispatch level i want to call from km driver to wdf driver to, for
instance, just receive a simple variable update, i dont want to set up an
elaborate case where where i have to handle a status pending

"Eliyas Yakub [MSFT]" wrote:

> This is because framework always marks the IRP pending and returns
> STATUS_PENDING even when the request is completed synchronously by the
> driver. What is your concern?
>
> -Eliyas
>
>
>

Eliyas
Fri Aug 24 09:56:18 CDT 2007

When you send a request to the lower driver, you cannot make assumption that
it will always complete it synchronously with success or failure status?
Even if you own both the drivers and have control over the behavior, you
cannot make that assumption. What if I insert a filter and make the call
asynchronous? On Vista, to enforce this design, Verifier has a new setting
to forcefully pend requests and complete them asynchronously in a DPC. So
please write code to deal with it. If you need any assistance on how to
handle, post your code snippet, and folks on this forum can give you some
ideas.

--
- This posting is provided "AS IS" with no warranties, and confers no
rights.

TomPicard
Fri Aug 24 10:32:03 CDT 2007

i asked how to get wdf driver to return status _success,

if i would have wanted advice on how to iocalldriver at dispatch level i
would have asked that,

thanks
tom

"Eliyas Yakub [MSFT]" wrote:

> When you send a request to the lower driver, you cannot make assumption that
> it will always complete it synchronously with success or failure status?
> Even if you own both the drivers and have control over the behavior, you
> cannot make that assumption. What if I insert a filter and make the call
> asynchronous? On Vista, to enforce this design, Verifier has a new setting
> to forcefully pend requests and complete them asynchronously in a DPC. So
> please write code to deal with it. If you need any assistance on how to
> handle, post your code snippet, and folks on this forum can give you some
> ideas.
>
> --
> - This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
>

Walter
Fri Aug 24 11:11:02 CDT 2007

"Eliyas Yakub [MSFT]" wrote:
> When you send a request to the lower driver, you cannot make assumption that
> it will always complete it synchronously with success or failure status?

There are (or were, as of XP) two drivers for which that wasn't entirely
true. Serial drivers would complete an IRP_MJ_READ synchronously if the
timeouts were set just right, and people depended on that. In addition,
IFDTEST (the SmartCard reader test) assumed that the only IOCTLs that
would ever be pended were the card-tracking requests, and you failed the
test if you broke that rule.

Assuming that these two problems no longer exist with Vista and later
systems, doesn't this restrict the platforms on which you can deploy an
WDF driver?

--
Walter Oney, Consulting and Training
http://www.oneysoft.com

Doron
Fri Aug 24 13:02:59 CDT 2007

you can work around the issues with various WDM proprocess routines in your
kmdf driver, but yes, these assumptions come up from time to time and must
be dealt with individually

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Walter Oney" <waltoney@oneysoft.com> wrote in message
news:46CF0316.98E8BA5E@oneysoft.com...
> "Eliyas Yakub [MSFT]" wrote:
>> When you send a request to the lower driver, you cannot make assumption
>> that
>> it will always complete it synchronously with success or failure status?
>
> There are (or were, as of XP) two drivers for which that wasn't entirely
> true. Serial drivers would complete an IRP_MJ_READ synchronously if the
> timeouts were set just right, and people depended on that. In addition,
> IFDTEST (the SmartCard reader test) assumed that the only IOCTLs that
> would ever be pended were the card-tracking requests, and you failed the
> test if you broke that rule.
>
> Assuming that these two problems no longer exist with Vista and later
> systems, doesn't this restrict the platforms on which you can deploy an
> WDF driver?
>
> --
> Walter Oney, Consulting and Training
> http://www.oneysoft.com

Alexander
Fri Aug 24 23:03:44 CDT 2007

MScomm32.ocx was very surprised when my driver returned STATUS_PENDING on a
request that should have been satisfied immediately. It actually was, but
the dispatch function always returned STATUS_PENDING, to simplify logic.

"Walter Oney" <waltoney@oneysoft.com> wrote in message
news:46CF0316.98E8BA5E@oneysoft.com...
> "Eliyas Yakub [MSFT]" wrote:
>> When you send a request to the lower driver, you cannot make assumption
>> that
>> it will always complete it synchronously with success or failure status?
>
> There are (or were, as of XP) two drivers for which that wasn't entirely
> true. Serial drivers would complete an IRP_MJ_READ synchronously if the
> timeouts were set just right, and people depended on that. In addition,
> IFDTEST (the SmartCard reader test) assumed that the only IOCTLs that
> would ever be pended were the card-tracking requests, and you failed the
> test if you broke that rule.
>
> Assuming that these two problems no longer exist with Vista and later
> systems, doesn't this restrict the platforms on which you can deploy an
> WDF driver?
>
> --
> Walter Oney, Consulting and Training
> http://www.oneysoft.com

Eliyas
Sat Aug 25 00:56:25 CDT 2007

You have a point. As Doron pointed out, you have to register WDM preprocess
callback to process the IRP. You will not be able to use queues. For an
example, take a look at the serial sample. It uses preprocess callback for
create irps to work around a bug in serenum on downlevel systems.

-Eliyas