Hi,
I am running the HCT 11.0 tests on Win XP OS, for the vendor specific USB
device. I am facing problem with “Device Path Exerciser” test in the
random test category.
When the IRP(IOCTL) is completed, the bug check “0x00000050” code(memory
access error) appears which shows access to Irp->UserBuffer for an write
operation. This happens after successfull testing with different IOCTL
values with and without data.
Also I observed that IOCTL_INTERNAL_USB_SUBMIT_URB uses METHOD_NEITHER and
as per documentation, Irp->UserBuffer should contain the address of output
buffer. But neither in the documentation nor in the samples the value
Irp->UserBuffer being populated.
Could someone please tell me if i am missing something.
Regards,
Shashi
Shashidhar wrote:
Also I observed that IOCTL_INTERNAL_USB_SUBMIT_URB uses METHOD_NEITHER and
as per documentation, Irp->UserBuffer should contain the address of output
buffer. But neither in the documentation nor in the samples the value
Irp->UserBuffer being populated.
There are basically no rules at all for internal IOCTL requests. The
designers of the USB bus driver elected to use this type of IRP as an
envelope to contain a URB, but the USB_SUBMIT_URB request doesn’t use
either the input or or output buffers.
–
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
This part is fine and works, but I am not able to find the reason for
the page fault that is happening while for some reason IO manager is
trying to access Irp->UserBuffer during the completion of the IRP.
I am reusing the IRP sent for IOCTL to send the URB request down the
stack, I hope this does not cause any problem…(and completing this IRP
synchronously by waiting for the sent request to complete).
Any guess what is happening?
-----Original Message-----
From: Walter Oney [mailto:xxxxx@oneysoft.com]
Sent: Sunday, February 23, 2003 7:21 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Shashidhar wrote:
Also I observed that IOCTL_INTERNAL_USB_SUBMIT_URB uses METHOD_NEITHER
and as per documentation, Irp->UserBuffer should contain the address
of output buffer. But neither in the documentation nor in the samples
the value
Irp->UserBuffer being populated.
There are basically no rules at all for internal IOCTL requests. The
designers of the USB bus driver elected to use this type of IRP as an
envelope to contain a URB, but the USB_SUBMIT_URB request doesn’t use
either the input or or output buffers.
–
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
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Shashidhar R wrote:
This part is fine and works, but I am not able to find the reason for
the page fault that is happening while for some reason IO manager is
trying to access Irp->UserBuffer during the completion of the IRP.
I am reusing the IRP sent for IOCTL to send the URB request down the
stack, I hope this does not cause any problem…(and completing this IRP
synchronously by waiting for the sent request to complete).
Any guess what is happening?
Let’s see if I understand your situation correctly:
Someone sends you an IRP_MJ_DEVICE_CONTROL. You use
IoGetNextIrpStackLocation to get a pointer to the next stack location,
which you fill with MajorFunction = IRP_MJ_INTERNAL_DEVICE_CONTROL,
Parameters.DeviceIoControl.IoControlCode =
IOCTL_INTERNAL_USB_SUBMIT_URB, and Parameters.Others.Argument1 = URB
address. Then you install a completion routine and call IoCallDriver.
The completion routine will call KeSetEvent on some event you’ve
initialized. If the lower driver returns STATUS_PENDING, you wait on the
event. Then you call IoCompleteRequest on this IRP, possibly after doing
some additional post processing. Is this correct? It may be more complex
than you need, but it should work fine – I’ve piggy backed URBs on
IRP_MJ_READ and IRP_MJ_WRITE techniques in countless drivers without
having any problem, and there’s nothing about an IRP_MJ_DEVICE_CONTROL
that would be different in a way that matters.
–
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
Yes this is the exact thing I am doing, and it works fine with all the
normal ioctl’s but fails only when I run the HCT tests…
I would like to know what is the use of the field IRP->UserBuffer, and
what is that IO manager is trying to write into it.
-----Original Message-----
From: Walter Oney [mailto:xxxxx@oneysoft.com]
Sent: Monday, February 24, 2003 4:02 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Shashidhar R wrote:
This part is fine and works, but I am not able to find the reason for
the page fault that is happening while for some reason IO manager is
trying to access Irp->UserBuffer during the completion of the IRP. I
am reusing the IRP sent for IOCTL to send the URB request down the
stack, I hope this does not cause any problem…(and completing this
IRP synchronously by waiting for the sent request to complete). Any
guess what is happening?
Let’s see if I understand your situation correctly:
Someone sends you an IRP_MJ_DEVICE_CONTROL. You use
IoGetNextIrpStackLocation to get a pointer to the next stack location,
which you fill with MajorFunction = IRP_MJ_INTERNAL_DEVICE_CONTROL,
Parameters.DeviceIoControl.IoControlCode =
IOCTL_INTERNAL_USB_SUBMIT_URB, and Parameters.Others.Argument1 = URB
address. Then you install a completion routine and call IoCallDriver.
The completion routine will call KeSetEvent on some event you’ve
initialized. If the lower driver returns STATUS_PENDING, you wait on the
event. Then you call IoCompleteRequest on this IRP, possibly after doing
some additional post processing. Is this correct? It may be more complex
than you need, but it should work fine – I’ve piggy backed URBs on
IRP_MJ_READ and IRP_MJ_WRITE techniques in countless drivers without
having any problem, and there’s nothing about an IRP_MJ_DEVICE_CONTROL
that would be different in a way that matters.
–
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
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Also my IOCTL is declared using METHOD_BUFFERED, so the user buffer
should not have any data. But it is containg some pointer (0xfffffc00)
also the system buffer field is valid.
-----Original Message-----
From: Shashidhar R
Sent: Monday, February 24, 2003 5:27 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Yes this is the exact thing I am doing, and it works fine with all the
normal ioctl’s but fails only when I run the HCT tests… I would like
to know what is the use of the field IRP->UserBuffer, and what is that
IO manager is trying to write into it.
-----Original Message-----
From: Walter Oney [mailto:xxxxx@oneysoft.com]
Sent: Monday, February 24, 2003 4:02 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Shashidhar R wrote:
This part is fine and works, but I am not able to find the reason for
the page fault that is happening while for some reason IO manager is
trying to access Irp->UserBuffer during the completion of the IRP. I
am reusing the IRP sent for IOCTL to send the URB request down the
stack, I hope this does not cause any problem…(and completing this
IRP synchronously by waiting for the sent request to complete). Any
guess what is happening?
Let’s see if I understand your situation correctly:
Someone sends you an IRP_MJ_DEVICE_CONTROL. You use
IoGetNextIrpStackLocation to get a pointer to the next stack location,
which you fill with MajorFunction = IRP_MJ_INTERNAL_DEVICE_CONTROL,
Parameters.DeviceIoControl.IoControlCode =
IOCTL_INTERNAL_USB_SUBMIT_URB, and Parameters.Others.Argument1 = URB
address. Then you install a completion routine and call IoCallDriver.
The completion routine will call KeSetEvent on some event you’ve
initialized. If the lower driver returns STATUS_PENDING, you wait on the
event. Then you call IoCompleteRequest on this IRP, possibly after doing
some additional post processing. Is this correct? It may be more complex
than you need, but it should work fine – I’ve piggy backed URBs on
IRP_MJ_READ and IRP_MJ_WRITE techniques in countless drivers without
having any problem, and there’s nothing about an IRP_MJ_DEVICE_CONTROL
that would be different in a way that matters.
–
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
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Irp->UserBuffer is the user mode address of the output buffer (specified in
the DeviceIoCtrl call) that the I/O Manager puts in the irp. When the Irp
is completed and the IoManager needs to copy the SystemBuffer back to the
user address space it has the saved address in Irp->UserBuffer to use.
Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
“Shashidhar R” wrote in message
news:xxxxx@ntdev…
Also my IOCTL is declared using METHOD_BUFFERED, so the user buffer
should not have any data. But it is containg some pointer (0xfffffc00)
also the system buffer field is valid.
-----Original Message-----
From: Shashidhar R
Sent: Monday, February 24, 2003 5:27 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Yes this is the exact thing I am doing, and it works fine with all the
normal ioctl’s but fails only when I run the HCT tests… I would like
to know what is the use of the field IRP->UserBuffer, and what is that
IO manager is trying to write into it.
-----Original Message-----
From: Walter Oney [mailto:xxxxx@oneysoft.com]
Sent: Monday, February 24, 2003 4:02 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Shashidhar R wrote:
> This part is fine and works, but I am not able to find the reason for
> the page fault that is happening while for some reason IO manager is
> trying to access Irp->UserBuffer during the completion of the IRP. I
> am reusing the IRP sent for IOCTL to send the URB request down the
> stack, I hope this does not cause any problem…(and completing this
> IRP synchronously by waiting for the sent request to complete). Any
> guess what is happening?
Let’s see if I understand your situation correctly:
Someone sends you an IRP_MJ_DEVICE_CONTROL. You use
IoGetNextIrpStackLocation to get a pointer to the next stack location,
which you fill with MajorFunction = IRP_MJ_INTERNAL_DEVICE_CONTROL,
Parameters.DeviceIoControl.IoControlCode =
IOCTL_INTERNAL_USB_SUBMIT_URB, and Parameters.Others.Argument1 = URB
address. Then you install a completion routine and call IoCallDriver.
The completion routine will call KeSetEvent on some event you’ve
initialized. If the lower driver returns STATUS_PENDING, you wait on the
event. Then you call IoCompleteRequest on this IRP, possibly after doing
some additional post processing. Is this correct? It may be more complex
than you need, but it should work fine – I’ve piggy backed URBs on
IRP_MJ_READ and IRP_MJ_WRITE techniques in countless drivers without
having any problem, and there’s nothing about an IRP_MJ_DEVICE_CONTROL
that would be different in a way that matters.
–
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
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
The crash occurs even when I copy some junk data and return it back. Is
it necessary to validate the user buffer is valid by probing by the
driver(I think this is not necessary if the IOCTL is buffered).
-----Original Message-----
From: Mark Cariddi [mailto:xxxxx@osr.com]
Sent: Monday, February 24, 2003 6:53 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Irp->UserBuffer is the user mode address of the output buffer (specified
Irp->in
the DeviceIoCtrl call) that the I/O Manager puts in the irp. When the
Irp
is completed and the IoManager needs to copy the SystemBuffer back to
the user address space it has the saved address in Irp->UserBuffer to
use.
Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
“Shashidhar R” wrote in message
news:xxxxx@ntdev…
Also my IOCTL is declared using METHOD_BUFFERED, so the user buffer
should not have any data. But it is containg some pointer (0xfffffc00)
also the system buffer field is valid.
-----Original Message-----
From: Shashidhar R
Sent: Monday, February 24, 2003 5:27 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Yes this is the exact thing I am doing, and it works fine with all the
normal ioctl’s but fails only when I run the HCT tests… I would like
to know what is the use of the field IRP->UserBuffer, and what is that
IO manager is trying to write into it.
-----Original Message-----
From: Walter Oney [mailto:xxxxx@oneysoft.com]
Sent: Monday, February 24, 2003 4:02 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Shashidhar R wrote:
> This part is fine and works, but I am not able to find the reason for
> the page fault that is happening while for some reason IO manager is
> trying to access Irp->UserBuffer during the completion of the IRP. I
> am reusing the IRP sent for IOCTL to send the URB request down the
> stack, I hope this does not cause any problem…(and completing this
> IRP synchronously by waiting for the sent request to complete). Any
> guess what is happening?
Let’s see if I understand your situation correctly:
Someone sends you an IRP_MJ_DEVICE_CONTROL. You use
IoGetNextIrpStackLocation to get a pointer to the next stack location,
which you fill with MajorFunction = IRP_MJ_INTERNAL_DEVICE_CONTROL,
Parameters.DeviceIoControl.IoControlCode =
IOCTL_INTERNAL_USB_SUBMIT_URB, and Parameters.Others.Argument1 = URB
address. Then you install a completion routine and call IoCallDriver.
The completion routine will call KeSetEvent on some event you’ve
initialized. If the lower driver returns STATUS_PENDING, you wait on the
event. Then you call IoCompleteRequest on this IRP, possibly after doing
some additional post processing. Is this correct? It may be more complex
than you need, but it should work fine – I’ve piggy backed URBs on
IRP_MJ_READ and IRP_MJ_WRITE techniques in countless drivers without
having any problem, and there’s nothing about an IRP_MJ_DEVICE_CONTROL
that would be different in a way that matters.
–
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
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
When using METHOD_BUFFERED Irp->UserBuffer has been validated by the I/O
Manager (if the Irp came from user mode). When you get the Irp to process
do you validate the size of the output buffer passed to you? Could its size
be zero?
–
Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
“Shashidhar R” wrote in message
news:xxxxx@ntdev…
The crash occurs even when I copy some junk data and return it back. Is
it necessary to validate the user buffer is valid by probing by the
driver(I think this is not necessary if the IOCTL is buffered).
-----Original Message-----
From: Mark Cariddi [mailto:xxxxx@osr.com]
Sent: Monday, February 24, 2003 6:53 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Irp->UserBuffer is the user mode address of the output buffer (specified
Irp->in
the DeviceIoCtrl call) that the I/O Manager puts in the irp. When the
Irp
is completed and the IoManager needs to copy the SystemBuffer back to
the user address space it has the saved address in Irp->UserBuffer to
use.
Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
“Shashidhar R” wrote in message
news:xxxxx@ntdev…
Also my IOCTL is declared using METHOD_BUFFERED, so the user buffer
should not have any data. But it is containg some pointer (0xfffffc00)
also the system buffer field is valid.
-----Original Message-----
From: Shashidhar R
Sent: Monday, February 24, 2003 5:27 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Yes this is the exact thing I am doing, and it works fine with all the
normal ioctl’s but fails only when I run the HCT tests… I would like
to know what is the use of the field IRP->UserBuffer, and what is that
IO manager is trying to write into it.
-----Original Message-----
From: Walter Oney [mailto:xxxxx@oneysoft.com]
Sent: Monday, February 24, 2003 4:02 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Shashidhar R wrote:
> This part is fine and works, but I am not able to find the reason for
> the page fault that is happening while for some reason IO manager is
> trying to access Irp->UserBuffer during the completion of the IRP. I
> am reusing the IRP sent for IOCTL to send the URB request down the
> stack, I hope this does not cause any problem…(and completing this
> IRP synchronously by waiting for the sent request to complete). Any
> guess what is happening?
Let’s see if I understand your situation correctly:
Someone sends you an IRP_MJ_DEVICE_CONTROL. You use
IoGetNextIrpStackLocation to get a pointer to the next stack location,
which you fill with MajorFunction = IRP_MJ_INTERNAL_DEVICE_CONTROL,
Parameters.DeviceIoControl.IoControlCode =
IOCTL_INTERNAL_USB_SUBMIT_URB, and Parameters.Others.Argument1 = URB
address. Then you install a completion routine and call IoCallDriver.
The completion routine will call KeSetEvent on some event you’ve
initialized. If the lower driver returns STATUS_PENDING, you wait on the
event. Then you call IoCompleteRequest on this IRP, possibly after doing
some additional post processing. Is this correct? It may be more complex
than you need, but it should work fine – I’ve piggy backed URBs on
IRP_MJ_READ and IRP_MJ_WRITE techniques in countless drivers without
having any problem, and there’s nothing about an IRP_MJ_DEVICE_CONTROL
that would be different in a way that matters.
–
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
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
I have validated the size of out buffer and also the length is less than
what I am filling up now. Also if the buffer length is wrong trying to
write to system buffer itself should cause the crash. I have also
validated the data size being indicated back to the io manager in the
IRP.
-----Original Message-----
From: Mark Cariddi [mailto:xxxxx@osr.com]
Sent: Monday, February 24, 2003 7:33 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
When using METHOD_BUFFERED Irp->UserBuffer has been validated by the I/O
Manager (if the Irp came from user mode). When you get the Irp to
process do you validate the size of the output buffer passed to you?
Could its size be zero?
–
Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
“Shashidhar R” wrote in message
news:xxxxx@ntdev…
The crash occurs even when I copy some junk data and return it back. Is
it necessary to validate the user buffer is valid by probing by the
driver(I think this is not necessary if the IOCTL is buffered).
-----Original Message-----
From: Mark Cariddi [mailto:xxxxx@osr.com]
Sent: Monday, February 24, 2003 6:53 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Irp->UserBuffer is the user mode address of the output buffer (specified
Irp->in
the DeviceIoCtrl call) that the I/O Manager puts in the irp. When the
Irp
is completed and the IoManager needs to copy the SystemBuffer back to
the user address space it has the saved address in Irp->UserBuffer to
use.
Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
“Shashidhar R” wrote in message
news:xxxxx@ntdev…
Also my IOCTL is declared using METHOD_BUFFERED, so the user buffer
should not have any data. But it is containg some pointer (0xfffffc00)
also the system buffer field is valid.
-----Original Message-----
From: Shashidhar R
Sent: Monday, February 24, 2003 5:27 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Yes this is the exact thing I am doing, and it works fine with all the
normal ioctl’s but fails only when I run the HCT tests… I would like
to know what is the use of the field IRP->UserBuffer, and what is that
IO manager is trying to write into it.
-----Original Message-----
From: Walter Oney [mailto:xxxxx@oneysoft.com]
Sent: Monday, February 24, 2003 4:02 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Shashidhar R wrote:
> This part is fine and works, but I am not able to find the reason for
> the page fault that is happening while for some reason IO manager is
> trying to access Irp->UserBuffer during the completion of the IRP. I
> am reusing the IRP sent for IOCTL to send the URB request down the
> stack, I hope this does not cause any problem…(and completing this
> IRP synchronously by waiting for the sent request to complete). Any
> guess what is happening?
Let’s see if I understand your situation correctly:
Someone sends you an IRP_MJ_DEVICE_CONTROL. You use
IoGetNextIrpStackLocation to get a pointer to the next stack location,
which you fill with MajorFunction = IRP_MJ_INTERNAL_DEVICE_CONTROL,
Parameters.DeviceIoControl.IoControlCode =
IOCTL_INTERNAL_USB_SUBMIT_URB, and Parameters.Others.Argument1 = URB
address. Then you install a completion routine and call IoCallDriver.
The completion routine will call KeSetEvent on some event you’ve
initialized. If the lower driver returns STATUS_PENDING, you wait on the
event. Then you call IoCompleteRequest on this IRP, possibly after doing
some additional post processing. Is this correct? It may be more complex
than you need, but it should work fine – I’ve piggy backed URBs on
IRP_MJ_READ and IRP_MJ_WRITE techniques in countless drivers without
having any problem, and there’s nothing about an IRP_MJ_DEVICE_CONTROL
that would be different in a way that matters.
–
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
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Shashidhar R wrote:
I have validated the size of out buffer and also the length is less than
what I am filling up now. Also if the buffer length is wrong trying to
write to system buffer itself should cause the crash. I have also
validated the data size being indicated back to the io manager in the
IRP.
How about trying the following, then. KdPrint the value of UserBuffer
before you send the IRP down the stack and afterwards. It should not
change, but the fact that you’re seeing FFFFFC00 is very suspect – this
is a *kernel* address, rather than a user-mode virtual address. Then use
your debugger to see who’s changing it. If worst comes to worst, you’ll
need to save and restore this value across the call down the stack.
–
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
I have tried the same and it does not change, now I am just filling up
the system buffer with some data and returning immediately with success.
The time the IOCTL with bufferlength >0 and some address in the
UserBuffer is sent, this crash happens.
Note that this is happening with HCT alone not with normal issuing of
IOCTL’s from my own application…(This is the point I am trying to
understand, is HCT trying to create some scenarios of security
validation of drivers. If so what is this check and how do I address
it).
-----Original Message-----
From: Walter Oney [mailto:xxxxx@oneysoft.com]
Sent: Monday, February 24, 2003 9:49 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Shashidhar R wrote:
I have validated the size of out buffer and also the length is less
than what I am filling up now. Also if the buffer length is wrong
trying to write to system buffer itself should cause the crash. I have
also validated the data size being indicated back to the io manager in
the IRP.
How about trying the following, then. KdPrint the value of UserBuffer
before you send the IRP down the stack and afterwards. It should not
change, but the fact that you’re seeing FFFFFC00 is very suspect – this
is a *kernel* address, rather than a user-mode virtual address. Then use
your debugger to see who’s changing it. If worst comes to worst, you’ll
need to save and restore this value across the call down the stack.
–
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
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
>>I have validated the size of out buffer and also the length is less
than
what I am filling up now.
>Also if the buffer length is wrong trying to
write to system buffer itself should cause the crash.
[Sathya] It is not true always. Size of system buffer is MAXIMUM size of
in or out buffer. For eg, if in buffer is 2k and out buffer is 1k,
system buffer allocated by i/o manager would be of 2k size and EVEN WHEN
YOU WRITE 2K BYTES INTO SYSTEM BUFFER, it will not crash. But, one
behaviour I noticed in NT4 that was, I/O MANAGER BLINDLY WRITES DATA
FROM SYSTEM BUFFER BACK TO “OutBuffer” specified in “DeviceIoControl”
for size specified by driver in IO_STATUS_BLOCK (IoStatus.Information
field, which specifies total number of bytes copied back into System
Buffer). It didn’t check whether the out buffer has enough room to hold
data of this size OR if the size specified by driver is > the size
specified by “OutBufferSize” passed in “DeviceIoControl”. It was
crashing for me earlier in NT4. Not sure if this bug is carried still.
>I have also
validated the data size being indicated back to the io manager in the
IRP.
-----Original Message-----
From: Mark Cariddi [mailto:xxxxx@osr.com]
Sent: Monday, February 24, 2003 7:33 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
When using METHOD_BUFFERED Irp->UserBuffer has been validated by the I/O
Manager (if the Irp came from user mode). When you get the Irp to
process do you validate the size of the output buffer passed to you?
Could its size be zero?
–
Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
“Shashidhar R” wrote in message
news:xxxxx@ntdev…
The crash occurs even when I copy some junk data and return it back. Is
it necessary to validate the user buffer is valid by probing by the
driver(I think this is not necessary if the IOCTL is buffered).
-----Original Message-----
From: Mark Cariddi [mailto:xxxxx@osr.com]
Sent: Monday, February 24, 2003 6:53 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Irp->UserBuffer is the user mode address of the output buffer (specified
Irp->in
the DeviceIoCtrl call) that the I/O Manager puts in the irp. When the
Irp
is completed and the IoManager needs to copy the SystemBuffer back to
the user address space it has the saved address in Irp->UserBuffer to
use.
Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
“Shashidhar R” wrote in message
news:xxxxx@ntdev…
Also my IOCTL is declared using METHOD_BUFFERED, so the user buffer
should not have any data. But it is containg some pointer (0xfffffc00)
also the system buffer field is valid.
-----Original Message-----
From: Shashidhar R
Sent: Monday, February 24, 2003 5:27 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Yes this is the exact thing I am doing, and it works fine with all the
normal ioctl’s but fails only when I run the HCT tests… I would like
to know what is the use of the field IRP->UserBuffer, and what is that
IO manager is trying to write into it.
-----Original Message-----
From: Walter Oney [mailto:xxxxx@oneysoft.com]
Sent: Monday, February 24, 2003 4:02 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Shashidhar R wrote:
> This part is fine and works, but I am not able to find the reason for
> the page fault that is happening while for some reason IO manager is
> trying to access Irp->UserBuffer during the completion of the IRP. I
> am reusing the IRP sent for IOCTL to send the URB request down the
> stack, I hope this does not cause any problem…(and completing this
> IRP synchronously by waiting for the sent request to complete). Any
> guess what is happening?
Let’s see if I understand your situation correctly:
Someone sends you an IRP_MJ_DEVICE_CONTROL. You use
IoGetNextIrpStackLocation to get a pointer to the next stack location,
which you fill with MajorFunction = IRP_MJ_INTERNAL_DEVICE_CONTROL,
Parameters.DeviceIoControl.IoControlCode =
IOCTL_INTERNAL_USB_SUBMIT_URB, and Parameters.Others.Argument1 = URB
address. Then you install a completion routine and call IoCallDriver.
The completion routine will call KeSetEvent on some event you’ve
initialized. If the lower driver returns STATUS_PENDING, you wait on the
event. Then you call IoCompleteRequest on this IRP, possibly after doing
some additional post processing. Is this correct? It may be more complex
than you need, but it should work fine – I’ve piggy backed URBs on
IRP_MJ_READ and IRP_MJ_WRITE techniques in countless drivers without
having any problem, and there’s nothing about an IRP_MJ_DEVICE_CONTROL
that would be different in a way that matters.
–
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
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Shashidhar R wrote:
I have tried the same and it does not change, now I am just filling up
the system buffer with some data and returning immediately with success.
The time the IOCTL with bufferlength >0 and some address in the
UserBuffer is sent, this crash happens.
Note that this is happening with HCT alone not with normal issuing of
IOCTL’s from my own application…(This is the point I am trying to
understand, is HCT trying to create some scenarios of security
validation of drivers. If so what is this check and how do I address
it).
I’m stumped too. You may be right that this error is in the test rather
than in your driver. Perhaps you’ll get more information at
microsoft.public.windowsxp.winlogo on the msnews.microsoft.com server.
–
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
The NT4 behavior is unfortunate, but it’s not really a bug in the
operating system. While Windows does check to make sure the supplied
buffers are valid (ie - the pages are mapped for read or write as
appropriate) the driver is responsible for ensuring that it doesn’t tell
windows to transfer more data to the application than the application
requested.
-p
-----Original Message-----
From: Sathyanarayanan Srinivasan
[mailto:xxxxx@wipro.com]
Sent: Monday, February 24, 2003 9:29 PM
To: NT Developers Interest List
>I have validated the size of out buffer and also the length is less
than
what I am filling up now.
>Also if the buffer length is wrong trying to
write to system buffer itself should cause the crash.
[Sathya] It is not true always. Size of system buffer is MAXIMUM size of
in or out buffer. For eg, if in buffer is 2k and out buffer is 1k,
system buffer allocated by i/o manager would be of 2k size and EVEN WHEN
YOU WRITE 2K BYTES INTO SYSTEM BUFFER, it will not crash. But, one
behaviour I noticed in NT4 that was, I/O MANAGER BLINDLY WRITES DATA
FROM SYSTEM BUFFER BACK TO “OutBuffer” specified in “DeviceIoControl”
for size specified by driver in IO_STATUS_BLOCK (IoStatus.Information
field, which specifies total number of bytes copied back into System
Buffer). It didn’t check whether the out buffer has enough room to hold
data of this size OR if the size specified by driver is > the size
specified by “OutBufferSize” passed in “DeviceIoControl”. It was
crashing for me earlier in NT4. Not sure if this bug is carried still.
>I have also
validated the data size being indicated back to the io manager in the
IRP.
-----Original Message-----
From: Mark Cariddi [mailto:xxxxx@osr.com]
Sent: Monday, February 24, 2003 7:33 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
When using METHOD_BUFFERED Irp->UserBuffer has been validated by the I/O
Manager (if the Irp came from user mode). When you get the Irp to
process do you validate the size of the output buffer passed to you?
Could its size be zero?
–
Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
“Shashidhar R” wrote in message
news:xxxxx@ntdev…
The crash occurs even when I copy some junk data and return it back. Is
it necessary to validate the user buffer is valid by probing by the
driver(I think this is not necessary if the IOCTL is buffered).
-----Original Message-----
From: Mark Cariddi [mailto:xxxxx@osr.com]
Sent: Monday, February 24, 2003 6:53 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Irp->UserBuffer is the user mode address of the output buffer (specified
Irp->in
the DeviceIoCtrl call) that the I/O Manager puts in the irp. When the
Irp
is completed and the IoManager needs to copy the SystemBuffer back to
the user address space it has the saved address in Irp->UserBuffer to
use.
Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
“Shashidhar R” wrote in message
news:xxxxx@ntdev…
Also my IOCTL is declared using METHOD_BUFFERED, so the user buffer
should not have any data. But it is containg some pointer (0xfffffc00)
also the system buffer field is valid.
-----Original Message-----
From: Shashidhar R
Sent: Monday, February 24, 2003 5:27 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Yes this is the exact thing I am doing, and it works fine with all the
normal ioctl’s but fails only when I run the HCT tests… I would like
to know what is the use of the field IRP->UserBuffer, and what is that
IO manager is trying to write into it.
-----Original Message-----
From: Walter Oney [mailto:xxxxx@oneysoft.com]
Sent: Monday, February 24, 2003 4:02 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Shashidhar R wrote:
> This part is fine and works, but I am not able to find the reason for
> the page fault that is happening while for some reason IO manager is
> trying to access Irp->UserBuffer during the completion of the IRP. I
> am reusing the IRP sent for IOCTL to send the URB request down the
> stack, I hope this does not cause any problem…(and completing this
> IRP synchronously by waiting for the sent request to complete). Any
> guess what is happening?
Let’s see if I understand your situation correctly:
Someone sends you an IRP_MJ_DEVICE_CONTROL. You use
IoGetNextIrpStackLocation to get a pointer to the next stack location,
which you fill with MajorFunction = IRP_MJ_INTERNAL_DEVICE_CONTROL,
Parameters.DeviceIoControl.IoControlCode =
IOCTL_INTERNAL_USB_SUBMIT_URB, and Parameters.Others.Argument1 = URB
address. Then you install a completion routine and call IoCallDriver.
The completion routine will call KeSetEvent on some event you’ve
initialized. If the lower driver returns STATUS_PENDING, you wait on the
event. Then you call IoCompleteRequest on this IRP, possibly after doing
some additional post processing. Is this correct? It may be more complex
than you need, but it should work fine – I’ve piggy backed URBs on
IRP_MJ_READ and IRP_MJ_WRITE techniques in countless drivers without
having any problem, and there’s nothing about an IRP_MJ_DEVICE_CONTROL
that would be different in a way that matters.
–
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
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Hi Peter,
I had checked the size of data and ensured that the size is less than
what is requested even then it causes an crash so I am now trying to
first validate the userbuffer for read/write. I will indicate the
results latter but I think this is not what is expected on Win2K and
WinXP.
-Shashi
-----Original Message-----
From: Peter Wieland [mailto:xxxxx@windows.microsoft.com]
Sent: Tuesday, February 25, 2003 10:20 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with HCT 11.0
The NT4 behavior is unfortunate, but it’s not really a bug in the
operating system. While Windows does check to make sure the supplied
buffers are valid (ie - the pages are mapped for read or write as
appropriate) the driver is responsible for ensuring that it doesn’t tell
windows to transfer more data to the application than the application
requested.
-p
-----Original Message-----
From: Sathyanarayanan Srinivasan
[mailto:xxxxx@wipro.com]
Sent: Monday, February 24, 2003 9:29 PM
To: NT Developers Interest List
>I have validated the size of out buffer and also the length is less
than
what I am filling up now.
>Also if the buffer length is wrong trying to
write to system buffer itself should cause the crash.
[Sathya] It is not true always. Size of system buffer is MAXIMUM size of
in or out buffer. For eg, if in buffer is 2k and out buffer is 1k,
system buffer allocated by i/o manager would be of 2k size and EVEN WHEN
YOU WRITE 2K BYTES INTO SYSTEM BUFFER, it will not crash. But, one
behaviour I noticed in NT4 that was, I/O MANAGER BLINDLY WRITES DATA
FROM SYSTEM BUFFER BACK TO “OutBuffer” specified in “DeviceIoControl”
for size specified by driver in IO_STATUS_BLOCK (IoStatus.Information
field, which specifies total number of bytes copied back into System
Buffer). It didn’t check whether the out buffer has enough room to hold
data of this size OR if the size specified by driver is > the size
specified by “OutBufferSize” passed in “DeviceIoControl”. It was
crashing for me earlier in NT4. Not sure if this bug is carried still.
>I have also
validated the data size being indicated back to the io manager in the
IRP.
-----Original Message-----
From: Mark Cariddi [mailto:xxxxx@osr.com]
Sent: Monday, February 24, 2003 7:33 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
When using METHOD_BUFFERED Irp->UserBuffer has been validated by the I/O
Manager (if the Irp came from user mode). When you get the Irp to
process do you validate the size of the output buffer passed to you?
Could its size be zero?
–
Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
“Shashidhar R” wrote in message
news:xxxxx@ntdev…
The crash occurs even when I copy some junk data and return it back. Is
it necessary to validate the user buffer is valid by probing by the
driver(I think this is not necessary if the IOCTL is buffered).
-----Original Message-----
From: Mark Cariddi [mailto:xxxxx@osr.com]
Sent: Monday, February 24, 2003 6:53 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Irp->UserBuffer is the user mode address of the output buffer (specified
Irp->in
the DeviceIoCtrl call) that the I/O Manager puts in the irp. When the
Irp
is completed and the IoManager needs to copy the SystemBuffer back to
the user address space it has the saved address in Irp->UserBuffer to
use.
Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
“Shashidhar R” wrote in message
news:xxxxx@ntdev…
Also my IOCTL is declared using METHOD_BUFFERED, so the user buffer
should not have any data. But it is containg some pointer (0xfffffc00)
also the system buffer field is valid.
-----Original Message-----
From: Shashidhar R
Sent: Monday, February 24, 2003 5:27 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Yes this is the exact thing I am doing, and it works fine with all the
normal ioctl’s but fails only when I run the HCT tests… I would like
to know what is the use of the field IRP->UserBuffer, and what is that
IO manager is trying to write into it.
-----Original Message-----
From: Walter Oney [mailto:xxxxx@oneysoft.com]
Sent: Monday, February 24, 2003 4:02 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Shashidhar R wrote:
> This part is fine and works, but I am not able to find the reason for
> the page fault that is happening while for some reason IO manager is
> trying to access Irp->UserBuffer during the completion of the IRP. I
> am reusing the IRP sent for IOCTL to send the URB request down the
> stack, I hope this does not cause any problem…(and completing this
> IRP synchronously by waiting for the sent request to complete). Any
> guess what is happening?
Let’s see if I understand your situation correctly:
Someone sends you an IRP_MJ_DEVICE_CONTROL. You use
IoGetNextIrpStackLocation to get a pointer to the next stack location,
which you fill with MajorFunction = IRP_MJ_INTERNAL_DEVICE_CONTROL,
Parameters.DeviceIoControl.IoControlCode =
IOCTL_INTERNAL_USB_SUBMIT_URB, and Parameters.Others.Argument1 = URB
address. Then you install a completion routine and call IoCallDriver.
The completion routine will call KeSetEvent on some event you’ve
initialized. If the lower driver returns STATUS_PENDING, you wait on the
event. Then you call IoCompleteRequest on this IRP, possibly after doing
some additional post processing. Is this correct? It may be more complex
than you need, but it should work fine – I’ve piggy backed URBs on
IRP_MJ_READ and IRP_MJ_WRITE techniques in countless drivers without
having any problem, and there’s nothing about an IRP_MJ_DEVICE_CONTROL
that would be different in a way that matters.
–
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
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Peter,
I want to express oenthing in this context.
During Driver development, mistakes like this might happen.
In this case, It should be the responsibility of the OS (Here, I/O
Manager) to indicate somehow that the size reported by driver is more
than requested.
Is it correct?
-±±±±±±±±±±±±±±±±±±+
We are what we repeatedly do.
Excellence, then is not an act. But a habit.
-±±±±±±±±±±±±±±±±±±+
-----Original Message-----
From: Peter Wieland [mailto:xxxxx@windows.microsoft.com]
Sent: Tuesday, February 25, 2003 10:20 PM
Subject: RE: Problem with HCT 11.0
The NT4 behavior is unfortunate, but it’s not really a bug in the
operating system. While Windows does check to make sure the supplied
buffers are valid (ie - the pages are mapped for read or write as
appropriate) the driver is responsible for ensuring that it doesn’t tell
windows to transfer more data to the application than the application
requested.
-p
-----Original Message-----
From: Sathyanarayanan Srinivasan
[mailto:xxxxx@wipro.com]
Sent: Monday, February 24, 2003 9:29 PM
To: NT Developers Interest List
>I have validated the size of out buffer and also the length is less
than
what I am filling up now.
>Also if the buffer length is wrong trying to
write to system buffer itself should cause the crash.
[Sathya] It is not true always. Size of system buffer is MAXIMUM size of
in or out buffer. For eg, if in buffer is 2k and out buffer is 1k,
system buffer allocated by i/o manager would be of 2k size and EVEN WHEN
YOU WRITE 2K BYTES INTO SYSTEM BUFFER, it will not crash. But, one
behaviour I noticed in NT4 that was, I/O MANAGER BLINDLY WRITES DATA
FROM SYSTEM BUFFER BACK TO “OutBuffer” specified in “DeviceIoControl”
for size specified by driver in IO_STATUS_BLOCK (IoStatus.Information
field, which specifies total number of bytes copied back into System
Buffer). It didn’t check whether the out buffer has enough room to hold
data of this size OR if the size specified by driver is > the size
specified by “OutBufferSize” passed in “DeviceIoControl”. It was
crashing for me earlier in NT4. Not sure if this bug is carried still.
>I have also
validated the data size being indicated back to the io manager in the
IRP.
-----Original Message-----
From: Mark Cariddi [mailto:xxxxx@osr.com]
Sent: Monday, February 24, 2003 7:33 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
When using METHOD_BUFFERED Irp->UserBuffer has been validated by the I/O
Manager (if the Irp came from user mode). When you get the Irp to
process do you validate the size of the output buffer passed to you?
Could its size be zero?
–
Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
“Shashidhar R” wrote in message
news:xxxxx@ntdev…
The crash occurs even when I copy some junk data and return it back. Is
it necessary to validate the user buffer is valid by probing by the
driver(I think this is not necessary if the IOCTL is buffered).
-----Original Message-----
From: Mark Cariddi [mailto:xxxxx@osr.com]
Sent: Monday, February 24, 2003 6:53 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Irp->UserBuffer is the user mode address of the output buffer (specified
Irp->in
the DeviceIoCtrl call) that the I/O Manager puts in the irp. When the
Irp
is completed and the IoManager needs to copy the SystemBuffer back to
the user address space it has the saved address in Irp->UserBuffer to
use.
Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
“Shashidhar R” wrote in message
news:xxxxx@ntdev…
Also my IOCTL is declared using METHOD_BUFFERED, so the user buffer
should not have any data. But it is containg some pointer (0xfffffc00)
also the system buffer field is valid.
-----Original Message-----
From: Shashidhar R
Sent: Monday, February 24, 2003 5:27 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Yes this is the exact thing I am doing, and it works fine with all the
normal ioctl’s but fails only when I run the HCT tests… I would like
to know what is the use of the field IRP->UserBuffer, and what is that
IO manager is trying to write into it.
-----Original Message-----
From: Walter Oney [mailto:xxxxx@oneysoft.com]
Sent: Monday, February 24, 2003 4:02 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Shashidhar R wrote:
> This part is fine and works, but I am not able to find the reason for
> the page fault that is happening while for some reason IO manager is
> trying to access Irp->UserBuffer during the completion of the IRP. I
> am reusing the IRP sent for IOCTL to send the URB request down the
> stack, I hope this does not cause any problem…(and completing this
> IRP synchronously by waiting for the sent request to complete). Any
> guess what is happening?
Let’s see if I understand your situation correctly:
Someone sends you an IRP_MJ_DEVICE_CONTROL. You use
IoGetNextIrpStackLocation to get a pointer to the next stack location,
which you fill with MajorFunction = IRP_MJ_INTERNAL_DEVICE_CONTROL,
Parameters.DeviceIoControl.IoControlCode =
IOCTL_INTERNAL_USB_SUBMIT_URB, and Parameters.Others.Argument1 = URB
address. Then you install a completion routine and call IoCallDriver.
The completion routine will call KeSetEvent on some event you’ve
initialized. If the lower driver returns STATUS_PENDING, you wait on the
event. Then you call IoCompleteRequest on this IRP, possibly after doing
some additional post processing. Is this correct? It may be more complex
than you need, but it should work fine – I’ve piggy backed URBs on
IRP_MJ_READ and IRP_MJ_WRITE techniques in countless drivers without
having any problem, and there’s nothing about an IRP_MJ_DEVICE_CONTROL
that would be different in a way that matters.
–
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
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Hi,
When I checked with probeforread/probeforwrite and handled the
condition, things looks to be working fine.
Thanks for the response.
Regards,
Shashi
-----Original Message-----
From: Shashidhar R
Sent: Wednesday, February 26, 2003 10:21 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with HCT 11.0
Hi Peter,
I had checked the size of data and ensured that the size is less than
what is requested even then it causes an crash so I am now trying to
first validate the userbuffer for read/write. I will indicate the
results latter but I think this is not what is expected on Win2K and
WinXP. -Shashi
-----Original Message-----
From: Peter Wieland [mailto:xxxxx@windows.microsoft.com]
Sent: Tuesday, February 25, 2003 10:20 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with HCT 11.0
The NT4 behavior is unfortunate, but it’s not really a bug in the
operating system. While Windows does check to make sure the supplied
buffers are valid (ie - the pages are mapped for read or write as
appropriate) the driver is responsible for ensuring that it doesn’t tell
windows to transfer more data to the application than the application
requested.
-p
-----Original Message-----
From: Sathyanarayanan Srinivasan
[mailto:xxxxx@wipro.com]
Sent: Monday, February 24, 2003 9:29 PM
To: NT Developers Interest List
>I have validated the size of out buffer and also the length is less
than
what I am filling up now.
>Also if the buffer length is wrong trying to
write to system buffer itself should cause the crash.
[Sathya] It is not true always. Size of system buffer is MAXIMUM size of
in or out buffer. For eg, if in buffer is 2k and out buffer is 1k,
system buffer allocated by i/o manager would be of 2k size and EVEN WHEN
YOU WRITE 2K BYTES INTO SYSTEM BUFFER, it will not crash. But, one
behaviour I noticed in NT4 that was, I/O MANAGER BLINDLY WRITES DATA
FROM SYSTEM BUFFER BACK TO “OutBuffer” specified in “DeviceIoControl”
for size specified by driver in IO_STATUS_BLOCK (IoStatus.Information
field, which specifies total number of bytes copied back into System
Buffer). It didn’t check whether the out buffer has enough room to hold
data of this size OR if the size specified by driver is > the size
specified by “OutBufferSize” passed in “DeviceIoControl”. It was
crashing for me earlier in NT4. Not sure if this bug is carried still.
>I have also
validated the data size being indicated back to the io manager in the
IRP.
-----Original Message-----
From: Mark Cariddi [mailto:xxxxx@osr.com]
Sent: Monday, February 24, 2003 7:33 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
When using METHOD_BUFFERED Irp->UserBuffer has been validated by the I/O
Manager (if the Irp came from user mode). When you get the Irp to
process do you validate the size of the output buffer passed to you?
Could its size be zero?
–
Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
“Shashidhar R” wrote in message
news:xxxxx@ntdev…
The crash occurs even when I copy some junk data and return it back. Is
it necessary to validate the user buffer is valid by probing by the
driver(I think this is not necessary if the IOCTL is buffered).
-----Original Message-----
From: Mark Cariddi [mailto:xxxxx@osr.com]
Sent: Monday, February 24, 2003 6:53 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Irp->UserBuffer is the user mode address of the output buffer (specified
Irp->in
the DeviceIoCtrl call) that the I/O Manager puts in the irp. When the
Irp
is completed and the IoManager needs to copy the SystemBuffer back to
the user address space it has the saved address in Irp->UserBuffer to
use.
Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
“Shashidhar R” wrote in message
news:xxxxx@ntdev…
Also my IOCTL is declared using METHOD_BUFFERED, so the user buffer
should not have any data. But it is containg some pointer (0xfffffc00)
also the system buffer field is valid.
-----Original Message-----
From: Shashidhar R
Sent: Monday, February 24, 2003 5:27 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Yes this is the exact thing I am doing, and it works fine with all the
normal ioctl’s but fails only when I run the HCT tests… I would like
to know what is the use of the field IRP->UserBuffer, and what is that
IO manager is trying to write into it.
-----Original Message-----
From: Walter Oney [mailto:xxxxx@oneysoft.com]
Sent: Monday, February 24, 2003 4:02 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Shashidhar R wrote:
> This part is fine and works, but I am not able to find the reason for
> the page fault that is happening while for some reason IO manager is
> trying to access Irp->UserBuffer during the completion of the IRP. I
> am reusing the IRP sent for IOCTL to send the URB request down the
> stack, I hope this does not cause any problem…(and completing this
> IRP synchronously by waiting for the sent request to complete). Any
> guess what is happening?
Let’s see if I understand your situation correctly:
Someone sends you an IRP_MJ_DEVICE_CONTROL. You use
IoGetNextIrpStackLocation to get a pointer to the next stack location,
which you fill with MajorFunction = IRP_MJ_INTERNAL_DEVICE_CONTROL,
Parameters.DeviceIoControl.IoControlCode =
IOCTL_INTERNAL_USB_SUBMIT_URB, and Parameters.Others.Argument1 = URB
address. Then you install a completion routine and call IoCallDriver.
The completion routine will call KeSetEvent on some event you’ve
initialized. If the lower driver returns STATUS_PENDING, you wait on the
event. Then you call IoCompleteRequest on this IRP, possibly after doing
some additional post processing. Is this correct? It may be more complex
than you need, but it should work fine – I’ve piggy backed URBs on
IRP_MJ_READ and IRP_MJ_WRITE techniques in countless drivers without
having any problem, and there’s nothing about an IRP_MJ_DEVICE_CONTROL
that would be different in a way that matters.
–
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
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
I think the behavior of crashing if more data length being indicated is
acceptable, this would help solving the bugs in the driver.
The problem I am referring looks like IoManager is not validating the
user buffer before completing the IRP.
I would like to know if this the expected behavior or any special
conditions are there when this happens. I am running windows XP gold
version and the test suite is HCT 11.0, if someone could explain this it
would be very helpful.
-----Original Message-----
From: Sathyanarayanan Srinivasan
Sent: Wednesday, February 26, 2003 1:29 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with HCT 11.0
Peter,
I want to express oenthing in this context.
During Driver development, mistakes like this might happen.
In this case, It should be the responsibility of the OS (Here, I/O
Manager) to indicate somehow that the size reported by driver is more
than requested. Is it correct?
-±±±±±±±±±±±±±±±±±±+
We are what we repeatedly do.
Excellence, then is not an act. But a habit.
-±±±±±±±±±±±±±±±±±±+
-----Original Message-----
From: Peter Wieland [mailto:xxxxx@windows.microsoft.com]
Sent: Tuesday, February 25, 2003 10:20 PM
Subject: RE: Problem with HCT 11.0
The NT4 behavior is unfortunate, but it’s not really a bug in the
operating system. While Windows does check to make sure the supplied
buffers are valid (ie - the pages are mapped for read or write as
appropriate) the driver is responsible for ensuring that it doesn’t tell
windows to transfer more data to the application than the application
requested.
-p
-----Original Message-----
From: Sathyanarayanan Srinivasan
[mailto:xxxxx@wipro.com]
Sent: Monday, February 24, 2003 9:29 PM
To: NT Developers Interest List
>I have validated the size of out buffer and also the length is less
than
what I am filling up now.
>Also if the buffer length is wrong trying to
write to system buffer itself should cause the crash.
[Sathya] It is not true always. Size of system buffer is MAXIMUM size of
in or out buffer. For eg, if in buffer is 2k and out buffer is 1k,
system buffer allocated by i/o manager would be of 2k size and EVEN WHEN
YOU WRITE 2K BYTES INTO SYSTEM BUFFER, it will not crash. But, one
behaviour I noticed in NT4 that was, I/O MANAGER BLINDLY WRITES DATA
FROM SYSTEM BUFFER BACK TO “OutBuffer” specified in “DeviceIoControl”
for size specified by driver in IO_STATUS_BLOCK (IoStatus.Information
field, which specifies total number of bytes copied back into System
Buffer). It didn’t check whether the out buffer has enough room to hold
data of this size OR if the size specified by driver is > the size
specified by “OutBufferSize” passed in “DeviceIoControl”. It was
crashing for me earlier in NT4. Not sure if this bug is carried still.
>I have also
validated the data size being indicated back to the io manager in the
IRP.
-----Original Message-----
From: Mark Cariddi [mailto:xxxxx@osr.com]
Sent: Monday, February 24, 2003 7:33 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
When using METHOD_BUFFERED Irp->UserBuffer has been validated by the I/O
Manager (if the Irp came from user mode). When you get the Irp to
process do you validate the size of the output buffer passed to you?
Could its size be zero?
–
Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
“Shashidhar R” wrote in message
news:xxxxx@ntdev…
The crash occurs even when I copy some junk data and return it back. Is
it necessary to validate the user buffer is valid by probing by the
driver(I think this is not necessary if the IOCTL is buffered).
-----Original Message-----
From: Mark Cariddi [mailto:xxxxx@osr.com]
Sent: Monday, February 24, 2003 6:53 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Irp->UserBuffer is the user mode address of the output buffer (specified
Irp->in
the DeviceIoCtrl call) that the I/O Manager puts in the irp. When the
Irp
is completed and the IoManager needs to copy the SystemBuffer back to
the user address space it has the saved address in Irp->UserBuffer to
use.
Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
“Shashidhar R” wrote in message
news:xxxxx@ntdev…
Also my IOCTL is declared using METHOD_BUFFERED, so the user buffer
should not have any data. But it is containg some pointer (0xfffffc00)
also the system buffer field is valid.
-----Original Message-----
From: Shashidhar R
Sent: Monday, February 24, 2003 5:27 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Yes this is the exact thing I am doing, and it works fine with all the
normal ioctl’s but fails only when I run the HCT tests… I would like
to know what is the use of the field IRP->UserBuffer, and what is that
IO manager is trying to write into it.
-----Original Message-----
From: Walter Oney [mailto:xxxxx@oneysoft.com]
Sent: Monday, February 24, 2003 4:02 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Shashidhar R wrote:
> This part is fine and works, but I am not able to find the reason for
> the page fault that is happening while for some reason IO manager is
> trying to access Irp->UserBuffer during the completion of the IRP. I
> am reusing the IRP sent for IOCTL to send the URB request down the
> stack, I hope this does not cause any problem…(and completing this
> IRP synchronously by waiting for the sent request to complete). Any
> guess what is happening?
Let’s see if I understand your situation correctly:
Someone sends you an IRP_MJ_DEVICE_CONTROL. You use
IoGetNextIrpStackLocation to get a pointer to the next stack location,
which you fill with MajorFunction = IRP_MJ_INTERNAL_DEVICE_CONTROL,
Parameters.DeviceIoControl.IoControlCode =
IOCTL_INTERNAL_USB_SUBMIT_URB, and Parameters.Others.Argument1 = URB
address. Then you install a completion routine and call IoCallDriver.
The completion routine will call KeSetEvent on some event you’ve
initialized. If the lower driver returns STATUS_PENDING, you wait on the
event. Then you call IoCompleteRequest on this IRP, possibly after doing
some additional post processing. Is this correct? It may be more complex
than you need, but it should work fine – I’ve piggy backed URBs on
IRP_MJ_READ and IRP_MJ_WRITE techniques in countless drivers without
having any problem, and there’s nothing about an IRP_MJ_DEVICE_CONTROL
that would be different in a way that matters.
–
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
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Unfortunately not. Drivers are considered extensions of the kernel and
must behave correctly, even during development, or the system will
crash. The driver verifier in more recent windows releases is the
closest Windows has to a “development” mode.
Think of it this way. The IO system allocates a buffer of 1024 bytes
for the output data because this is what the client application
requested. The driver indicates that it’s returned 1025 bytes of data
to the IO system when the request completes. If the driver actually
wrote 1025 bytes into the buffer then it has overwritten its allocation
and corrupted the system memory pool. The fact that the IO system is
going to copy more memory to the client than it requested is irrelevant
compared to the fact that the system’s kernel state has been corrupted
and will most likely crash.
In general Windows trusts the kernel and drivers to behave correctly.
The alternative is to check everything by default which would be much
slower and which the verifier does now anyway when the user chooses to
turn it on.
-p
-----Original Message-----
From: Sathyanarayanan Srinivasan
[mailto:xxxxx@wipro.com]
Sent: Tuesday, February 25, 2003 11:59 PM
To: NT Developers Interest List
Peter,
I want to express oenthing in this context.
During Driver development, mistakes like this might happen.
In this case, It should be the responsibility of the OS (Here, I/O
Manager) to indicate somehow that the size reported by driver is more
than requested.
Is it correct?
-±±±±±±±±±±±±±±±±±±+
We are what we repeatedly do.
Excellence, then is not an act. But a habit.
-±±±±±±±±±±±±±±±±±±+
-----Original Message-----
From: Peter Wieland [mailto:xxxxx@windows.microsoft.com]
Sent: Tuesday, February 25, 2003 10:20 PM
Subject: RE: Problem with HCT 11.0
The NT4 behavior is unfortunate, but it’s not really a bug in the
operating system. While Windows does check to make sure the supplied
buffers are valid (ie - the pages are mapped for read or write as
appropriate) the driver is responsible for ensuring that it doesn’t tell
windows to transfer more data to the application than the application
requested.
-p
-----Original Message-----
From: Sathyanarayanan Srinivasan
[mailto:xxxxx@wipro.com]
Sent: Monday, February 24, 2003 9:29 PM
To: NT Developers Interest List
>I have validated the size of out buffer and also the length is less
than
what I am filling up now.
>Also if the buffer length is wrong trying to
write to system buffer itself should cause the crash.
[Sathya] It is not true always. Size of system buffer is MAXIMUM size of
in or out buffer. For eg, if in buffer is 2k and out buffer is 1k,
system buffer allocated by i/o manager would be of 2k size and EVEN WHEN
YOU WRITE 2K BYTES INTO SYSTEM BUFFER, it will not crash. But, one
behaviour I noticed in NT4 that was, I/O MANAGER BLINDLY WRITES DATA
FROM SYSTEM BUFFER BACK TO “OutBuffer” specified in “DeviceIoControl”
for size specified by driver in IO_STATUS_BLOCK (IoStatus.Information
field, which specifies total number of bytes copied back into System
Buffer). It didn’t check whether the out buffer has enough room to hold
data of this size OR if the size specified by driver is > the size
specified by “OutBufferSize” passed in “DeviceIoControl”. It was
crashing for me earlier in NT4. Not sure if this bug is carried still.
>I have also
validated the data size being indicated back to the io manager in the
IRP.
-----Original Message-----
From: Mark Cariddi [mailto:xxxxx@osr.com]
Sent: Monday, February 24, 2003 7:33 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
When using METHOD_BUFFERED Irp->UserBuffer has been validated by the I/O
Manager (if the Irp came from user mode). When you get the Irp to
process do you validate the size of the output buffer passed to you?
Could its size be zero?
–
Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
“Shashidhar R” wrote in message
news:xxxxx@ntdev…
The crash occurs even when I copy some junk data and return it back. Is
it necessary to validate the user buffer is valid by probing by the
driver(I think this is not necessary if the IOCTL is buffered).
-----Original Message-----
From: Mark Cariddi [mailto:xxxxx@osr.com]
Sent: Monday, February 24, 2003 6:53 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Irp->UserBuffer is the user mode address of the output buffer (specified
Irp->in
the DeviceIoCtrl call) that the I/O Manager puts in the irp. When the
Irp
is completed and the IoManager needs to copy the SystemBuffer back to
the user address space it has the saved address in Irp->UserBuffer to
use.
Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
“Shashidhar R” wrote in message
news:xxxxx@ntdev…
Also my IOCTL is declared using METHOD_BUFFERED, so the user buffer
should not have any data. But it is containg some pointer (0xfffffc00)
also the system buffer field is valid.
-----Original Message-----
From: Shashidhar R
Sent: Monday, February 24, 2003 5:27 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Yes this is the exact thing I am doing, and it works fine with all the
normal ioctl’s but fails only when I run the HCT tests… I would like
to know what is the use of the field IRP->UserBuffer, and what is that
IO manager is trying to write into it.
-----Original Message-----
From: Walter Oney [mailto:xxxxx@oneysoft.com]
Sent: Monday, February 24, 2003 4:02 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with HCT 11.0
Shashidhar R wrote:
> This part is fine and works, but I am not able to find the reason for
> the page fault that is happening while for some reason IO manager is
> trying to access Irp->UserBuffer during the completion of the IRP. I
> am reusing the IRP sent for IOCTL to send the URB request down the
> stack, I hope this does not cause any problem…(and completing this
> IRP synchronously by waiting for the sent request to complete). Any
> guess what is happening?
Let’s see if I understand your situation correctly:
Someone sends you an IRP_MJ_DEVICE_CONTROL. You use
IoGetNextIrpStackLocation to get a pointer to the next stack location,
which you fill with MajorFunction = IRP_MJ_INTERNAL_DEVICE_CONTROL,
Parameters.DeviceIoControl.IoControlCode =
IOCTL_INTERNAL_USB_SUBMIT_URB, and Parameters.Others.Argument1 = URB
address. Then you install a completion routine and call IoCallDriver.
The completion routine will call KeSetEvent on some event you’ve
initialized. If the lower driver returns STATUS_PENDING, you wait on the
event. Then you call IoCompleteRequest on this IRP, possibly after doing
some additional post processing. Is this correct? It may be more complex
than you need, but it should work fine – I’ve piggy backed URBs on
IRP_MJ_READ and IRP_MJ_WRITE techniques in countless drivers without
having any problem, and there’s nothing about an IRP_MJ_DEVICE_CONTROL
that would be different in a way that matters.
–
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
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com