how to get the top object in the device object's stack

Hi all,

device stack is as follows (from up to bottom):

1. upper filter dirver
2. usb video class driver
3. lower fitler driver
4. usbccgp driver

I tried to get the top object in the device object's stack in lower fitler
driver but failed and the return devExt->TopDevice = 0x00.


I will appriciate if you provide some suggestions?

//=====================================
Below is the code in AddDevice() function.

#define DEVICE_NAME L"\\Device\\lowUVCFilter"

RtlInitUnicodeString(&deviceName, DEVICE_NAME );

status = IoCreateDevice(Driver,
sizeof(USBCAMD_DEVICE_EXTENSION),
&deviceName,
FILE_DEVICE_UNKNOWN, 0,
FALSE,
&device
);


if (!NT_SUCCESS(status)) {
return (status);
}

RtlZeroMemory(device->DeviceExtension, sizeof(USBCAMD_DEVICE_EXTENSION));

devExt = (PDEVICE_EXTENSION) device->DeviceExtension;
devExt->TopOfStack = IoAttachDeviceToDeviceStack(device, PDO);

status = IoGetDeviceObjectPointer( &deviceName,
FILE_ALL_ACCESS,
&FileObject,
&devExt->TopDevice
);

Doron
Thu Aug 23 15:44:11 CDT 2007

IoGetDeviceObjectPointer creates a handle to the stack, but you can't create
a handle to the stack until the start irp completes (which is much later
then AddDevice). IoGetAttachedDeviceReference will get you the top of the
stack, but in the context of AddDevice, it will be your device and not the
rest of the stack. If you want the top of the stack, call
IoGetAttachedDeviceReference in your start irp handler. Also remember to
derefence the device object returned to you by IoGetAttachedDeviceReference.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Steve" <Steve@discussions.microsoft.com> wrote in message
news:1095AC6F-2764-4BEE-BA9D-FCDEE3BB0EAC@microsoft.com...
> Hi all,
>
> device stack is as follows (from up to bottom):
>
> 1. upper filter dirver
> 2. usb video class driver
> 3. lower fitler driver
> 4. usbccgp driver
>
> I tried to get the top object in the device object's stack in lower fitler
> driver but failed and the return devExt->TopDevice = 0x00.
>
>
> I will appriciate if you provide some suggestions?
>
> //=====================================
> Below is the code in AddDevice() function.
>
> #define DEVICE_NAME L"\\Device\\lowUVCFilter"
>
> RtlInitUnicodeString(&deviceName, DEVICE_NAME );
>
> status = IoCreateDevice(Driver,
> sizeof(USBCAMD_DEVICE_EXTENSION),
> &deviceName,
> FILE_DEVICE_UNKNOWN, 0,
> FALSE,
> &device
> );
>
>
> if (!NT_SUCCESS(status)) {
> return (status);
> }
>
> RtlZeroMemory(device->DeviceExtension,
> sizeof(USBCAMD_DEVICE_EXTENSION));
>
> devExt = (PDEVICE_EXTENSION) device->DeviceExtension;
> devExt->TopOfStack = IoAttachDeviceToDeviceStack(device, PDO);
>
> status = IoGetDeviceObjectPointer( &deviceName,
> FILE_ALL_ACCESS,
> &FileObject,
> &devExt->TopDevice
> );
>

Steve
Thu Aug 23 20:22:00 CDT 2007

Hi Doron,

Thanks for your help.
My work is in lower fitler driver and want to get top of stack( ie. upper
filter driver).
Could you kindly explain the detailed infomation about how to get top of
stack(ie. upper filter driver) in start irp handler by
IoGetAttachedDeviceReference?

Thank you very much!

"Doron Holan [MSFT]" wrote:

