For a DeviceIoControl() issued on an overlapped handle, it is said that KMDF always marks the IRP pending and returns STATUS_PENDING, even if the driver routine completes the request synchronously. [Orwick & Smith, p. 259]
My question is this – Does this mean that such a call to DeviceIoControl() will NEVER return TRUE?
Tom wrote:
For a DeviceIoControl() issued on an overlapped handle, it
is said that KMDF always marks the IRP pending and returns
STATUS_PENDING, even if the driver routine completes the
request synchronously. [Orwick & Smith, p. 259]My question is this – Does this mean that such a call to
DeviceIoControl() will NEVER return TRUE?
Essentially yes, you’ll always get FALSE and GetLastError() of 997 / ERROR_IO_PENDING, unless you register a WDM IRP preprocess return and complete the IRP there. Note that this design decision has caused incompatibilities with some legacy code so watch out…
Chris is on target here, but please DO note his caveat:
So, it’s entirely possible for SOME KMDF driver, or a given revision of a KMDF driver, to synchronously complete a request sent on an overlapped handle.
When using an overlapped handle, applications should *not* be written to assume the request will be completed asynchronously. In other words, code to the interface contract not to the behavior of a given framework or driver… you need to handle ALL the cases.
Peter
OSR
Thanks, guys. I am trying to analyze existing user mode code to determine what possible paths it may take when interfacing with my existing KMDF driver. (Trying to come up with a scenario to explain a particular failure mode.)
I do know that the proper application coding technique is not to make these assumptions. This particular application code, it turns out, leaves a lot to be desired. The most glaring appears one level up in the hierarchy, where error conditions very carefully and *mostly* correctly analyzed at this level and returned in a return code, are never checked.
Thank you both for clarifying this issue.