Thanks for the explanation, Max and Rev. I could not find where the DDK doc
says that. With your explaination, I believe it is by design, using Output
buffer as the second input buffer, using the input buffer to specify private
information of the second input buffer.
It looks like DeviceIoControl does not foot my bill to piggy-pack some data
on the way back to user mode, I try to avoid page probe and lock the "output
buffer (to DeviceIoControl) since it is usally no more than 32 byte. The
best way may be to use METHOD_NEITHER and almost documented KAPC. Shame on
Microsoft not to give us an easy way out.
Bi
-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Monday, September 30, 2002 5:45 PM
To: NT Developers Interest List
Subject: [ntdev] Re: 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 mailto:xxxxx
To: NT Developers Interest List mailto:xxxxx
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%%
—
You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%</mailto:xxxxx></mailto:xxxxx>