> IoGetDeviceObjectPointer creates a handle to the stack, but you can't create
> a handle to the stack until the start irp completes (which is much later
> then AddDevice). IoGetAttachedDeviceReference will get you the top of the
> stack, but in the context of AddDevice, it will be your device and not the
> rest of the stack. If you want the top of the stack, call
> IoGetAttachedDeviceReference in your start irp handler. Also remember to
> derefence the device object returned to you by IoGetAttachedDeviceReference.
>
> d
>
> --
> Please do not send e-mail directly to this alias. this alias is for
> newsgroup purposes only.
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
> "Steve" <Steve@discussions.microsoft.com> wrote in message
> news:1095AC6F-2764-4BEE-BA9D-FCDEE3BB0EAC@microsoft.com...
> > Hi all,
> >
> > device stack is as follows (from up to bottom):
> >
> > 1. upper filter dirver
> > 2. usb video class driver
> > 3. lower fitler driver
> > 4. usbccgp driver
> >
> > I tried to get the top object in the device object's stack in lower fitler
> > driver but failed and the return devExt->TopDevice = 0x00.
> >
> >
> > I will appriciate if you provide some suggestions?
> >
> > //=====================================
> > Below is the code in AddDevice() function.
> >
> > #define DEVICE_NAME L"\\Device\\lowUVCFilter"
> >
> > RtlInitUnicodeString(&deviceName, DEVICE_NAME );
> >
> > status = IoCreateDevice(Driver,
> > sizeof(USBCAMD_DEVICE_EXTENSION),
> > &deviceName,
> > FILE_DEVICE_UNKNOWN, 0,
> > FALSE,
> > &device
> > );
> >
> >
> > if (!NT_SUCCESS(status)) {
> > return (status);
> > }
> >
> > RtlZeroMemory(device->DeviceExtension,
> > sizeof(USBCAMD_DEVICE_EXTENSION));
> >
> > devExt = (PDEVICE_EXTENSION) device->DeviceExtension;
> > devExt->TopOfStack = IoAttachDeviceToDeviceStack(device, PDO);
> >
> > status = IoGetDeviceObjectPointer( &deviceName,
> > FILE_ALL_ACCESS,
> > &FileObject,
> > &devExt->TopDevice
> > );
> >
>
>

Doron
Fri Aug 24 13:05:01 CDT 2007

how about this

PDEVICE_OBJECT top = IoGetAttachedDeviceReference(<your device object>);
...do stuff...
ObDereferenceObject(top)

if you need to store the device object pointer for the entire lifetime of
the device, call ObDereferenceObject during your IRP_MN_REMOVE_DEVICE
handler

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Steve" <Steve@discussions.microsoft.com> wrote in message
news:B359629B-BC3A-4DCF-B554-3B983C847E9D@microsoft.com...
> Hi Doron,
>
> Thanks for your help.
> My work is in lower fitler driver and want to get top of stack( ie. upper
> filter driver).
> Could you kindly explain the detailed infomation about how to get top of
> stack(ie. upper filter driver) in start irp handler by
> IoGetAttachedDeviceReference?
>
> Thank you very much!
>
> "Doron Holan [MSFT]" wrote:
>
>> IoGetDeviceObjectPointer creates a handle to the stack, but you can't
>> create
>> a handle to the stack until the start irp completes (which is much later
>> then AddDevice). IoGetAttachedDeviceReference will get you the top of
>> the
>> stack, but in the context of AddDevice, it will be your device and not
>> the
>> rest of the stack. If you want the top of the stack, call
>> IoGetAttachedDeviceReference in your start irp handler. Also remember to
>> derefence the device object returned to you by
>> IoGetAttachedDeviceReference.
>>
>> d
>>
>> --
>> Please do not send e-mail directly to this alias. this alias is for
>> newsgroup purposes only.
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>> "Steve" <Steve@discussions.microsoft.com> wrote in message
>> news:1095AC6F-2764-4BEE-BA9D-FCDEE3BB0EAC@microsoft.com...
>> > Hi all,
>> >
>> > device stack is as follows (from up to bottom):
>> >
>> > 1. upper filter dirver
>> > 2. usb video class driver
>> > 3. lower fitler driver
>> > 4. usbccgp driver
>> >
>> > I tried to get the top object in the device object's stack in lower
>> > fitler
>> > driver but failed and the return devExt->TopDevice = 0x00.
>> >
>> >
>> > I will appriciate if you provide some suggestions?
>> >
>> > //=====================================
>> > Below is the code in AddDevice() function.
>> >
>> > #define DEVICE_NAME L"\\Device\\lowUVCFilter"
>> >
>> > RtlInitUnicodeString(&deviceName, DEVICE_NAME );
>> >
>> > status = IoCreateDevice(Driver,
>> > sizeof(USBCAMD_DEVICE_EXTENSION),
>> > &deviceName,
>> > FILE_DEVICE_UNKNOWN, 0,
>> > FALSE,
>> > &device
>> > );
>> >
>> >
>> > if (!NT_SUCCESS(status)) {
>> > return (status);
>> > }
>> >
>> > RtlZeroMemory(device->DeviceExtension,
>> > sizeof(USBCAMD_DEVICE_EXTENSION));
>> >
>> > devExt = (PDEVICE_EXTENSION) device->DeviceExtension;
>> > devExt->TopOfStack = IoAttachDeviceToDeviceStack(device, PDO);
>> >
>> > status = IoGetDeviceObjectPointer( &deviceName,
>> > FILE_ALL_ACCESS,
>> > &FileObject,
>> > &devExt->TopDevice
>> > );
>> >
>>
>>

