trouble when read data from driver through the 2nd device object.

NTDEV
1

Hi Experts,
I created 2nd device object in my usb device driver.Application
can open the 2nd device object,but has trouble when read data from
driver through the 2nd device object.
The reason I suppose is due to the IRP_MJ_READ.In the IRP_MJ_READ
dispatch routine for the 2nd device object,if I add the only sentence:
“return STATUS_SUCESS”,ReadFile in application is OK.
If I add “IRP->Iostatus.Information = 8” before above sentence,
appears BSOD “A,IRP_NOT_LESS_OR_EQUAL”.
What’s wrong?
Could you advice?Thanks a lot.

Mp3·è¿ñËÑ-иèÈȸè¸ßËÙÏÂ

2

If your device has the flag DO_BUFFERED_IO then you order the system to copy 8 bytes from the system’s buffer to the user’s buffer. Did the application really want to read 8 byte? May be 2 or 4 bytes?

“Yu Zhou” wrote in message news:xxxxx@ntdev…
Hi Experts,
I created 2nd device object in my usb device driver.Application
can open the 2nd device object,but has trouble when read data from
driver through the 2nd device object.
The reason I suppose is due to the IRP_MJ_READ.In the IRP_MJ_READ
dispatch routine for the 2nd device object,if I add the only sentence:
“return STATUS_SUCESS”,ReadFile in application is OK.
If I add “IRP->Iostatus.Information = 8” before above sentence,
appears BSOD “A,IRP_NOT_LESS_OR_EQUAL”.
What’s wrong?
Could you advice?Thanks a lot.

------------------------------------------------------------------------------
Mp3???-?¸??ȸ???

3

How did you set IRP->IoStatus->Status? If it is not STATUS_SUCCESS, then
setting the bytes to return is spurious. Also, if you do not have a buffer
allocated for that 8 bytes, the IO manager is going to write them to god
knows where, given that status is STATUS_SUCCESS. Once your driver has the
buffer, your app cannot reuse or release it until your driver has finished
with it and the IO request has been completed.

Gary G. Little

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.
osr.com] On Behalf Of xxxxx@yahoo.com.cn
Sent: Tuesday, June 27, 2006 6:02 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] trouble when read data from driver through the 2nd device
object.

Hi Experts,
I created 2nd device object in my usb device driver.Application
can open the 2nd device object,but has trouble when read data from
driver through the 2nd device object.
The reason I suppose is due to the IRP_MJ_READ.In the IRP_MJ_READ
dispatch routine for the 2nd device object,if I add the only sentence:
“return STATUS_SUCESS”,ReadFile in application is OK.
If I add “IRP->Iostatus.Information = 8” before above sentence,
appears BSOD “A,IRP_NOT_LESS_OR_EQUAL”.
What’s wrong?
Could you advice?Thanks a lot.

Mp3 http: ???-?¸???
??? — Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</http:>

4

When did you call IoCompleteRequest? Was it before or after you set IRP->IoStatus.Information?

You are not allowed to touch the IRP after it has been completed. You should set the IoStatus block before calling IoCompleteRequest (and make sure you do not return IRP->IoStatus.Status for the same reason).

Beverly

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Yu Zhou
Sent: Tuesday, June 27, 2006 7:02 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] trouble when read data from driver through the 2nd device object.

Hi Experts,
I created 2nd device object in my usb device driver.Application
can open the 2nd device object,but has trouble when read data from
driver through the 2nd device object.
The reason I suppose is due to the IRP_MJ_READ.In the IRP_MJ_READ
dispatch routine for the 2nd device object,if I add the only sentence:
“return STATUS_SUCESS”,ReadFile in application is OK.
If I add “IRP->Iostatus.Information = 8” before above sentence,
appears BSOD “A,IRP_NOT_LESS_OR_EQUAL”.
What’s wrong?
Could you advice?Thanks a lot.

Mp3???-?¸??ȸ??? http: — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</http:>

5

xxxxx@seagate.com wrote:

How did you set IRP->IoStatus->Status? If it is not STATUS_SUCCESS,
then setting the bytes to return is spurious.

Is it? If a buffer is too small, I thought I could return partial data
along with an error that the client could detect and act on if it needed to.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

6

You can only return partial data on error if you are using Direct IO.

For DeviceIoControl with METHOD_BUFFERED, no data will be copied back on
error regardless of the number of bytes you set for Information. That
number just gets ignored. You can return partial data on error if you
use METHOD_OUT_DIRECT.

I don’t know what will happen for reads if you use DO_BUFFERED_IO. I
usually have DO_DIRECT_IO set for doing reads. I would expect similar
behavior to DeviceIoControl, though.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, June 27, 2006 12:19 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] trouble when read data from driver through the 2nd
device object.

xxxxx@seagate.com wrote:

How did you set IRP->IoStatus->Status? If it is not STATUS_SUCCESS,
then setting the bytes to return is spurious.

Is it? If a buffer is too small, I thought I could return partial data
along with an error that the client could detect and act on if it needed
to.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

7

Close, but not exactly right.

For buffered I/O, if the returned status is NOT an error (that is: !NT_ERROR(irp->IoStatus.Status)) ) then the number of bytes specified in IoStatus.Information is copied back to the user data buffer.

Thus the use of STATUS_BUFFER_OVERFLOW (a warning) and STATUS_BUFFER_TOO_SMALL, STATUS_INVALID_USER_BUFFER, and STATUS_INVALID_BUFFER_SIZEL (all errors).

Peter
OSR

8

It’s been a while since I played with stuff like this, but I think the
trick is to use a return value that doesn’t fail NT_SUCCESS(). I don’t
think you are only limited to STATUS_SUCCESS. I could be really wrong on
that, and welcome correction for the sake of the archives if I am.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

“Brown, Beverly”

Sent by: To
bounce-255063-643 “Windows System Software Devs
xxxxx@lists.osr.com Interest List”
No Phone Info
Available cc

Subject
06/27/2006 11:01 RE: [ntdev] trouble when read data
AM from driver through the 2nd device
object.

Please respond to
“Windows System
Software Devs
Interest List”
com>

You can only return partial data on error if you are using Direct IO.

For DeviceIoControl with METHOD_BUFFERED, no data will be copied back on
error regardless of the number of bytes you set for Information. That
number just gets ignored. You can return partial data on error if you
use METHOD_OUT_DIRECT.

I don’t know what will happen for reads if you use DO_BUFFERED_IO. I
usually have DO_DIRECT_IO set for doing reads. I would expect similar
behavior to DeviceIoControl, though.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, June 27, 2006 12:19 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] trouble when read data from driver through the 2nd
device object.

xxxxx@seagate.com wrote:

> How did you set IRP->IoStatus->Status? If it is not STATUS_SUCCESS,
> then setting the bytes to return is spurious.
>

Is it? If a buffer is too small, I thought I could return partial data
along with an error that the client could detect and act on if it needed
to.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

9

I think it depends on the status, and re-thinking what I said in a hurry
this morning, of course there really are status returns that will return
data, but are not STATUS_SUCCESS. That 32 bit value going into
IoStatus->Status is the “status” of the operation, not necessarily an
error; Error, Warning, Information, Success are the typical definitions,
and many of them legitimately will return data, requiring a value in
Information.

In my drivers, if I return Status == Error, I set Information to zero,
which I believe, is the proper value for a true error (0x8xxxxxxx). Driver
Verifier will change the value of STATUS_SUCCESS as I have seen to test
for such silliness as “if (STATUS_SUCCESS == status)” instead of using the
NT_SUCCESS macro.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@probo.com
Sent: Tuesday, June 27, 2006 11:19 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] trouble when read data from driver through the 2nd
device object.

xxxxx@seagate.com wrote:

How did you set IRP->IoStatus->Status? If it is not STATUS_SUCCESS,
then setting the bytes to return is spurious.

Is it? If a buffer is too small, I thought I could return partial data
along with an error that the client could detect and act on if it needed
to.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

10

> > How did you set IRP->IoStatus->Status? If it is not STATUS_SUCCESS,

> then setting the bytes to return is spurious.
>

Is it? If a buffer is too small, I thought I could return partial data
along with an error that the client could detect and act on if it needed to.

You cannot fill more data at ->AssociatedIrp.SystemBuffer then the output
buffer size which was the syscall parameter in ->Parameters.Read.Length
or ->Parameters.DeviceControl.OutputBufferLength.

The OS allocates ->AssociatedIrp.SystemBuffer according to this.

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

11

> Thus the use of STATUS_BUFFER_OVERFLOW (a warning) and

STATUS_BUFFER_TOO_SMALL, STATUS_INVALID_USER_BUFFER, and

Correct.

STATUS_BUFFER_OVERFLOW is mapped to Win32 ERROR_MORE_DATA, and means “the
actual data is larger then the provided space, but we will copy the starting
part of it anyway”.

STATUS_BUFFER_TOO_SMALL means - fatal error, we can do nothing with this
small a space provided.

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