RE: Weird DeviceIoControl bug in win2k (blame the Io Manager for that ?)

I/O is functioning as it should. Please check docs for issues like this.
METHOD_IN_DIRECT/OUT_DIRECT expect that:
1.) the input buffer is buffered and in
Irp->AssociatedIrp.SystemBuffer - this is strictly an input buffer. Any
changes to this will not be reflected back in the original user buffer
2.) the output buffer is probed & locked down & described by
Irp->MdlAddress.

So the first form of the device i/o control call is correct, since
‘request’ would be in the SystemBuffer, and reply would be described by
MdlAddress.
Your driver fills in the reply by getting a system address for
Irp->MdlAddress & using that to modify the buffer contents.

If you want everything to be buffered, use METHOD_BUFFERED

If you have huge input buffers, use METHOD_NEITHER to save on the
copies. But, be careful - use exception handlers when accessing the
buffer, probe & lock if necessary etc.

Lastly remember regardless of what method you use, if your driver
implements a FastIoDeviceControl() to handle the IOCTL, the buffers that
come in via this dispatch will always be raw user buffers & access
should always be protected by an exception handler. The last bites many
people who tend to use a common routine for handling both
FastIoDeviceControl & IRP_MJ_DEVICE_CONTROL, and use METHOD_BUFFERED
IOCTLs assuming it’s always safe to touch the buffer.

Ravi

This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
From: Bi Chen [mailto:xxxxx@AppStream.com]
Sent: Monday, September 30, 2002 5:16 PM
To: NT Developers Interest List
Subject: [ntdev] Weird DeviceIoControl bug in win2k (blame the Io
Manager for that ?)

Hi,
I encountered a weird DeviceIoControl Bug. I wrote a driver that I have
a special need to send large chuck of data to kernel mode driver but
receive some small piggy-pack data in return. The driver is opened with
GENERIC_READ | GENERIC_WRITE flag.
I use
#define APPSD_IOCTL_DIRECTTOUT_REQ CTL_CODE(FILE_DEVICE_UNKNOWN,
APPS_DEVICE_1STFUNC + 3, METHOD_OUT_DIRECT,
FILE_READ_DATA|FILE_WRITE_DATA)
^^^^^^^^^^^^^^^^^
as the ioctl code.
In my code
DWORD cbRet = 0;
BOOL bRet = DeviceIoControl(m_hDriver, APPSD_IOCTL_DIRECTTOUT_REQ,
request, cbreq, reply, cbrep, &cbRet,
pOvlapped);
However, in my driver, I found out that IO Manager always
MmPageProbeAndLock the “reply” and set
Irp->MdlAddress to that memory.
Then I try the other way around even though DDK doc says otherwise, I
change the ioctl code to
#define APPSD_IOCTL_DIRECTTOUT_REQ CTL_CODE(FILE_DEVICE_UNKNOWN,
APPS_DEVICE_1STFUNC + 3, METHOD_IN_DIRECT,
FILE_READ_DATA|FILE_WRITE_DATA)
^^^^^^^^^^^^^^^^
The result is the same. Irp->MdlAddress still points to the reply.
The I revised input buffer and output buffer role

bRet = DeviceIoControl(m_hDriver, APPSD_IOCTL_DIRECTTOUT_REQ,
reply, cbrep, request, cbreq, &cbRet,
pOvlapped);
Now Irp->MdlAddress points to where I want. The problem is, whatever I
worte in the
Irp->AssociatedIrp.SystemBuffer in the driver is not copied to the reply
buffer in user mode.
Uh…, either I was working to hard to become dizzy headed or Microsoft
kernel guy did something really weird, something like
if(ioctl&3)
{
mdl = IoAllocateMdl(…);
MmPageProbeAndLock(mdl, UserMode, IoModifyAcess);
}
I believe it could be beause my head is dizzy and spining. First time
use DeviceIoControl to pass large data. I could not believe Io Manager
has such a bug.
Thanks.
Bi


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

Weird DeviceIoControl bug in win2k (blame the Io Manager for that?) This is by design.

Both direct IOCTL methods (they differ in IoxxxAccess parameter to MmProbeAndLockPages only) put InputBuffer to AssociatedIrp.SystemBuffer, and OutputBuffer to MdlAddress.
AssociatedIrp.SystemBuffer is never copied back to user.
The only difference between 2 IOCTLs is how the OutputBuffer is locked. One method (don’t remember off-head what namely) locks OutputBuffer for write, thus providing a usual request/response semantics. Another locks OutputBuffer for read, in this case, OutputBuffer is second input buffer and there is no output buffer.
Such an IOCTL provides a “write qualified with some small additional data” semantics, it can be useful.

Max

----- Original Message -----
From: Bi Chen
To: NT Developers Interest List
Sent: Tuesday, October 01, 2002 4:15 AM
Subject: [ntdev] Weird DeviceIoControl bug in win2k (blame the Io Manager for that ?)

Hi,

I encountered a weird DeviceIoControl Bug. I wrote a driver that I have a special need to send large chuck of data to kernel mode driver but receive some small piggy-pack data in return. The driver is opened with GENERIC_READ | GENERIC_WRITE flag.

I use

#define APPSD_IOCTL_DIRECTTOUT_REQ CTL_CODE(FILE_DEVICE_UNKNOWN, APPS_DEVICE_1STFUNC + 3, METHOD_OUT_DIRECT, FILE_READ_DATA|FILE_WRITE_DATA)

^^^^^^^^^^^^^^^^^
as the ioctl code.

In my code

DWORD cbRet = 0;
BOOL bRet = DeviceIoControl(m_hDriver, APPSD_IOCTL_DIRECTTOUT_REQ,
request, cbreq, reply, cbrep, &cbRet, pOvlapped);

However, in my driver, I found out that IO Manager always MmPageProbeAndLock the “reply” and set
Irp->MdlAddress to that memory.

Then I try the other way around even though DDK doc says otherwise, I change the ioctl code to

#define APPSD_IOCTL_DIRECTTOUT_REQ CTL_CODE(FILE_DEVICE_UNKNOWN, APPS_DEVICE_1STFUNC + 3, METHOD_IN_DIRECT, FILE_READ_DATA|FILE_WRITE_DATA)

^^^^^^^^^^^^^^^^

The result is the same. Irp->MdlAddress still points to the reply.

The I revised input buffer and output buffer role

bRet = DeviceIoControl(m_hDriver, APPSD_IOCTL_DIRECTTOUT_REQ,
reply, cbrep, request, cbreq, &cbRet, pOvlapped);

Now Irp->MdlAddress points to where I want. The problem is, whatever I worte in the
Irp->AssociatedIrp.SystemBuffer in the driver is not copied to the reply buffer in user mode.

Uh…, either I was working to hard to become dizzy headed or Microsoft kernel guy did something really weird, something like

if(ioctl&3)
{
mdl = IoAllocateMdl(…);
MmPageProbeAndLock(mdl, UserMode, IoModifyAcess);
}

I believe it could be beause my head is dizzy and spining. First time use DeviceIoControl to pass large data. I could not believe Io Manager has such a bug.

Thanks.

Bi


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