Re: Finding out the Attached Upper device object fromPDO

“Roddy, Mark” wrote:

Yes but why exactly do you think you need to know ‘what all devices are
attached to the PDO’? The only legitimate reason I can think of for calling
IoGetAttachedDeviceReference is if you need to send IRPs to the top of the
stack from somewhere lower in the stack, and it doesn’t sound like that is
your requirement at all. Also, it sounds like you intend to traverse the
deviceobject attached device link, and that you cannot do safely.

I’m puzzled by the requirement too, but IoGetAttachedDeviceReference is
is the right answer to that specific question.

BUT, just having an extra reference to topmost FiDO in a stack will not
prevent an IRP_MN_REMOVE_DEVICE from working its way through the stack
and causing everybody to call IoDetachDevice and IoDeleteDevice. Once
that happens, and once the PnP Manager releases the guard reference it
has on all the device objects in the stack, all but the topmost device
object could disappear. It’s probably the case that the driver above
mine (and the one above it, etc.) are using an IO_REMOVE_LOCK or similar
construct to keep me in memory, so there probably isn’t an actual
problem in real life.

BUT, if Microsoft says that AttachedDevice is an opaque field, we’d
really better treat it that way. It’s really not safe to follow that
pointer without holding the internal lock that
IoGetAttachedDeviceReference holds.

IOW, Mark is right on all counts here.


Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

In case someone need to take a decision to attach to the stack for given PDO
only if a specific driver is not in the stack. In this situation
IoGetAttachedDeviceRefrence will not help. So only way is to traverse
through DeviceObject->AttachedDevice.

Regards,
Vijay
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Walter Oney
Sent: Tuesday, July 22, 2003 2:42 AM
To: Windows System Software Developers Interest List
Subject: [ntdev] Re: Finding out the Attached Upper device object
fromPDO

“Roddy, Mark” wrote:

Yes but why exactly do you think you need to know ‘what all devices are
attached to the PDO’? The only legitimate reason I can think of for
calling
IoGetAttachedDeviceReference is if you need to send IRPs to the top of the
stack from somewhere lower in the stack, and it doesn’t sound like that is
your requirement at all. Also, it sounds like you intend to traverse the
deviceobject attached device link, and that you cannot do safely.

I’m puzzled by the requirement too, but IoGetAttachedDeviceReference is
is the right answer to that specific question.

BUT, just having an extra reference to topmost FiDO in a stack will not
prevent an IRP_MN_REMOVE_DEVICE from working its way through the stack
and causing everybody to call IoDetachDevice and IoDeleteDevice. Once
that happens, and once the PnP Manager releases the guard reference it
has on all the device objects in the stack, all but the topmost device
object could disappear. It’s probably the case that the driver above
mine (and the one above it, etc.) are using an IO_REMOVE_LOCK or similar
construct to keep me in memory, so there probably isn’t an actual
problem in real life.

BUT, if Microsoft says that AttachedDevice is an opaque field, we’d
really better treat it that way. It’s really not safe to follow that
pointer without holding the internal lock that
IoGetAttachedDeviceReference holds.

IOW, Mark is right on all counts here.


Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com


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

Vijay Agrawal wrote:

In case someone need to take a decision to attach to the stack for given PDO
only if a specific driver is not in the stack. In this situation
IoGetAttachedDeviceRefrence will not help. So only way is to traverse
through DeviceObject->AttachedDevice.

Okay, so you want to find out if a given driver is already in the stack
at the time your AddDevice is running. If that other driver belongs to
you, and if you believe that every other driver between you and it will
pass down unrecognized IRP_MJ_INTERNAL_DEVICE_CONTROL requests, you
could define one of those to “ping” that other driver. Alternatively,
you could issue an IRP_MN_QUERY_INTERFACE that your other driver would
recognize.

This is still a fairly unusual requirement. Why can’t you do this at
setup time by having a program, like a co-installer DLL, query the
UpperFilters or LowerFilters values for the device and the class to see
if a particular service name is in the list?


Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

Hi Thanks for the comments,

Re:"
Okay, so you want to find out if a given driver is already in the stack
at the time your AddDevice is running. If that other driver belongs to
you, and if you believe that every other driver between you and it will
pass down unrecognized IRP_MJ_INTERNAL_DEVICE_CONTROL requests, you
could define one of those to “ping” that other driver. Alternatively,
you could issue an IRP_MN_QUERY_INTERFACE that your other driver would
recognize."

Problem is the other driver is third party driver. In that case we do not
have anything as you mentioned above.
Re:“This is still a fairly unusual requirement. Why can’t you do this at
setup time by having a program, like a co-installer DLL, query the
UpperFilters or LowerFilters values for the device and the class to see
if a particular service name is in the list?”

Because the other driver is not a Upper or Lower Filter. It replaces some
class driver in such a way that few devices configured under driver X and
rest are configured under Y. Requirement is in my filter I do not want to
attach to the objects which are configured under X.

Regards,
Vijay

> BUT, just having an extra reference to topmost FiDO in a stack will not

prevent an IRP_MN_REMOVE_DEVICE from working its way through the stack
and causing everybody to call IoDetachDevice and IoDeleteDevice.

Creating a file object (and then using IoGetRelatedDeviceObject) will block
MN_REMOVE_DEVICE, at least on NT OSes.

IMHO relying on Ob’s reference count for a device object is unreliable. The
DeviceObject->ReferenceCount field - which counts the file objects - seems to
be a better thing to rely on, since it is automatically maintained by IO
manager while creating/deleting file objects.

Max

So why not check the service in the coinstaller?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Vijay Agrawal
Sent: Tuesday, July 22, 2003 3:40 AM
To: Windows System Software Developers Interest List
Subject: [ntdev] Re: Finding out the Attached Upper device object
fromPDO

Hi Thanks for the comments,

Re:"
Okay, so you want to find out if a given driver is already in the stack
at the time your AddDevice is running. If that other driver belongs to
you, and if you believe that every other driver between you and it will
pass down unrecognized IRP_MJ_INTERNAL_DEVICE_CONTROL requests, you
could define one of those to “ping” that other driver. Alternatively,
you could issue an IRP_MN_QUERY_INTERFACE that your other driver would
recognize."

Problem is the other driver is third party driver. In that case we do
not have anything as you mentioned above.
Re:“This is still a fairly unusual requirement. Why can’t you do this at
setup time by having a program, like a co-installer DLL, query the
UpperFilters or LowerFilters values for the device and the class to see
if a particular service name is in the list?”

Because the other driver is not a Upper or Lower Filter. It replaces
some class driver in such a way that few devices configured under driver
X and rest are configured under Y. Requirement is in my filter I do not
want to attach to the objects which are configured under X.

Regards,
Vijay


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

You shouldn’t “rely” on either. They’re both private kernel values you
should just leave alone.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Tuesday, July 22, 2003 10:29 AM
To: Windows System Software Developers Interest List
Subject: [ntdev] Re: Finding out the Attached Upper device object
fromPDO

BUT, just having an extra reference to topmost FiDO in a stack will
not prevent an IRP_MN_REMOVE_DEVICE from working its way through the
stack and causing everybody to call IoDetachDevice and IoDeleteDevice.

Creating a file object (and then using IoGetRelatedDeviceObject) will
block MN_REMOVE_DEVICE, at least on NT OSes.

IMHO relying on Ob’s reference count for a device object is unreliable.
The
DeviceObject->ReferenceCount field - which counts the file objects -
DeviceObject->seems to
be a better thing to rely on, since it is automatically maintained by IO
manager while creating/deleting file objects.

Max


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