Alexander
Sat Dec 31 16:38:39 CST 2005
I think we have a little disagreement.
If you return STATUS_PENDING, the IRP is considered asynchronous, and
asynchronous completion path is invoked on IoCompleteRequest, even though
the driver logic guaranteed its completion before return from dispatch
routine. In this case DeviceIoControl returns
FALSE/GetLastError=ERROR_IO_PENDING. If the handle is overlapped, the app
must in this case use GetOverlappedResult.
If the driver calls IoCompleteRequest and returns NON STATUS_PENDING, the
IRP is considered synchronous. Even if the handle is overlapped, the result
will be placed to BytesReturned. I'm not sure the OVERLAPPED.event will even
be signalled in that case.
Some applications incorrectly assume that some IPRs are always completed
synchronously and expect DeviceIoControl return TRUE for those. For example,
I've had a problem with a virtual COM driver of mine, which always used
asynchronous completion for READ IRP, even though the requested amount of
data was guaranteed available in the buffer. Microsoft's MCCOMM32.OCX
erroneously assumed that those IRPs should be completed synchronously (it is
using ClearCommError/COMSTAT::cbInQueue to get number of avilable bytes).
"Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
news:eQfI6qjDGHA.2292@tk2msftngp13.phx.gbl...
> if you mark the irp pending, complete the irp and return STATUS_PENDING
> (which is a synchronous complete), BytesReturned is not valid. If you
> have an OVERLAPPED HANDLE, you should never rely on BytesReturned and
> should always use GetOverlappedResult to get the final bytes transfered.
> You cannot rely on BytesReturned b/c you don't know if the driver or some
> filter pended the irp.
>
> d
>
> --
> Please do not send e-mail directly to this alias. this alias is for
> newsgroup purposes only.
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
> "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
> news:OLNBiZiDGHA.1264@TK2MSFTNGP09.phx.gbl...
>>I think if the IRP is completed synchronously (even on OVERLAPPED handle),
>>the result will be placed to BytesReturned.
>>
>> I guess the OP problem might be because of incorrect
>> IoMarkIrpPending/STATUS_PENDING matching.
>>
>> "Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
>> news:%232LnjbeDGHA.2924@tk2msftngp13.phx.gbl...
>>> are you sending a synchronous IOCTL on an overlapped HANDLE? if so,
>>> BytesReturned is meaningless in this scenario.
>>>
>>> d
>>>
>>> --
>>> Please do not send e-mail directly to this alias. this alias is for
>>> newsgroup purposes only.
>>> This posting is provided "AS IS" with no warranties, and confers no
>>> rights.
>>>
>>>
>>> "Tierrie" <tierrie@gmail.com> wrote in message
>>> news:1135997002.416797.41330@g43g2000cwa.googlegroups.com...
>>>> In one of my DeviceIoControl, the BytesReturned is always 3435973836
>>>> (0xCCCCCCCC). In the driver I set the value of
>>>> Irp->IoStatus.Information to 4 and I have verified this value many
>>>> times. I even initialized the value of BytesReturned to 0 prior to
>>>> DeviceIoControl and verified that is is 0.
>>>>
>>>> Has anyone else encountered this problem?
>>>>
>>>
>>>
>>
>>
>
>