Returning STATUS_END_OF_FILE from IRP_MJ_READ

NTDEV
1

Hi everybody,

I am writing a pretty simple legacy driver that creates a FILE_DEVICE_UNKNOWN device object and it will return some data from the IRP_MJ_READ dispatch routine. By some reason, I’d like to return STATUS_END_OF_FILE when my driver has no more data to be read. During a test I realized an unexpected behavior when the driver returns STATUS_END_OF_FILE from the dispatch routine, the User-Mode API ReadFile still returns TRUE, that means no error has occurred. I changed the error code to another one like STATUS_ACCESS_DENIED just to see what would happen, and it worked as expected, that means ReadFile has returned FALSE and GetLastError() has returned 5 (Access denied). I already read some books about driver development including “Windows NT File Systems Internals”, but I can’t remember any special behavior about returning STATUS_END_OF_FILE from a legacy driver.

Even with the code shown below the behavior is seen.

NTSTATUS OnRead(PDEVICE_OBJECT pDeviceObj,
PIRP pIrp)
{
pIrp->IoStatus.Status = STATUS_END_OF_FILE;
pIrp->IoStatus.Information = 0;
IoCompleteRequest(pIrp,
IO_NO_INCREMENT);

return STATUS_END_OF_FILE;
}

Anyone knows about this special behavior?
If so, is there any documentation about that?

Regards,

Fernando Roberto da Silva
DriverEntry Kernel Development
http://www.driverentry.com.br

2

>it will return some data from the IRP_MJ_READ dispatch routine. By some reason, I’d like to return

STATUS_END_OF_FILE when my driver has no more data to be read.

I think that STATUS_END_OF_FILE is only used somewhere in FSD/Cc/Mm interaction.

The proper way is to return lesser bytes from read then was asked, or even 0 bytes (the usual EOF indication).

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

3

Thanks Maxim,

I did an interesting test with my application just opening a actual file rather then my device. The same behavior was observed. So, it hast nothing to do with my driver.

One Google search later I found the following text at ReadFile MSDN page:

http://msdn.microsoft.com/en-us/library/aa365467(VS.85).aspx
“When a synchronous read operation reaches the end of a file, ReadFile returns TRUE and sets *lpNumberOfBytesRead to zero.”

Concluding, it was just an unhappy choice for a return code.

Thanks again.

Fernando Roberto da Silva
DriverEntry Kernel Development
http://www.driverentry.com.br

4

I believe that the correct behavior is that when the last block (whatever
block size you chose) is read it will report the amount of data it actually
read. If that size is less than the requested size it is the application’s
responsibility to handle that. If the last block read is equal to the
quantity requested, then the next read will return no error and zero as the
quantity read.

wrote in message news:xxxxx@ntdev…
> Thanks Maxim,
>
> I did an interesting test with my application just opening a actual file
> rather then my device. The same behavior was observed. So, it hast nothing
> to do with my driver.
>
> One Google search later I found the following text at ReadFile MSDN page:
>
> http://msdn.microsoft.com/en-us/library/aa365467(VS.85).aspx
> “When a synchronous read operation reaches the end of a file, ReadFile
> returns TRUE and sets *lpNumberOfBytesRead to zero.”
>
> Concluding, it was just an unhappy choice for a return code.
>
> Thanks again.
> –
> Fernando Roberto da Silva
> DriverEntry Kernel Development
> http://www.driverentry.com.br
>