Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Filter Driver not getting volume detach callback

FODOCHALYFODOCHALY Member Posts: 7

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?

Comments

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 398
    via Email
    Are you holding any vokume's related objects referenced at that time?
    Not kust FLT_VOLUME, but any context, etc.?
  • FODOCHALYFODOCHALY Member Posts: 7

    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.

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 398
    via Email
    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.
  • FODOCHALYFODOCHALY Member Posts: 7

    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.

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 398
    via Email
    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
  • FODOCHALYFODOCHALY Member Posts: 7

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

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,398

    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?

    -scott
    OSR

  • FODOCHALYFODOCHALY Member Posts: 7

    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.

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,398

    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).

    -scott
    OSR

  • FODOCHALYFODOCHALY Member Posts: 7

    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.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE