I can say from personal experience that this can hose you…It’s been a
while since I’ve been bitten by this, but this is the reasoning to the best
of my recollection (and someone will fill in the holes if I miss something,
this list is usually pretty good at that :))
When you open non-overlapped, you (duh) get synchronous I/O. This causes the
I/O manager to do all kinds of extra things, two of which are interesting:
-
He takes out a per-file object lock before dispatching operations against
your handle
-
More importantly, he signals the completion of the I/O operation via an
event in the file object. There’s only ever going to be one I/O operation at
a time against the handle, so he can leverage the file object to signal
completion.
Now, compare this to the overlapped case. In the overlapped case, the file
object is not locked across the dispatch *and* it is assumed that your
application is supplying the event for the I/O operation, so the I/O manager
will signal the completion of the operation via that event…
The hosing then happens because by doing what you suggest you confuse the
I/O manager in KM and the Win32 subsystem in UM when you mix and match.
You open the file overlapped, so you have an asynchronous file object in KM.
Then you do your DeviceIoControl. Win32 determines if you’ve opened the file
for overlapped or not by the presense of the overlapped structure (why
bother tracking all handles in your process and how you opened them?). If
the overlapped structure is present, this is an overlapped handle and he
hucks the device control and returns.
If the structure is *not* present, then this means to Win32 that you’ve
opened a synchronous handle and completion is going to be signaled via the
file object. So, Win32 hucks the I/O and, if pending is returned, it then
*waits on the file handle*, 'cause that’s what is signalled for synchronous
I/O. Now you have the kernel and user parts of the O/S out of phase and bad
things can happen (in a multithreaded scenario I’ve managed to have the O/S
tell me that my I/O was complete even though it really wasn’t finished yet,
oops).
There are other details in there that will make it seem like it works most
of the time, like I said it’s been a while. But, this isn’t just a Win9x
issue, it’s an actual bug.
-scott
–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Thomas F. Divine” wrote in message
news:xxxxx@ntdev…
Thanks for the info.
Actually, I’m hoping someone who really knows will pipe up and answer.
IIRC, DeviceIoControl on 9X/ME would behave badly in the case I am
interested in, but I don’t think it is a problem on NT.
Any Microsoft guys want to comment on this?
Just want to know…
Thomas F. Divine
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-329773-
> xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
> Sent: Tuesday, July 08, 2008 9:44 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] DeviceIoControl, FILE_FLAG_OVERLAPPED and NULL
> lpOverlapped Question (I have the stupids today…)
>
> Thomas Divine wrote:
>
> > In reviewing a lot of WDK sample code I see quite a few examples
> > where a device handle is opened with FILE_FLAG_OVERLAPPED for
> > asynchronous I/O, but DeviceIoControl calls are made with
> > lpOverlapped being NULL.
>
> This came up awhile ago and actually spawned a huge flamewar when a
> noob posted that he wanted to “protect against people doing non-
> overlapped I/O to his driver” or something like that.
>
> If you’re calling into a driver, and the IRP is completed synchronously
> in the dispatch routine, I think you’ll see the success/failure value
> of the IRP as the return value of DeviceIoControl() even if
> lpOverlapped is NULL. Otherwise I don’t know what happens.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer