Synchronous and asynchronous I/O

Hi,
What happens if you perform a synchronous I/O operation on a handle opened for asynchronous operation? In particular, what should happen if the following code is executed?

Code:

---

...
path_io="P:\\oints_to\\a_usb\\dev.ice"
...
handle = CreateFile(path_io,GENERIC_READ,0,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL|FILE_FLAG_OVERLAPPED,NULL);
...
if(!DeviceIoControl(handle,IOCTL_MCHPUSB_GET_DESCRIPTOR,&DscParam,sizeof(DscParam),pDevDsc,dwLen,pLength,NULL))
{
    printf("Get dsc error: %d",GetLastError());
    return MPUSB_FAIL;
}
...
CloseHandle(handle)
...

---

The things to note here are that handle is created with FILE_FLAG_OVERLAPPED, but then DeviceIoControl is called without passing an OVERLAPPED structure as the last parameter, signifying a synchronous operation.

At this point you might be wondering why on earth I would want to do that. Well, it's not my choice, it occurs inside a dll that I have to use (if I don't want to completely rewrite my code that is).

When I run this code, the DeviceIoControl function performs as required, despite the synchronisation issue. Yet, about half the time I get a blue screen error and have to reboot my computer before the program finishes. The details are:

Code:

---

0x000000CE
DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS

---

Can anyone explain what the code should do and whether it could even possibly be causing the blue screen of death?

My interpretation is that the DeviceIoControl function operates synchronously in this case and hence retrieves the required data immediately (explaining why the function still seems to work), but somehow the operation is still 'pending' because the handle is meant to operate asynchronously. This means that when CloseHandle is called, depending on how quick the in between code executes, the operation might still be pending. If it is, then the program would attempt to close a handle for which an async io is still pending. Could this possibly relate to the blue screen error?
One thing that supports my interpretation is that when I step through the program there is never a blue screen, only when I let it run freely do I get it.

Is my interpretation valid/possible/likely?? What do you think? What should happen if a synchronous operation is performed on an async handle? Anyone know?

Cheers,
Philipp

I suppose the operation is started asynchronously due to OVERLAPPED flag.

But because you do not provide the event handle - there is no way to know when it is finished

So some code tries to destruct memory actually used by driver for writing during IO operation - causing crash in driver...

Something like that I guess...
What I am interested in though is whether there is anything I can do to stop the blue screens because they are, to say the least, highly annoying!
To put the example in context, the first two lines are part of a function called MPUSBOpen, the DeviceIoControl call is part of another function called MPUSBGetDeviceDescriptor, and the CloseHandle statement is part of a function called MPUSBClose. These three functions are part of the dll and I cannot change what is in them, but it is up to me to call them from my own code, so I could potentially insert some statements where the ellipses ('...') are in the original code snippet I sent.
Is there anything I could try adding to resolve the blue screen?
Philipp

Quote:

---

If this is an overlapped operation, you can get the number of bytes returned by calling GetOverlappedResult. If hDevice is associated with an I/O completion port, you can get the number of bytes returned by calling GetQueuedCompletionStatus.

---

so you need to call one of this to be sure that operation if finished before closing handle...

or - call CancelIO before closing handle if you do not want to wait

I added a CancelIO statement just before the CloseHandle statement and have not been able to reproduce the blue screen since then. Not that I want it to happen (!) but I tried connecting then immediately disconnecting and things like that and there no longer seems to be a problem.
Thanks vart,
Philipp