Steve
Sat Aug 25 10:32:03 CDT 2007

Hi Doron,

Thank you very much!
I have got the top object by following your suggestion.

Now, I have other questions.

(1).Is there any way to get all device object in the device object's
stack?

For example, in the upper filter driver ,how can I get the device object of
usb video class ,
lower fitler , and
usbccgp in the device object's stack?

meanwhile,
in the lower filter driver ,how can I get the device object of
upper fitler ,
usb video class ,
and
usbccgp in the device object's stack?


(2).I wonder Whether can I call IoCallDriver pass down IRP directly from
upper filter to lower filter or not?

Thanks.


"Doron Holan [MSFT]" wrote:

> how about this
>
> PDEVICE_OBJECT top = IoGetAttachedDeviceReference(<your device object>);
> ....do stuff...
> ObDereferenceObject(top)
>
> if you need to store the device object pointer for the entire lifetime of
> the device, call ObDereferenceObject during your IRP_MN_REMOVE_DEVICE
> handler
>
> d
>
> --
> Please do not send e-mail directly to this alias. this alias is for
> newsgroup purposes only.
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
> "Steve" <Steve@discussions.microsoft.com> wrote in message
> news:B359629B-BC3A-4DCF-B554-3B983C847E9D@microsoft.com...
> > Hi Doron,
> >
> > Thanks for your help.
> > My work is in lower fitler driver and want to get top of stack( ie. upper
> > filter driver).
> > Could you kindly explain the detailed infomation about how to get top of
> > stack(ie. upper filter driver) in start irp handler by
> > IoGetAttachedDeviceReference?
> >
> > Thank you very much!
> >
> > "Doron Holan [MSFT]" wrote:
> >
> >> IoGetDeviceObjectPointer creates a handle to the stack, but you can't
> >> create
> >> a handle to the stack until the start irp completes (which is much later
> >> then AddDevice). IoGetAttachedDeviceReference will get you the top of
> >> the
> >> stack, but in the context of AddDevice, it will be your device and not
> >> the
> >> rest of the stack. If you want the top of the stack, call
> >> IoGetAttachedDeviceReference in your start irp handler. Also remember to
> >> derefence the device object returned to you by
> >> IoGetAttachedDeviceReference.
> >>
> >> d
> >>
> >> --
> >> Please do not send e-mail directly to this alias. this alias is for
> >> newsgroup purposes only.
> >> This posting is provided "AS IS" with no warranties, and confers no
> >> rights.
> >>
> >>
> >> "Steve" <Steve@discussions.microsoft.com> wrote in message
> >> news:1095AC6F-2764-4BEE-BA9D-FCDEE3BB0EAC@microsoft.com...
> >> > Hi all,
> >> >
> >> > device stack is as follows (from up to bottom):
> >> >
> >> > 1. upper filter dirver
> >> > 2. usb video class driver
> >> > 3. lower fitler driver
> >> > 4. usbccgp driver
> >> >
> >> > I tried to get the top object in the device object's stack in lower
> >> > fitler
> >> > driver but failed and the return devExt->TopDevice = 0x00.
> >> >
> >> >
> >> > I will appriciate if you provide some suggestions?
> >> >
> >> > //=====================================
> >> > Below is the code in AddDevice() function.
> >> >
> >> > #define DEVICE_NAME L"\\Device\\lowUVCFilter"
> >> >
> >> > RtlInitUnicodeString(&deviceName, DEVICE_NAME );
> >> >
> >> > status = IoCreateDevice(Driver,
> >> > sizeof(USBCAMD_DEVICE_EXTENSION),
> >> > &deviceName,
> >> > FILE_DEVICE_UNKNOWN, 0,
> >> > FALSE,
> >> > &device
> >> > );
> >> >
> >> >
> >> > if (!NT_SUCCESS(status)) {
> >> > return (status);
> >> > }
> >> >
> >> > RtlZeroMemory(device->DeviceExtension,
> >> > sizeof(USBCAMD_DEVICE_EXTENSION));
> >> >
> >> > devExt = (PDEVICE_EXTENSION) device->DeviceExtension;
> >> > devExt->TopOfStack = IoAttachDeviceToDeviceStack(device, PDO);
> >> >
> >> > status = IoGetDeviceObjectPointer( &deviceName,
> >> > FILE_ALL_ACCESS,
> >> > &FileObject,
> >> > &devExt->TopDevice
> >> > );
> >> >
> >>
> >>
>
>

