I have run into a problem with certain fibrechannel HBAs where a disk never
comes back after a failure. So far this looks like it might be limited to one
HBA manufacturer, but I’m still assuming that means I’m doing something
in my driver which is not quite “by the book”.
This appears to be related to holding a reference to the FILE_OBJECT obtained
from IoGetDeviceObjectPointer. Unlike the typical filter driver, this driver is given
the names of devices to layer on top of (as opposed to just calling
IoAttachDeviceToDeviceStack on an AddDevice callback).
The original code held onto the FILE_OBJECT reference until just before calling
IoDetachDevice when handling a REMOVE_DEVICE event. But the problem that
I mentioned above occurred in this case. In contrast, if I call ObDeferenceObject
on the FILE_OBJECT (not the DEVICE_OBJECT) immediately after calling
IoAttachDeviceToDeviceStack, things appear to work.
The question is, do I have a referential problem with the DEVICE_OBJECT or does
the call to IoAttachDeviceToDeviceStack implicitly add a reference to the
DEVICE_OBJECT previously returned from IoGetDeviceObjectPointer (thus
I can deference the FILE_OBJECT anytime after calling IoAttachDeviceToDeviceStack)?
If this is a problem, will a ObReferenceObject on the DEVICE_OBJECT do the trick
(I would expect so, but some of the comments in Walter Oney’s 2nd Ed. WDM
book worry me a bit … see p. 231 if you’re curious where he discusses reasons
to consider if you drop the FILE_OBJECT reference just after taking a reference
on the DEVICE_OBJECT).
IoAttachDeviceToDeviceStack implicitly references the lower device. You can safely get rid of your file object reference. This is only clear from the documentation for IoDetachDevice.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-280949-
xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Friday, March 16, 2007 6:13 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Filter Driver, IoGetDeviceObjectPointer, and PNP
I have run into a problem with certain fibrechannel HBAs where a disk
never
comes back after a failure. So far this looks like it might be limited
to one
HBA manufacturer, but I’m still assuming that means I’m doing something
in my driver which is not quite “by the book”.
This appears to be related to holding a reference to the FILE_OBJECT
obtained
from IoGetDeviceObjectPointer. Unlike the typical filter driver, this
driver is given
the names of devices to layer on top of (as opposed to just calling
IoAttachDeviceToDeviceStack on an AddDevice callback).
The original code held onto the FILE_OBJECT reference until just before
calling
IoDetachDevice when handling a REMOVE_DEVICE event. But the problem
that
I mentioned above occurred in this case. In contrast, if I call
ObDeferenceObject
on the FILE_OBJECT (not the DEVICE_OBJECT) immediately after calling
IoAttachDeviceToDeviceStack, things appear to work.
The question is, do I have a referential problem with the DEVICE_OBJECT
or does
the call to IoAttachDeviceToDeviceStack implicitly add a reference to
the
DEVICE_OBJECT previously returned from IoGetDeviceObjectPointer (thus
I can deference the FILE_OBJECT anytime after calling
IoAttachDeviceToDeviceStack)?
If this is a problem, will a ObReferenceObject on the DEVICE_OBJECT do
the trick
(I would expect so, but some of the comments in Walter Oney’s 2nd Ed.
WDM
book worry me a bit … see p. 231 if you’re curious where he discusses
reasons
to consider if you drop the FILE_OBJECT reference just after taking a
reference
on the DEVICE_OBJECT).
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer