system buffer address?

NTDEV
1

Hi all,

Can someone give me a clue what may be going on here? I believe the system buffer should have a valid address in this case. What could cause it not to?

#define V3_IOCTL_READ_SWITCHES CTL_CODE (FILE_DEVICE_UNKNOWN, \
0x8002, \
METHOD_BUFFERED, \
FILE_ANY_ACCESS);

In user app:

long unsigned int switch_data = 0;

if(DeviceIoControl(hV3Device,
V3_IOCTL_READ_SWITCHES,
NULL,
0,
&switch_data,
sizeof(switch_data),
&nBytesTransferred,
NULL) == 0)
{
// ERROR, could not communicate to device!!!
printf(“ERROR: could not communicate to device!\n”);
printf(“Press return to quit”);
getc(stdin);
exit(1);
}

And from the driver (via windbg):

v3driver: Opened!!

v3driver: v3Ioctl

v3driver: Doing a “read switches”

v3driver: read switches > ioStack->Parameters.DeviceIoControl.IoControlCode = 0x8002

v3driver: read switches > ioStack->Parameters.DeviceIoControl.OutputBufferLength = 0x4

v3driver: read switches > ioStack->Parameters.DeviceIoControl.InputBufferLength = 0x0

v3driver: read switches > ioStack->Parameters.DeviceIoControl.Type3InputBuffer = 0x0

v3driver: read switches > Irp->AssociatedIrp.SystemBuffer = 0x0

Breakpoint 1 hit

v3driver!v3Ioctl+0x260:

Now I was under the impression that the System Buffer would be defined by the output buffer if the input buffer was NULL. So why would the address be 0x0? This, of course is causing an access violation shortly after. If I were to specify the output and input buffer, I would get a reasonable address for the system buffer. This is strange.

Thanks in advance,

Howard Keller

2

that is odd.

i presume you’re the top driver in the stack?

-p

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of hkeller
Sent: Tuesday, February 10, 2004 11:09 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] system buffer address?

Hi all,

Can someone give me a clue what may be going on here? I believe the
system buffer should have a valid address in this case. What could cause
it not to?

#define V3_IOCTL_READ_SWITCHES CTL_CODE (FILE_DEVICE_UNKNOWN, \
0x8002, \
METHOD_BUFFERED, \
FILE_ANY_ACCESS);

In user app:

long unsigned int switch_data = 0;

if(DeviceIoControl(hV3Device,
V3_IOCTL_READ_SWITCHES,
NULL,
0,
&switch_data,
sizeof(switch_data),
&nBytesTransferred,
NULL) == 0)
{
// ERROR, could not communicate to device!!!
printf(“ERROR: could not communicate to
device!\n”);
printf(“Press return to quit”);
getc(stdin);
exit(1);
}

And from the driver (via windbg):

v3driver: Opened!!

v3driver: v3Ioctl

v3driver: Doing a “read switches”

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.IoControlCode = 0x8002

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.OutputBufferLength = 0x4

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.InputBufferLength = 0x0

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.Type3InputBuffer = 0x0

v3driver: read switches > Irp->AssociatedIrp.SystemBuffer = 0x0

Breakpoint 1 hit

v3driver!v3Ioctl+0x260:

Now I was under the impression that the System Buffer would be defined
by the output buffer if the input buffer was NULL. So why would the
address be 0x0? This, of course is causing an access violation shortly
after. If I were to specify the output and input buffer, I would get a
reasonable address for the system buffer. This is strange.

Thanks in advance,

Howard Keller

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

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

3

This is all just a WAG but anyhow…

Didn’t you have a remarkably similar problem with another IOCTL using
METHOD_OUT_DIRECT? Is this actually the same malfunctioning IOCTL redefined?
Are you sure that you changed the IOCTL definition in both the driver and
the application? Are you using IoGetFunctionCodeFromCtlCode() in a switch
statement? This would hide the inconsistency between your application and
your driver and is not generally a good idea. In fact it ought to be
banished from the DDK. Instead just switch on the CTL_CODE value itself as
in

case V3_IOCTL_READ_SWITCHES:

By the way IOCTLs do actually work as defined, so (obviously) you have a bug
in your code.

=====================
Mark Roddy

From: hkeller [mailto:xxxxx@memecdesign.com]
Sent: Tuesday, February 10, 2004 2:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] system buffer address?

Hi all,

Can someone give me a clue what may be going on here? I believe the
system buffer should have a valid address in this case. What could cause it
not to?