Walter
Sat Aug 25 17:15:33 CDT 2007

Steve wrote:

I'm going to answer these questions so Doron doesn't have to expend any
more of his limited store of patience. Why do you want to do these
things? There isn't a DDI that's documented to let you do them, and the
fields in data structures that would let you do them are opaque. The
reason for both of those is that driver writers almost never need to do
them. Specifically:

> (1).Is there any way to get all device object in the device object's
> stack?

Yes, but why do YOU care about this? Diagnostic tools might need this
ability, but they can (mostly) rely on the registry to tell them.
(UpperFilters and LowerFilters). I didn't publish the source for the
DevView utility that shipped with my WDM book because it uses
undocumented and therefore fragile kernel calls to do what it does.
There is a field in a data structure that could be useful for this
purpose, but you can't use it safely from a driver because you can't get
access to the synchronization object that's needed to do it safely. I
think it's best not to say more about this, since you apparently don't
already know which field I'm talking about. The rule is that, if the
WDK/DDK doesn't document a particular field, you mustn't use it. And
PreFast will flag violations.

> (2).I wonder Whether can I call IoCallDriver pass down IRP directly from
> upper filter to lower filter or not?

Again, why do you want to do this? You'll bypass the function driver,
which may have a very good reason for not forwarding particular IRPs.
Not to mention that you can cause a crash at REMOVE_DEVICE time by
having an IRP outstanding that a driver in the middle of the stack
doesn't know about. Or jump into the middle of a series of operations
that the function driver needs to do in an atomic way without
interruption.

There is a documented method for accomplishing a similar task anyway,
using IRP_MN_QUERY_INTERFACE. Your lower filter would handle this
request and return a direct-call interface up the stack. The function
driver should not be filtering these requests.

In my book, I advised people writing USB function drivers to always pass
down INTERNAL_DEVICE_CONTROL requests. After writing this response, I
now think that's actually a bad idea.

--
Walter Oney, Consulting and Training
http://www.oneysoft.com

Doron
Mon Aug 27 13:19:18 CDT 2007

