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


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:

Filter manager object tracking out of sync

OSR_Community_UserOSR_Community_User Member Posts: 110,217
Sometimes I get this filter verifier warning and verifier reports some FLT_GENERIC_WORKITEM leaks. I verified that there are no actual leaks in my driver. Anyone has more information on this warning?

FILTER VERIFIER WARNING: Filter manager verifier object tracking may be out of sync for the system
because the verifier was unable to identify the calling filter for 0 object
allocation(s)/reference(s) and for 6 object deallocation(s)/release(s).
Failure to identify the calling filter for an object deallocation/release
may cause verifier to complain when the filter is unloaded even though
the filter is not leaking any objects.


  • Scott_BrenderScott_Brender Member - All Emails Posts: 39
    This means there were six cases where verifier could not identify which filter was deallocating/releasing some resource. This can lead to a false leak detection.

    One way this can happen is if a filter allocates/deallocates workitems without ever queuing them. This is legal but it throws off filter verifier.

    If you have verified you are not leaking any objects then you can ignore this warning.

    This posting is provided "AS IS" with no warranties, and confers no rights.
  • Alnoor_AllidinaAlnoor_Allidina Member Posts: 12

    Unfortunately, our testers don't agree with Scott -- they don't want to ignore this warning. :-)

    I finally figured out what was going wrong in our case -- we weren't leaking anything.

    As it turns out, Filter Verifier walks the stack and tries to match the address of the calling instruction to a filter.

    FLTMGR!FltvFreeGenericWorkItem excerpt:
    fffff800`21d803e1 48ff154836fdff  call    qword ptr [FLTMGR!_imp_RtlGetCallersAddress (fffff800`21d53a30)]
    fffff800`21d803e8 0f1f440000      nop     dword ptr [rax+rax]
    fffff800`21d803ed 488b4c2438      mov     rcx,qword ptr [rsp+38h]
    fffff800`21d803f2 e809e2ffff      call    FLTMGR!FltpvGetFilterFromCallerAddress (fffff800`21d7e600)

    In our case, the compiler optimized the call instruction for a jmp instruction, which erases our driver off the stack. Filter Manager cannot not find our filter and so we're left with an outstanding work item.

      224 fffff800`1e219b36 4883c430        add     rsp,30h
      224 fffff800`1e219b3a 5f              pop     rdi
      223 fffff800`1e219b3b 48ff25f6440300  jmp     qword ptr [Parity!_imp_FltFreeGenericWorkItem (fffff800`1e24e038)]  Branch

    This can only happen if FltFreeGenericWorkItem is the last line of the function so I re-ordered the function to make our "leak" magically disappear :-)

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

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!
Kernel Debugging 30 January 2023 Live, Online
Developing Minifilters 20 March 2023 Live, Online
Internals & Software Drivers 17 April 2023 Live, Online
Writing WDF Drivers 22 May 2023 Live, Online