#define V3_IOCTL_READ_SWITCHES CTL_CODE (FILE_DEVICE_UNKNOWN, \
0x8002, \
METHOD_BUFFERED, \
FILE_ANY_ACCESS);

In user app:

long unsigned int switch_data = 0;

if(DeviceIoControl(hV3Device,
V3_IOCTL_READ_SWITCHES,
NULL,
0,
&switch_data,
sizeof(switch_data),
&nBytesTransferred,
NULL) == 0)
{
// ERROR, could not communicate to
device!!!
printf(“ERROR: could not communicate to
device!\n”);
printf(“Press return to quit”);
getc(stdin);
exit(1);
}

And from the driver (via windbg):

v3driver: Opened!!

v3driver: v3Ioctl

v3driver: Doing a “read switches”

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.IoControlCode = 0x8002

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.OutputBufferLength = 0x4

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.InputBufferLength = 0x0

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.Type3InputBuffer = 0x0

v3driver: read switches > Irp->AssociatedIrp.SystemBuffer = 0x0

Breakpoint 1 hit

v3driver!v3Ioctl+0x260:

Now I was under the impression that the System Buffer would be
defined by the output buffer if the input buffer was NULL. So why would the
address be 0x0? This, of course is causing an access violation shortly
after. If I were to specify the output and input buffer, I would get a
reasonable address for the system buffer. This is strange.

Thanks in advance,

Howard Keller

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

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

Yes, The app calls me via IOCTLs and I talk directly to a PCI bus master
card.

Howard

“Peter Wieland” wrote in message
news:xxxxx@ntdev…
that is odd.

i presume you’re the top driver in the stack?

-p

________________________________

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of hkeller
Sent: Tuesday, February 10, 2004 11:09 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] system buffer address?

Hi all,

Can someone give me a clue what may be going on here? I believe the
system buffer should have a valid address in this case. What could cause
it not to?

#define V3_IOCTL_READ_SWITCHES CTL_CODE (FILE_DEVICE_UNKNOWN, <br> 0x8002, <br> METHOD_BUFFERED, <br> FILE_ANY_ACCESS);

In user app:

long unsigned int switch_data = 0;

if(DeviceIoControl(hV3Device,
V3_IOCTL_READ_SWITCHES,
NULL,
0,
&switch_data,
sizeof(switch_data),
&nBytesTransferred,
NULL) == 0)
{
// ERROR, could not communicate to device!!!
printf(“ERROR: could not communicate to
device!\n”);
printf(“Press return to quit”);
getc(stdin);
exit(1);
}

And from the driver (via windbg):

v3driver: Opened!!

v3driver: v3Ioctl

v3driver: Doing a “read switches”

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.IoControlCode = 0x8002

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.OutputBufferLength = 0x4

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.InputBufferLength = 0x0

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.Type3InputBuffer = 0x0

v3driver: read switches > Irp->AssociatedIrp.SystemBuffer = 0x0

Breakpoint 1 hit

v3driver!v3Ioctl+0x260:

Now I was under the impression that the System Buffer would be defined
by the output buffer if the input buffer was NULL. So why would the
address be 0x0? This, of course is causing an access violation shortly
after. If I were to specify the output and input buffer, I would get a
reasonable address for the system buffer. This is strange.

Thanks in advance,

Howard Keller

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

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

5

Yes, I seem to be having some sort of problem that by some remote thing may
be related. I did change the IOCTL definition in both the driver and the
application, so the IOCTL called is really the desired IOCTL. I’m using
switch (ioStack->Parameters.DeviceIoControl.IoControlCode) in the driver so
that should be ok. And in the driver I am using case
V3_IOCTL_READ_SWITCHES: .

The real case I was trying to find a solution for was a case where I was
reading and writing BAR0 registers correctly using buffered I/O and both an
in and out buffer in the DeviceIoControl. The read in this case worked just
fine, the register data was getting to my app. The code I had for the read
switches was essentially the same as the read reg, but the data never got to
the app (the nBytesTransfered variable did indicate 4 bytes were transferred
to the app). The data, however WAS transferred from the BAR0 register to the
system buffer!. Now if I were to substitute the BAR1 address (switches)
instead of the BAR0 address in the driver code for read reg and called the
read reg from the app, the switch data GOT to the app!. No real difference
except a different entry point in the driver.

Could I possibly have some sort of environment problem?

Howard
“Roddy, Mark” wrote in message news:xxxxx@ntdev…
> This is all just a WAG but anyhow…
>
> Didn’t you have a remarkably similar problem with another IOCTL using
> METHOD_OUT_DIRECT? Is this actually the same malfunctioning IOCTL
redefined?
> Are you sure that you changed the IOCTL definition in both the driver and
> the application? Are you using IoGetFunctionCodeFromCtlCode() in a switch
> statement? This would hide the inconsistency between your application and
> your driver and is not generally a good idea. In fact it ought to be
> banished from the DDK. Instead just switch on the CTL_CODE value itself as
> in
>
> case V3_IOCTL_READ_SWITCHES:
>
>
> By the way IOCTLs do actually work as defined, so (obviously) you have a
bug
> in your code.
>
> =====================
> Mark Roddy
>
>
>
>
>
> ________________________________
>
> From: hkeller [mailto:xxxxx@memecdesign.com]
> Sent: Tuesday, February 10, 2004 2:09 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] system buffer address?
>
>
> Hi all,
>
> Can someone give me a clue what may be going on here? I believe the
> system buffer should have a valid address in this case. What could cause
it
> not to?
>
> #define V3_IOCTL_READ_SWITCHES CTL_CODE (FILE_DEVICE_UNKNOWN, <br>> 0x8002, <br>> METHOD_BUFFERED, <br>> FILE_ANY_ACCESS);
>
> In user app:
>
> long unsigned int switch_data = 0;
>
> if(DeviceIoControl(hV3Device,
> V3_IOCTL_READ_SWITCHES,
> NULL,
> 0,
> &switch_data,
> sizeof(switch_data),
> &nBytesTransferred,
> NULL) == 0)
> {
> // ERROR, could not communicate to
> device!!!
> printf(“ERROR: could not communicate to
> device!\n”);
> printf(“Press return to quit”);
> getc(stdin);
> exit(1);
> }
>
> And from the driver (via windbg):
>
>
> v3driver: Opened!!
>
> v3driver: v3Ioctl
>
> v3driver: Doing a “read switches”
>
> v3driver: read switches >
> ioStack->Parameters.DeviceIoControl.IoControlCode = 0x8002
>
> v3driver: read switches >
> ioStack->Parameters.DeviceIoControl.OutputBufferLength = 0x4
>
> v3driver: read switches >
> ioStack->Parameters.DeviceIoControl.InputBufferLength = 0x0
>
> v3driver: read switches >
> ioStack->Parameters.DeviceIoControl.Type3InputBuffer = 0x0
>
> v3driver: read switches > Irp->AssociatedIrp.SystemBuffer = 0x0
>
> Breakpoint 1 hit
>
> v3driver!v3Ioctl+0x260:
>
> Now I was under the impression that the System Buffer would be
> defined by the output buffer if the input buffer was NULL. So why would
the
> address be 0x0? This, of course is causing an access violation shortly
> after. If I were to specify the output and input buffer, I would get a
> reasonable address for the system buffer. This is strange.
>
> Thanks in advance,
>
> Howard Keller
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@stratus.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>

6

Function codes are only 12 bits. IOW 0x8002 is too big, and you are
screwing with the access method. The function number must be less than
0x1000.

Thanks,
Rob

#define V3_IOCTL_READ_SWITCHES CTL_CODE (FILE_DEVICE_UNKNOWN, \
0x8002, \
METHOD_BUFFERED, \
FILE_ANY_ACCESS);

In user app:

long unsigned int switch_data = 0;

if(DeviceIoControl(hV3Device,
V3_IOCTL_READ_SWITCHES,
NULL,
0,
&switch_data,
sizeof(switch_data),
&nBytesTransferred,
NULL) == 0)
{
// ERROR, could not communicate to
device!!!
printf(“ERROR: could not communicate to
device!\n”);
printf(“Press return to quit”);
getc(stdin);
exit(1);
}

And from the driver (via windbg):

v3driver: Opened!!

v3driver: v3Ioctl

v3driver: Doing a “read switches”

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.IoControlCode = 0x8002

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.OutputBufferLength = 0x4

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.InputBufferLength = 0x0

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.Type3InputBuffer = 0x0

v3driver: read switches > Irp->AssociatedIrp.SystemBuffer = 0x0

Breakpoint 1 hit

v3driver!v3Ioctl+0x260:

Now I was under the impression that the System Buffer would be
defined by the output buffer if the input buffer was NULL. So why would
the
address be 0x0? This, of course is causing an access violation shortly
after. If I were to specify the output and input buffer, I would get a
reasonable address for the system buffer. This is strange.

Thanks in advance,

