DeviceIoControl Buffer size limit.

NTDEV
1

I’m used to sending ioctls with buffers of 1 MB length since early days of
NT.
Now, I’m testing a rather generic driver that I wrote for XP/2000, and
ioctls of
greater than 32 KB fail in the following manner.

  • The driver gets called at its ioctl dispatch routine, however the
    IRP is invalid. That is I’m issuing a DIRECT (rather than BUFFERED) ioctl,
    but Irp->MdlAddress is NULL.

You would think, if anything, the over the limit request would get
aborted by the I/O manager and never make it to the driver.

thanks,

m navab

2

the output buffer of the IOCTL is the one the MDL gets built for. The
input buffer always arrives as the system buffer.

-p

-----Original Message-----
From: xxxxx@yahoo.com [mailto:xxxxx@yahoo.com]
Sent: Monday, December 02, 2002 9:08 AM
To: NT Developers Interest List
Subject: [ntdev] DeviceIoControl Buffer size limit.

I’m used to sending ioctls with buffers of 1 MB length since early days
of NT. Now, I’m testing a rather generic driver that I wrote for
XP/2000, and ioctls of greater than 32 KB fail in the following manner.

  • The driver gets called at its ioctl dispatch routine, however the IRP
    is invalid. That is I’m issuing a DIRECT (rather than BUFFERED) ioctl,
    but Irp->MdlAddress is NULL.

You would think, if anything, the over the limit request would get
aborted by the I/O manager and never make it to the driver.

thanks,

m navab

You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

3

i thought which gets the MDL, and which get the system
buffer depends on the METHOD_(IN/OUT)_DIRECT FLAG.

I use METHOD_IN_DIRECT. What I’m trying to figure out is that
why when I increase buffer size from 32 KB, I get an IRP with
MdlAddress to set NULL. For smaller buffers IRP looks good.

thanks,

m navab

4

xxxxx@yahoo.com wrote:

i thought which gets the MDL, and which get the system
buffer depends on the METHOD_(IN/OUT)_DIRECT FLAG.

Nope. Input buffer (if any) always goes to SystemBuffer, output buffer
always goes to MDL. This is for *both* IN_DIRECT and OUT_DIRECT.

As I recall, there was lots of confusion about this up until a few years
ago, and I think the DDK even had it wrong.

If you’re not dizzy yet, think about this: if you’re trying to send data
to your hardware, you’re doing an output operation, right? So you’d use
METHOD_IN_DIRECT. I kid you not – the “IN” is from the perspective of
the driver.

I use METHOD_IN_DIRECT. What I’m trying to figure out is that
why when I increase buffer size from 32 KB, I get an IRP with
MdlAddress to set NULL. For smaller buffers IRP looks good.

This truly doesn’t make sense. If the system were unable to probe and
lock the pages, it would fail the DeviceIoControl call before it ever
sent the IRP to the driver. I think you must somehow be passing zero as
the output buffer length somehow.

–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Now teaming with John Hyde for USB Device Engineering Seminars
Check out our schedule at http://www.oneysoft.com

5

I have to agree with Walter, considering that I use METHOD_IN/OUT_DIRECT to
pass a command buffer and data buffer. The command buffer is in the INPUT
parameters (SystemBuffer) and the data buffer goes to the OUTPUT parameters
(MdlAddress) of the DeviceIoControl call. You’ve got a silly little bug that
you can’t see, because the ONLY limitation on the size of the buffer
described by MdlAddress arfe limitations imposaed by you and the natural
limitation of an MDL which is 64Meg.

Jamey Hanrahan described it best in a seminar — When using
METHOD_IN/OUT_DIRECT think of INPUT as your COMMAND or CONTROL buffer which
means that OUTPUT becomes your DATA buffer.

