Do you have an InstanceTeardownStart that gets called?
Filter Driver InstanceTeardownComplete callback not called
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 (InstanceTeardownComplete ) 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?
2 answers
Sort by: Most helpful
-
Christian Allred 1 Reputation point Microsoft Employee
2021-02-19T19:42:10.997+00:00 -
RV 1 Reputation point
2021-02-21T19:23:56.393+00:00 Hi, I did not register a callback for InstanceTeardownStart.
I registered callbacks for: InstanceSetup, InstanceTeardownComplete, FilterUnload.
All of volumes in detached state are writable VSS volumes and most of the time we do get InstanceTeardownComplete.
I ran verifier multiple times on the driver (load/unload) with no issues; not during the leaked volumes (could not repro it in house).