Howard Keller

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

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: xxxxx@cdp.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

7

The function code is wrong but if you apply the CTL_CODE macro then the
results will be 0x00220008. The access method is still FILE_ANY_ACCESS and
the device type is still 0x0022. If both the application and driver use the
CTL_CODE macro then they should get the same result.

Bill Wandel

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of Rob Green
Sent: Tuesday, February 10, 2004 6:39 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] system buffer address?

Function codes are only 12 bits. IOW 0x8002 is too big, and you are
screwing with the access method. The function number must be less than
0x1000.

Thanks,
Rob

#define V3_IOCTL_READ_SWITCHES CTL_CODE (FILE_DEVICE_UNKNOWN, \
0x8002, \
METHOD_BUFFERED, \
FILE_ANY_ACCESS);

In user app:

long unsigned int switch_data = 0;

if(DeviceIoControl(hV3Device,
V3_IOCTL_READ_SWITCHES,
NULL,
0,
&switch_data,
sizeof(switch_data),
&nBytesTransferred,
NULL) == 0)
{
// ERROR, could not communicate to
device!!!
printf(“ERROR: could not communicate to
device!\n”);
printf(“Press return to quit”);
getc(stdin);
exit(1);
}

And from the driver (via windbg):

v3driver: Opened!!

v3driver: v3Ioctl

v3driver: Doing a “read switches”

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.IoControlCode = 0x8002

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.OutputBufferLength = 0x4

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.InputBufferLength = 0x0

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.Type3InputBuffer = 0x0

v3driver: read switches > Irp->AssociatedIrp.SystemBuffer = 0x0

Breakpoint 1 hit

v3driver!v3Ioctl+0x260:

Now I was under the impression that the System Buffer would be
defined by the output buffer if the input buffer was NULL. So why
would the address be 0x0? This, of course is causing an access
violation shortly after. If I were to specify the output and input
buffer, I would get a reasonable address for the system buffer. This
is strange.

Thanks in advance,

Howard Keller

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

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: xxxxx@cdp.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: xxxxx@bwandel.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

8

No, result of CTL_CODE will be 0x20220008,so access method will become
FILE_DEVICE_TAPE_FILE_SYSTEM. So Rob is right.

Hope this help,
Dev

-----Original Message-----
From: Bill Wandel [mailto:xxxxx@bwandel.com]
Sent: Wednesday, February 11, 2004 6:30 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] system buffer address?

The function code is wrong but if you apply the CTL_CODE macro then the
results will be 0x00220008. The access method is still FILE_ANY_ACCESS and
the device type is still 0x0022. If both the application and driver use the
CTL_CODE macro then they should get the same result.

Bill Wandel

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of Rob Green
Sent: Tuesday, February 10, 2004 6:39 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] system buffer address?

Function codes are only 12 bits. IOW 0x8002 is too big, and you are
screwing with the access method. The function number must be less than
0x1000.

Thanks,
Rob

#define V3_IOCTL_READ_SWITCHES CTL_CODE (FILE_DEVICE_UNKNOWN, \
0x8002, \
METHOD_BUFFERED, \
FILE_ANY_ACCESS);

In user app:

long unsigned int switch_data = 0;

if(DeviceIoControl(hV3Device,
V3_IOCTL_READ_SWITCHES,
NULL,
0,
&switch_data,
sizeof(switch_data),
&nBytesTransferred,
NULL) == 0)
{
// ERROR, could not communicate to
device!!!
printf(“ERROR: could not communicate to
device!\n”);
printf(“Press return to quit”);
getc(stdin);
exit(1);
}

And from the driver (via windbg):

v3driver: Opened!!

v3driver: v3Ioctl

v3driver: Doing a “read switches”

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.IoControlCode = 0x8002

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.OutputBufferLength = 0x4

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.InputBufferLength = 0x0

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.Type3InputBuffer = 0x0

v3driver: read switches > Irp->AssociatedIrp.SystemBuffer = 0x0

Breakpoint 1 hit

v3driver!v3Ioctl+0x260:

Now I was under the impression that the System Buffer would be
defined by the output buffer if the input buffer was NULL. So why
would the address be 0x0? This, of course is causing an access
violation shortly after. If I were to specify the output and input
buffer, I would get a reasonable address for the system buffer. This
is strange.

Thanks in advance,

Howard Keller

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

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: xxxxx@cdp.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: xxxxx@bwandel.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: dsingh@in.rainbow.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

9

Also you may find this info about METHOD_BUFFERED useful:

user-mode perspective about this:

InBuffer - optional, contains data that is written to the driver
OutBuffer - optional, contains data that is read from the driver after the
call has completed

InBuffer and OutBuffer can be two buffers or a single shared buffer. If a
shared buffer, InBuffer is overwritten by OutBuffer.

I/O Manager perspective about this:

examines InBufferSize and OutBufferSize. Allocates memory from non-paged
pool and puts the address of this pool in Irp->AssociatedIrp.SystemBuffer.
The size of this buffer is equal to the size of the larger of the two
buffers. This buffer is accessible at any IRQL.

copies InBufferSize to irpSp->Parameters.DeviceIoControl.InputBufferLength
copies OutBufferSize to irpSp->Parameters.DeviceIoControl.OutputBufferLength
copies contents of InBuffer to SystemBuffer allocated above
calls your driver

Device Driver perspective about this:

you have one buffer, Irp->AssociatedIrp.SystemBuffer. You read input data
from this buffer and you write output data to the same buffer, overwriting
the input data.

Before calling IoCompleteRequest, you must

  • set IoStatus.Status to an appropriate NtStatus
  • if IoStatus.Status == STATUS_SUCCESS
    set IoStatus.Information to the number of bytes you want copied from the
    SystemBuffer back into OutBuffer.

I/O Manager Completion Routine perspective:

looks at IoStatus block, if IoStatus.Status = STATUS_SUCCESS, then copies
the number of bytes specified by IoStatus.Information from
Irp->AssociatedIrp.SystemBuffer into OutBuffer
completes the request

Dev
-----Original Message-----
From: dsingh@IN.rainbow.com [mailto:dsingh@IN.rainbow.com]
Sent: Wednesday, February 11, 2004 10:34 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] system buffer address?

No, result of CTL_CODE will be 0x20220008,so access method will become
FILE_DEVICE_TAPE_FILE_SYSTEM. So Rob is right.
Hope this help,
Dev
-----Original Message-----
From: Bill Wandel [mailto:xxxxx@bwandel.com]
Sent: Wednesday, February 11, 2004 6:30 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] system buffer address?

The function code is wrong but if you apply the CTL_CODE macro then the
results will be 0x00220008. The access method is still FILE_ANY_ACCESS and
the device type is still 0x0022. If both the application and driver use the
CTL_CODE macro then they should get the same result.
Bill Wandel
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]

On Behalf Of Rob Green
Sent: Tuesday, February 10, 2004 6:39 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] system buffer address?
Function codes are only 12 bits. IOW 0x8002 is too big, and you are
screwing with the access method. The function number must be less than
0x1000.
Thanks,
Rob

#define V3_IOCTL_READ_SWITCHES CTL_CODE (FILE_DEVICE_UNKNOWN, \
0x8002, \
METHOD_BUFFERED, \
FILE_ANY_ACCESS);

In user app:

long unsigned int switch_data = 0;

if(DeviceIoControl(hV3Device,
V3_IOCTL_READ_SWITCHES,
NULL,
0,
&switch_data,
sizeof(switch_data),
&nBytesTransferred,
NULL) == 0)
{
// ERROR, could not communicate to
device!!!
printf(“ERROR: could not communicate to
device!\n”);
printf(“Press return to quit”);
getc(stdin);
exit(1);
}

And from the driver (via windbg):

v3driver: Opened!!

v3driver: v3Ioctl

v3driver: Doing a “read switches”

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.IoControlCode = 0x8002

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.OutputBufferLength = 0x4

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.InputBufferLength = 0x0

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.Type3InputBuffer = 0x0

v3driver: read switches > Irp->AssociatedIrp.SystemBuffer = 0x0

Breakpoint 1 hit

v3driver!v3Ioctl+0x260:

Now I was under the impression that the System Buffer would be
defined by the output buffer if the input buffer was NULL. So why
would the address be 0x0? This, of course is causing an access
violation shortly after. If I were to specify the output and input
buffer, I would get a reasonable address for the system buffer. This
is strange.

Thanks in advance,

Howard Keller

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

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: xxxxx@cdp.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@bwandel.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: dsingh@in.rainbow.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: dsingh@in.rainbow.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

10

Bob,

Thanks for pointing that out. But unfortunately, that did not solve my
problems.

Thanks,