who says i have limited patience ;) ? thanks for answering.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Walter Oney" <waltoney@oneysoft.com> wrote in message
news:46D0AA05.EC990A89@oneysoft.com...
> Steve wrote:
>
> I'm going to answer these questions so Doron doesn't have to expend any
> more of his limited store of patience. Why do you want to do these
> things? There isn't a DDI that's documented to let you do them, and the
> fields in data structures that would let you do them are opaque. The
> reason for both of those is that driver writers almost never need to do
> them. Specifically:
>
>> (1).Is there any way to get all device object in the device object's
>> stack?
>
> Yes, but why do YOU care about this? Diagnostic tools might need this
> ability, but they can (mostly) rely on the registry to tell them.
> (UpperFilters and LowerFilters). I didn't publish the source for the
> DevView utility that shipped with my WDM book because it uses
> undocumented and therefore fragile kernel calls to do what it does.
> There is a field in a data structure that could be useful for this
> purpose, but you can't use it safely from a driver because you can't get
> access to the synchronization object that's needed to do it safely. I
> think it's best not to say more about this, since you apparently don't
> already know which field I'm talking about. The rule is that, if the
> WDK/DDK doesn't document a particular field, you mustn't use it. And
> PreFast will flag violations.
>
>> (2).I wonder Whether can I call IoCallDriver pass down IRP directly
>> from
>> upper filter to lower filter or not?
>
> Again, why do you want to do this? You'll bypass the function driver,
> which may have a very good reason for not forwarding particular IRPs.
> Not to mention that you can cause a crash at REMOVE_DEVICE time by
> having an IRP outstanding that a driver in the middle of the stack
> doesn't know about. Or jump into the middle of a series of operations
> that the function driver needs to do in an atomic way without
> interruption.
>
> There is a documented method for accomplishing a similar task anyway,
> using IRP_MN_QUERY_INTERFACE. Your lower filter would handle this
> request and return a direct-call interface up the stack. The function
> driver should not be filtering these requests.
>
> In my book, I advised people writing USB function drivers to always pass
> down INTERNAL_DEVICE_CONTROL requests. After writing this response, I
> now think that's actually a bad idea.
>
> --
> Walter Oney, Consulting and Training
> http://www.oneysoft.com

Steve
Wed Aug 29 02:06:02 CDT 2007

Thanks for your reply.

Your answers are very clear and very helpful.


"Doron Holan [MSFT]" wrote:

> who says i have limited patience ;) ? thanks for answering.
>
> d
>
> --
> Please do not send e-mail directly to this alias. this alias is for
> newsgroup purposes only.
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
> "Walter Oney" <waltoney@oneysoft.com> wrote in message
> news:46D0AA05.EC990A89@oneysoft.com...
> > Steve wrote:
> >
> > I'm going to answer these questions so Doron doesn't have to expend any
> > more of his limited store of patience. Why do you want to do these
> > things? There isn't a DDI that's documented to let you do them, and the
> > fields in data structures that would let you do them are opaque. The
> > reason for both of those is that driver writers almost never need to do
> > them. Specifically:
> >
> >> (1).Is there any way to get all device object in the device object's
> >> stack?
> >
> > Yes, but why do YOU care about this? Diagnostic tools might need this
> > ability, but they can (mostly) rely on the registry to tell them.
> > (UpperFilters and LowerFilters). I didn't publish the source for the
> > DevView utility that shipped with my WDM book because it uses
> > undocumented and therefore fragile kernel calls to do what it does.
> > There is a field in a data structure that could be useful for this
> > purpose, but you can't use it safely from a driver because you can't get
> > access to the synchronization object that's needed to do it safely. I
> > think it's best not to say more about this, since you apparently don't
> > already know which field I'm talking about. The rule is that, if the
> > WDK/DDK doesn't document a particular field, you mustn't use it. And
> > PreFast will flag violations.
> >
> >> (2).I wonder Whether can I call IoCallDriver pass down IRP directly
> >> from
> >> upper filter to lower filter or not?
> >
> > Again, why do you want to do this? You'll bypass the function driver,
> > which may have a very good reason for not forwarding particular IRPs.
> > Not to mention that you can cause a crash at REMOVE_DEVICE time by
> > having an IRP outstanding that a driver in the middle of the stack
> > doesn't know about. Or jump into the middle of a series of operations
> > that the function driver needs to do in an atomic way without
> > interruption.
> >
> > There is a documented method for accomplishing a similar task anyway,
> > using IRP_MN_QUERY_INTERFACE. Your lower filter would handle this
> > request and return a direct-call interface up the stack. The function
> > driver should not be filtering these requests.
> >
> > In my book, I advised people writing USB function drivers to always pass
> > down INTERNAL_DEVICE_CONTROL requests. After writing this response, I
> > now think that's actually a bad idea.
> >
> > --
> > Walter Oney, Consulting and Training
> > http://www.oneysoft.com
>
>