Filter Driver not getting volume detach callback

I have a filter driver attaching to writable volumes to monitor write activity on files. The driver attaches to all writable volumes including VSS writable volumes (the driver do not attach to the VSS readonly volume) associated to the parent volume.
I noticed that sometimes our driver is not getting a detach callback on the VSS writable volume when the system retire the volume.
After this the fltmc instances / volumes shows a lot of other drivers (some are AV drivers) in the stack holding that volume in Detached state; on some systems where we do a lot of VSS snapshots we end up with hundred of records as bellow - VSS volumes in Detached state.
Example:
WdFilter \Device\HarddiskVolumeShadowCopy10 328010 WdFilter Instance 0 00000003 Detached
This is a fairly random incident - most of the time we do get the detach callback paired with the attach callback.
Our filter has the highest altitude in the stack (above the AV and the driver in the example),
Did anybody encounter this issue? Any pointers to get to the root cause?

Are you holding any vokume’s related objects referenced at that time?
Not kust FLT_VOLUME, but any context, etc.?

I do hold FTL_VOLUME pointers, no FLT_VOLUME_CONTEXT objects. It is also a very rear event, I was not able to repro it on the debug system.

I cannot be sure, but I think if you hold an FLT_VOLUME referenced it
will not be calling detach volume.

run !fltkd.filter to see all the volume references from your filter at
the time when you should see a detach already.

I do hold FTL_VOLUME pointers, no FLT_VOLUME_CONTEXT objects. It is also a
very rear event, I was not able to repro it on the debug system.

I see, as mentioned before i hold FLT_VOLUME_CONTEXT for non snapshot volumes but not for snapshot volumes (I have a mapping between VSS snapshots and parent volume - the one that is in the snapshot set). I thought that FLT_VOLUME is just a pointer and is not referential counted.
I ran the fltkd.filter but did not see any context related to the snapshot volume.

Holding an object = holding a reference to it, via FltReferenceObject,
FltAlkicate/GetXxxContext, etc.

If you just have a pointer, and not a reference, that is different, and not
an issue here.

Maybe someone else can chime in with other ideas.

I see, as mentioned before i hold FLT_VOLUME_CONTEXT for non snapshot

Thanks. I used to have issues with leaked FltRefs, they were showing up in the verifier.

Enable Verifier and then try to unload your filter while there are the dangling detached instances. If you’re leaking FltMgr refs it will show up. If not, do you ever take our references to device objects or file objects?

It’s also possible that it’s not your fault. Did you try removing your filter and seeing if you can still repro the problem?

Thanks Scott. I did run verifier and unload the driver without any issue but not in this case.
I can’t repro in our lab; it seems to be happening on systems that are running AV filters.
I did unload our driver on one of the sites but the detached volumes were still around; did not actually try to see if new detached volumes showed up after the unload.

If you could unload your filter with the detached volumes dangling then it’s definitely not a Flt reference leak (the unload would hang if it was).

Yes. Ee unload our driver on the system with detached volumes with no issues. We recycle the driver (unload/load) to release resources (they were supposed to be release during the InstanceTeardownComplete callback that is not called for the volumes that shows in detached state - the observation is all are VSS writable snapshot volumes)
Could it be that IO is still pending - like lost IRP - on the volume so that the volume object has to be retain(in detached state)?
Unloading/Loading our driver is not releasing the detached volumes.