Howard
“Rob Green” wrote in message news:xxxxx@ntdev…
> Function codes are only 12 bits. IOW 0x8002 is too big, and you are
> screwing with the access method. The function number must be less than
> 0x1000.
>
> Thanks,
> Rob
>
>
> > #define V3_IOCTL_READ_SWITCHES CTL_CODE (FILE_DEVICE_UNKNOWN, <br>> > 0x8002, <br>> > METHOD_BUFFERED, <br>> > FILE_ANY_ACCESS);
> >
> > In user app:
> >
> > long unsigned int switch_data = 0;
> >
> > if(DeviceIoControl(hV3Device,
> > V3_IOCTL_READ_SWITCHES,
> > NULL,
> > 0,
> > &switch_data,
> > sizeof(switch_data),
> > &nBytesTransferred,
> > NULL) == 0)
> > {
> > // ERROR, could not communicate to
> > device!!!
> > printf(“ERROR: could not communicate to
> > device!\n”);
> > printf(“Press return to quit”);
> > getc(stdin);
> > exit(1);
> > }
> >
> > And from the driver (via windbg):
> >
> >
> > v3driver: Opened!!
> >
> > v3driver: v3Ioctl
> >
> > v3driver: Doing a “read switches”
> >
> > v3driver: read switches >
> > ioStack->Parameters.DeviceIoControl.IoControlCode = 0x8002
> >
> > v3driver: read switches >
> > ioStack->Parameters.DeviceIoControl.OutputBufferLength = 0x4
> >
> > v3driver: read switches >
> > ioStack->Parameters.DeviceIoControl.InputBufferLength = 0x0
> >
> > v3driver: read switches >
> > ioStack->Parameters.DeviceIoControl.Type3InputBuffer = 0x0
> >
> > v3driver: read switches > Irp->AssociatedIrp.SystemBuffer = 0x0
> >
> > Breakpoint 1 hit
> >
> > v3driver!v3Ioctl+0x260:
> >
> > Now I was under the impression that the System Buffer would be
> > defined by the output buffer if the input buffer was NULL. So why would
> > the
> > address be 0x0? This, of course is causing an access violation shortly
> > after. If I were to specify the output and input buffer, I would get a
> > reasonable address for the system buffer. This is strange.
> >
> > Thanks in advance,
> >
> > Howard Keller
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@stratus.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@cdp.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

11

not sure if anyone has asked yet - what OS are you running?

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of hkeller
Sent: Wednesday, February 11, 2004 8:11 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] system buffer address?

Bob,

Thanks for pointing that out. But unfortunately, that did not solve my
problems.

Thanks,

Howard
“Rob Green” wrote in message news:xxxxx@ntdev…
> Function codes are only 12 bits. IOW 0x8002 is too big, and you are
> screwing with the access method. The function number must be less
> than 0x1000.
>
> Thanks,
> Rob
>
>
> > #define V3_IOCTL_READ_SWITCHES CTL_CODE (FILE_DEVICE_UNKNOWN, <br>> > 0x8002, <br>> > METHOD_BUFFERED, <br>> > FILE_ANY_ACCESS);
> >
> > In user app:
> >
> > long unsigned int switch_data = 0;
> >
> > if(DeviceIoControl(hV3Device,
> > V3_IOCTL_READ_SWITCHES,
> > NULL,
> > 0,
> > &switch_data,
> > sizeof(switch_data),
> > &nBytesTransferred,
> > NULL) == 0)
> > {
> > // ERROR, could not communicate to
> > device!!!
> > printf(“ERROR: could not communicate to
> > device!\n”);
> > printf(“Press return to quit”);
> > getc(stdin);
> > exit(1);
> > }
> >
> > And from the driver (via windbg):
> >
> >
> > v3driver: Opened!!
> >
> > v3driver: v3Ioctl
> >
> > v3driver: Doing a “read switches”
> >
> > v3driver: read switches >
> > ioStack->Parameters.DeviceIoControl.IoControlCode = 0x8002
> >
> > v3driver: read switches >
> > ioStack->Parameters.DeviceIoControl.OutputBufferLength = 0x4
> >
> > v3driver: read switches >
> > ioStack->Parameters.DeviceIoControl.InputBufferLength = 0x0
> >
> > v3driver: read switches >
> > ioStack->Parameters.DeviceIoControl.Type3InputBuffer = 0x0
> >
> > v3driver: read switches > Irp->AssociatedIrp.SystemBuffer = 0x0
> >
> > Breakpoint 1 hit
> >
> > v3driver!v3Ioctl+0x260:
> >
> > Now I was under the impression that the System Buffer would be
> > defined by the output buffer if the input buffer was NULL. So why
> > would the address be 0x0? This, of course is causing an access
> > violation shortly after. If I were to specify the output and input
> > buffer, I would get a reasonable address for the system buffer. This

