Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
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/
|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|
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.
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.
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.
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 :-)