I’m going to guess that you’re building a RAID or multi-path product.
That’s just a guess - but it’s based on previous attempts to build such
products in this incorrect manner.
If you’re trying to aggreate devices A and B (perhaps separate devices,
perhaps different paths to the same device) then you need to expose a
new device (of a new bus driver you write) C, which takes care of
forwarding the I/O to A or B as appropriate. You also likely need a bus
filter driver which attaches to the other HBAs, attaches to devices A, B
(etc…) and blocks any attempt to access them.
This way when A is removed from the system, C can just fail over to
using B. When A returns, C can start using A again (but may run off and
regenerate a mirror/stripe on A before using A again).
The approach of attaching to A and B doesn’t work because you can’t keep
your filter alive when one of the underlying devices is disconnected.
Trying to manipulate the object reference counts is going to cause
problems. The driver creating a device is the ONLY component allowed to
delete that device. If you try to do it you will very likely cause a
bugcheck (which will probably happen later and look like a pool fault in
the poor driver you helpfully corrupted).
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Raju
Sent: Tuesday, June 21, 2005 10:45 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Cleaning Un-wanted Device Objects
Hi
Thanks for the info, Peter.
Are you attaching a device to the PDO and then not removing it during
IRP_MJ_PNP/IRP_MN_REMOVE_DEVICE processing?
We are attaching our device object to HBA driver’s device object, when
the device is connected initially.
And when the device is removed, we are not detaching our object from
HBA’s object. This we are doing intentionally due to some functional
requirement.
The problem is that …
When the same device is connected once again, HBA driver creates one
more object and reports our driver. Since we already have old object
with us, we want to get rid of this new object created by HBA driver.
BTW,
You mentioned that I/O Manager’s ReferenceCount and Object Manager’s
ReferenceCount for an object are different.
How do I check the value of Object Manager’s ReferenceCount for an
Object?
Thanks
KPR
Date: Tue, 21 Jun 2005 09:01:59 -0700
From: “Peter Wieland”
> Subject: RE: Cleaning Un-wanted Device Objects
>
> 1 - that’s not your job. That’s the job of the HBA driver.
>
> 2 - System will automatically delete a device object if (a) the driver
> has called IoDeleteDevice and (b) the Object reference count goes to
> zero. What you’re looking at below is the IO manager reference count
> which is different than the one the Object manager maintains (though
> they’re linked)
>
> I would guess your filter is referencing these objects and not
> releasing the references. Are you attaching a device to the PDO and
> then not removing it during IRP_MJ_PNP/IRP_MN_REMOVE_DEVICE
processing?
>
> -p
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Raju
> Sent: Tuesday, June 21, 2005 3:44 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Cleaning Un-wanted Device Objects
>
> Hi
>
> We are writing a storage filter driver that will be layered above the
> port driver.
>
> Please help me in clearing my questions…
>
> 1) How to delete the device object that was created by other driver
> (HBA driver)?
>
> 2) Does the system automatically clears the device object if the
> ReferenceCount is 0?
> 2a) If yes, timing of cleanup?
> 2b) If No, is there any other parameter of device object that can be
> set so that system
> will delete the un-wanted object?
>
> Please find more information below…
>
> Thanks,
> KPR.
>
> The following shows the list of device objects for HBA driver.
>
> 1: kd> !drvobj fffffadf9c558e20
> Driver object (fffffadf9c558e20) is for:
> \Driver\elxstor
> Driver Extension List: (id , addr)
> (fffffadf90406a60 fffffadf9c558d40)
> Device Object list:
> fffffadf9b01c960 fffffadf9af40450 fffffadf9b0ea280 fffffadf9c6d4060
> fffffadf9c63e960 fffffadf9c697060 fffffadf9c6d8060 fffffadf9c668060
> fffffadf9ca9f060
>
>
> Some device objects in the above list are orphans. The following shows
> one of the orphan device object stack.
>
> 1: kd> !devstack fffffadf9b01c960
> !DevObj !DrvObj !DevExt ObjectName
> > fffffadf9b01c960 \Driver\elxstor fffffadf9b01cab0 00000072
>
>
> I would like to get rid off this orphan device object. The following
> shows the properties of the orphan device object. Here the
> ReferenceCount is 0. I don’t know why system is not clearing the
> object even if the ReferenceCount is 0.
>
> 1: kd> dt nt!_DEVICE_OBJECT fffffadf9b01c960
> +0x000 Type : 3
> +0x002 Size : 0x650
> +0x004 ReferenceCount : 0
> +0x008 DriverObject : 0xfffffadf9c558e20<br>> +0x010 NextDevice : 0xfffffadf9af40450
> +0x018 AttachedDevice : (null)
> +0x020 CurrentIrp : (null)
> +0x028 Timer : (null)
> +0x030 Flags : 0x1050
> +0x034 Characteristics : 0x180
> +0x038 Vpb : (null)
> +0x040 DeviceExtension : 0xfffffadf9b01cab0<br>> +0x048 DeviceType : 0x2d<br>> +0x04c StackSize : 1 ''<br>> +0x050 Queue : <unnamed-tag><br>> +0x098 AlignmentRequirement : 0<br>> +0x0a0 DeviceQueue : _KDEVICE_QUEUE<br>> +0x0c8 Dpc : _KDPC<br>> +0x108 ActiveThreadCount : 0<br>> +0x110 SecurityDescriptor : 0xfffffa8000516d20
> +0x118 DeviceLock : _KEVENT
> +0x130 SectorSize : 0
> +0x132 Spare1 : 0
> +0x138 DeviceObjectExtension : 0xfffffadf`9b01cfb0
> +0x140 Reserved : (null)
>
>
> —
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com