Filter manager object tracking out of sync

OSR_Community_User

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_Brender

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.

Scott
This posting is provided "AS IS" with no warranties, and confers no rights.

Alnoor_Allidina

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