A driver can't have more then 1 IRP pending from a specific file handle?
For example, if I have a read IRP pending, I won't receive a IOCTL IRP (on
the same handle).

The requests are sent from a win32 application.

See the platform sdk concerning overlapped IO requests. If you have opened
the file handle for overlapped operations you can have any number of
read/write/ioctl requests in progress associated with the file handle.

--

=====================
Mark Roddy
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
markr@hollistech.com


"Alex" <AlX@a> wrote in message
news:etbAYzwQEHA.1276@TK2MSFTNGP11.phx.gbl...

Yep, that solved it.

"Mark Roddy" <markr@hollistech.com> wrote in message
news:e8sBaFxQEHA.3728@TK2MSFTNGP10.phx.gbl...

"Alex" <AlX@a> wrote in message news:<etbAYzwQEHA.1276@TK2MSFTNGP11.phx.gbl>...
Do you set flag FILE_FLAG_OVERLAPPED in call to CreateFile function
(in 6th parameter dwFlagsAndAttributes)? According to MSDN "...This
flag also enables more than one operation to be performed
simultaneously with the handle (a simultaneous read and write
operation, for example)".

Regards,
Gennady Mayko.

After setting FILE_FLAG_OVERLAPPED in the win32 application 'convinced'
windows to send to my driver more then 1 IRP.

This is not at all the behaviour I expected, because, for example, I can
issue more then 1 read simultaneosly (on diffrent threads) without using the
overlapped flag.

But, if you think about it, it does make sense, mostly because of the file
pointer (i guess). Ovelapped operations don't have a implicit file pointer,
and you have to explicitly set it in the OVERLAPPED structure. This allows
concurent reads to bahave corectly.
Afcourse, I don't know for sure if this is the main or the only issue as to
why if you don't use the overlapped flag a driver will not see more then 1
IRP from a specific handle.



"Gennady Mayko" <gennady.mayko@broadcom.com> wrote in message
news:892d18ff.0405260731.5c1c6a88@posting.google.c om...

Yes.
Open the file with FILE_FLAG_OVERLAPPED to get rid of this.

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


"Alex" <AlX@a> wrote in message news:etbAYzwQEHA.1276@TK2MSFTNGP11.phx.gbl...

To the best of my knowledge, even if you don't use the overlapped flag
a driver CAN and WILL see more than one IRP.
As far as I know, the trouble comes when it you try to complete an
IRP, while
there is another pending IRP. In this case, Windows will "wake" two
threads, the one with the completed IRP and the one with the
UNcompleted IRP.

My guess is that this is due to the following scenario :
If you don't use the overlapped flag : upon CreateFile windows will
Create it's own one event, for all future requests. This event is
associated with this
HANDLE. Now, upon every DeviceIoControl/ReadFile/WriteFile/etc.... It
will
reset, this event and send it down as THE user event of this IRP. If
an Irp
is pending, the thread is waiting for this event.

IoCompleteRequest will ALWAYS
(Pending/NotPending/Overlapped/NotOevrlapped)
signal this event and the pending thread will wake. Only in this
scenario,
the thread with the uncompleted IRP is waiting for this one event, the
event
is signaled, and ......

I hope that what I wrote is clear.


Bye
Maurice

No, with this file object :-)

The rest of the description is correct. The main purpose is to protect the
lseek() pointer (FileObject->CurrentByteOffset).

Async IO allows several outstanding requests on the same handle, but with a
cost of being unable to use FileObject->CurrentByteOffset, so any operation
must explicitly specify the offset in the OVERLAPPED structure.

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