> > is strange.
> >
> > Thanks in advance,
> >
> > Howard Keller
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@stratus.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@cdp.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

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

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

12

We must be using different include files.
printf(“%08x\n”, CTL_CODE(FILE_DEVICE_UNKNOWN, \
0x8002, \
METHOD_BUFFERED, \
FILE_ANY_ACCESS))
prints 00220008

FILE_DEVICE_UNKNOWN << 16 = 0x00220000
Function code (0x8002) << 2 = 20008
FILE_ANY_ACCESS << 14 = 0000

Bill Wandel

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of dsingh@IN.rainbow.com
Sent: Wednesday, February 11, 2004 12:04 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] system buffer address?

No, result of CTL_CODE will be 0x20220008,so access method will become
FILE_DEVICE_TAPE_FILE_SYSTEM. So Rob is right.

Hope this help,
Dev

-----Original Message-----
From: Bill Wandel [mailto:xxxxx@bwandel.com]
Sent: Wednesday, February 11, 2004 6:30 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] system buffer address?

The function code is wrong but if you apply the CTL_CODE macro then the
results will be 0x00220008. The access method is still FILE_ANY_ACCESS and
the device type is still 0x0022. If both the application and driver use the
CTL_CODE macro then they should get the same result.

Bill Wandel

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]

On Behalf Of Rob Green
Sent: Tuesday, February 10, 2004 6:39 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] system buffer address?

Function codes are only 12 bits. IOW 0x8002 is too big, and you are
screwing with the access method. The function number must be less than
0x1000.

Thanks,
Rob

#define V3_IOCTL_READ_SWITCHES CTL_CODE (FILE_DEVICE_UNKNOWN, \
0x8002, \
METHOD_BUFFERED, \
FILE_ANY_ACCESS);

In user app:

long unsigned int switch_data = 0;

if(DeviceIoControl(hV3Device,
V3_IOCTL_READ_SWITCHES,
NULL,
0,
&switch_data,
sizeof(switch_data),
&nBytesTransferred,
NULL) == 0)
{
// ERROR, could not communicate to
device!!!
printf(“ERROR: could not communicate to
device!\n”);
printf(“Press return to quit”);
getc(stdin);
exit(1);
}

And from the driver (via windbg):

v3driver: Opened!!

v3driver: v3Ioctl

v3driver: Doing a “read switches”

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.IoControlCode = 0x8002

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.OutputBufferLength = 0x4

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.InputBufferLength = 0x0

v3driver: read switches >
ioStack->Parameters.DeviceIoControl.Type3InputBuffer = 0x0

v3driver: read switches > Irp->AssociatedIrp.SystemBuffer = 0x0

Breakpoint 1 hit

v3driver!v3Ioctl+0x260:

Now I was under the impression that the System Buffer would be
defined by the output buffer if the input buffer was NULL. So why
would the address be 0x0? This, of course is causing an access
violation shortly after. If I were to specify the output and input
buffer, I would get a reasonable address for the system buffer. This
is strange.

Thanks in advance,

Howard Keller

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

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: xxxxx@cdp.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: xxxxx@bwandel.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: dsingh@in.rainbow.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: xxxxx@bwandel.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

13

I’m running win2k sp3.

Howard

“Peter Wieland” wrote in message
news:xxxxx@ntdev…
not sure if anyone has asked yet - what OS are you running?

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of hkeller
Sent: Wednesday, February 11, 2004 8:11 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] system buffer address?

Bob,

Thanks for pointing that out. But unfortunately, that did not solve my
problems.

Thanks,

Howard
“Rob Green” wrote in message news:xxxxx@ntdev…
> Function codes are only 12 bits. IOW 0x8002 is too big, and you are
> screwing with the access method. The function number must be less
> than 0x1000.
>
> Thanks,
> Rob
>
>
> > #define V3_IOCTL_READ_SWITCHES CTL_CODE (FILE_DEVICE_UNKNOWN, <br>> > 0x8002, <br>> > METHOD_BUFFERED, <br>> > FILE_ANY_ACCESS);
> >
> > In user app:
> >
> > long unsigned int switch_data = 0;
> >
> > if(DeviceIoControl(hV3Device,
> > V3_IOCTL_READ_SWITCHES,
> > NULL,
> > 0,
> > &switch_data,
> > sizeof(switch_data),
> > &nBytesTransferred,
> > NULL) == 0)
> > {
> > // ERROR, could not communicate to
> > device!!!
> > printf(“ERROR: could not communicate to
> > device!\n”);
> > printf(“Press return to quit”);
> > getc(stdin);
> > exit(1);
> > }
> >
> > And from the driver (via windbg):
> >
> >
> > v3driver: Opened!!
> >
> > v3driver: v3Ioctl
> >
> > v3driver: Doing a “read switches”
> >
> > v3driver: read switches >
> > ioStack->Parameters.DeviceIoControl.IoControlCode = 0x8002
> >
> > v3driver: read switches >
> > ioStack->Parameters.DeviceIoControl.OutputBufferLength = 0x4
> >
> > v3driver: read switches >
> > ioStack->Parameters.DeviceIoControl.InputBufferLength = 0x0
> >
> > v3driver: read switches >
> > ioStack->Parameters.DeviceIoControl.Type3InputBuffer = 0x0
> >
> > v3driver: read switches > Irp->AssociatedIrp.SystemBuffer = 0x0
> >
> > Breakpoint 1 hit
> >
> > v3driver!v3Ioctl+0x260:
> >
> > Now I was under the impression that the System Buffer would be
> > defined by the output buffer if the input buffer was NULL. So why
> > would the address be 0x0? This, of course is causing an access
> > violation shortly after. If I were to specify the output and input
> > buffer, I would get a reasonable address for the system buffer. This

> > is strange.
> >
> > Thanks in advance,
> >
> > Howard Keller
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@stratus.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@cdp.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

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

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

14

and the next thing I can’t remember if we’ve asked: does the IRP happen
to have a valid MDL?

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of hkeller
Sent: Wednesday, February 11, 2004 5:13 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] system buffer address?

I’m running win2k sp3.

Howard

“Peter Wieland” wrote in message
news:xxxxx@ntdev…
not sure if anyone has asked yet - what OS are you running?

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of hkeller
Sent: Wednesday, February 11, 2004 8:11 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] system buffer address?

Bob,

Thanks for pointing that out. But unfortunately, that did not solve my
problems.

Thanks,

Howard
“Rob Green” wrote in message news:xxxxx@ntdev…
> Function codes are only 12 bits. IOW 0x8002 is too big, and you are
> screwing with the access method. The function number must be less
> than 0x1000.
>
> Thanks,
> Rob
>
>
> > #define V3_IOCTL_READ_SWITCHES CTL_CODE (FILE_DEVICE_UNKNOWN, <br>> > 0x8002, <br>> > METHOD_BUFFERED, <br>> > FILE_ANY_ACCESS);
> >
> > In user app:
> >
> > long unsigned int switch_data = 0;
> >
> > if(DeviceIoControl(hV3Device,
> > V3_IOCTL_READ_SWITCHES,
> > NULL,
> > 0,
> > &switch_data,
> > sizeof(switch_data),
> > &nBytesTransferred,
> > NULL) == 0)
> > {
> > // ERROR, could not communicate to
> > device!!!
> > printf(“ERROR: could not communicate to
> > device!\n”);
> > printf(“Press return to quit”);
> > getc(stdin);
> > exit(1);
> > }
> >
> > And from the driver (via windbg):
> >
> >
> > v3driver: Opened!!
> >
> > v3driver: v3Ioctl
> >
> > v3driver: Doing a “read switches”
> >
> > v3driver: read switches >
> > ioStack->Parameters.DeviceIoControl.IoControlCode = 0x8002
> >
> > v3driver: read switches >
> > ioStack->Parameters.DeviceIoControl.OutputBufferLength = 0x4
> >
> > v3driver: read switches >
> > ioStack->Parameters.DeviceIoControl.InputBufferLength = 0x0
> >
> > v3driver: read switches >
> > ioStack->Parameters.DeviceIoControl.Type3InputBuffer = 0x0
> >
> > v3driver: read switches > Irp->AssociatedIrp.SystemBuffer = 0x0
> >
> > Breakpoint 1 hit
> >
> > v3driver!v3Ioctl+0x260:
> >
> > Now I was under the impression that the System Buffer would be
> > defined by the output buffer if the input buffer was NULL. So why
> > would the address be 0x0? This, of course is causing an access
> > violation shortly after. If I were to specify the output and input
> > buffer, I would get a reasonable address for the system buffer. This

> > is strange.
> >
> > Thanks in advance,
> >
> > Howard Keller
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@stratus.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@cdp.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

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

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

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

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