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.
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.
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
2 Likes