synchronous vs asynchronous DeviceIoControl calls

Hello all,

I’m writing user mode code that is meant to be platform compatible (Os
independant) so I try to minimize Windows specific constructs like
Overlapped IO. But of course, the code should compile and run under Windows.

I’m also writing a device driver for a USB device which will be called by
the mentioned user mode code.

In my user mode code, i have a notification thread to receive asynchoronous
events signaled by the driver.

These are my questions:

  1. If I do a Synchronous DeviceIoControl call (i.e. Ovelapped = NULL) to
    wait for the notification from the driver, is there a way to cancel this
    call? Can I call CloseHandle() from the main application thread to Cancel a
    pending synchronous DeviceIoControl?

  2. If I implement a IoctlDispatch routine in the driver, that would
    force-block in the dispatch routine without completing the Irp (not even
    with a STATUS_PENDING) could I cancel this wait by using another
    DeviceIoControl call, from the main application thread?

I guess that the right way to do this is using an asynchonous
DeviceIocontrol call with an Overlapped structure and its asscociated event,
and then using WaitForMultipleObjects to wait for the asynchonous driver
event and a ThreadTerminate event (as explained in Oney’s book) -but- as my
*user mode code* is meant to be as platform independent as possible i would
like to avoid this as the other operating systems I will use lacks the
overlapped and the WaitForMultipleObject features.

Advices welcome,
Thanks,
Nestor.

First, seperate your thoughts on the driver from the application. The
driver should support asynchronous I/O, this is good practice, and you
might find someone wanting to use it.

Now just because the driver does asynch doesn’t mean the application has
to. The OS will take care of pending the application thread and doing the
right thing. In fact because the driver does asynch and returns
STATUS_PENDING, you can use the CancelIo function to clear the pending.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

“Nestor Lopez” wrote in message
news:xxxxx@ntdev…
> Hello all,
>
> I’m writing user mode code that is meant to be platform compatible (Os
> independant) so I try to minimize Windows specific constructs like
> Overlapped IO. But of course, the code should compile and run under
> Windows.
>
> I’m also writing a device driver for a USB device which will be called by
> the mentioned user mode code.
>
> In my user mode code, i have a notification thread to receive
> asynchoronous events signaled by the driver.
>
> These are my questions:
>
> 1) If I do a Synchronous DeviceIoControl call (i.e. Ovelapped = NULL)
> to wait for the notification from the driver, is there a way to cancel
> this call? Can I call CloseHandle() from the main application thread to
> Cancel a pending synchronous DeviceIoControl?
>
> 2) If I implement a IoctlDispatch routine in the driver, that would
> force-block in the dispatch routine without completing the Irp (not even
> with a STATUS_PENDING) could I cancel this wait by using another
> DeviceIoControl call, from the main application thread?
>
> I guess that the right way to do this is using an asynchonous
> DeviceIocontrol call with an Overlapped structure and its asscociated
> event, and then using WaitForMultipleObjects to wait for the asynchonous
> driver event and a ThreadTerminate event (as explained in Oney’s
> book) -but- as my user mode code is meant to be as platform independent
> as possible i would like to avoid this as the other operating systems I
> will use lacks the overlapped and the WaitForMultipleObject features.
>
> Advices welcome,
> Thanks,
> Nestor.
>
>

> 1) If I do a Synchronous DeviceIoControl call (i.e. Ovelapped = NULL) to

wait for the notification from the driver, is there a way to cancel this
call? Can I call CloseHandle() from the main application thread to Cancel a
pending synchronous DeviceIoControl?

If the driver is written properly - then yes, the driver will cancel the IRPs
in the MJ_CLEANUP path.

  1. If I implement a IoctlDispatch routine in the driver, that would
    force-block in the dispatch routine without completing the Irp (not even
    with a STATUS_PENDING) could I cancel this wait by using another
    DeviceIoControl call, from the main application thread?

Never write such dispatch routines, pend the IRP with cancellation support
instead.

I guess that the right way to do this is using an asynchonous
DeviceIocontrol call with an Overlapped structure and its asscociated event,

Not necessary.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com