“Walter Oney” wrote in message news:xxxxx@ntdev…
>
> xxxxx@yahoo.com wrote:
> > i thought which gets the MDL, and which get the system
> > buffer depends on the METHOD_(IN/OUT)_DIRECT FLAG.
>
> Nope. Input buffer (if any) always goes to SystemBuffer, output buffer
> always goes to MDL. This is for both IN_DIRECT and OUT_DIRECT.
>
> As I recall, there was lots of confusion about this up until a few years
> ago, and I think the DDK even had it wrong.
>
> If you’re not dizzy yet, think about this: if you’re trying to send data
> to your hardware, you’re doing an output operation, right? So you’d use
> METHOD_IN_DIRECT. I kid you not – the “IN” is from the perspective of
> the driver.
>
> > I use METHOD_IN_DIRECT. What I’m trying to figure out is that
> > why when I increase buffer size from 32 KB, I get an IRP with
> > MdlAddress to set NULL. For smaller buffers IRP looks good.
>
> This truly doesn’t make sense. If the system were unable to probe and
> lock the pages, it would fail the DeviceIoControl call before it ever
> sent the IRP to the driver. I think you must somehow be passing zero as
> the output buffer length somehow.
>
> –
> Walter Oney, Consulting and Training
> Basic and Advanced Driver Programming Seminars
> Now teaming with John Hyde for USB Device Engineering Seminars
> Check out our schedule at http://www.oneysoft.com
>
>

6

We went through a rewrite of this area in the DDK documentation recently to
clear up this confusion. Also Walter’s right. If the length passed is NULL
the IO manager sets Irp->MdlAddress to NULL.

–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no rights.

“Gary G. Little” wrote in message news:xxxxx@ntdev…
>
> I have to agree with Walter, considering that I use METHOD_IN/OUT_DIRECT
to
> pass a command buffer and data buffer. The command buffer is in the INPUT
> parameters (SystemBuffer) and the data buffer goes to the OUTPUT
parameters
> (MdlAddress) of the DeviceIoControl call. You’ve got a silly little bug
that
> you can’t see, because the ONLY limitation on the size of the buffer
> described by MdlAddress arfe limitations imposaed by you and the natural
> limitation of an MDL which is 64Meg.
>
> Jamey Hanrahan described it best in a seminar — When using
> METHOD_IN/OUT_DIRECT think of INPUT as your COMMAND or CONTROL buffer
which
> means that OUTPUT becomes your DATA buffer.
>
> “Walter Oney” wrote in message news:xxxxx@ntdev…
> >
> > xxxxx@yahoo.com wrote:
> > > i thought which gets the MDL, and which get the system
> > > buffer depends on the METHOD_(IN/OUT)_DIRECT FLAG.
> >
> > Nope. Input buffer (if any) always goes to SystemBuffer, output buffer
> > always goes to MDL. This is for both IN_DIRECT and OUT_DIRECT.
> >
> > As I recall, there was lots of confusion about this up until a few years
> > ago, and I think the DDK even had it wrong.
> >
> > If you’re not dizzy yet, think about this: if you’re trying to send data
> > to your hardware, you’re doing an output operation, right? So you’d use
> > METHOD_IN_DIRECT. I kid you not – the “IN” is from the perspective of
> > the driver.
> >
> > > I use METHOD_IN_DIRECT. What I’m trying to figure out is that
> > > why when I increase buffer size from 32 KB, I get an IRP with
> > > MdlAddress to set NULL. For smaller buffers IRP looks good.
> >
> > This truly doesn’t make sense. If the system were unable to probe and
> > lock the pages, it would fail the DeviceIoControl call before it ever
> > sent the IRP to the driver. I think you must somehow be passing zero as
> > the output buffer length somehow.
> >
> > –
> > Walter Oney, Consulting and Training
> > Basic and Advanced Driver Programming Seminars
> > Now teaming with John Hyde for USB Device Engineering Seminars
> > Check out our schedule at http://www.oneysoft.com
> >
> >
>
>
>
>