We are getting some crashes in fltmgr!FltpvDoLostObjectCheck when our driver is unloaded. Using “!fltkd.filter <flt_filter> 8 1” indicates we have a couple of FLT_GENERIC_WORKITEM’s outstanding.
We reviewed the code and found out the following use cases exist:
1) Function A allocates and queues work item and waits on an event that gets signaled inside the work item routine. Function A then frees the work item.
2) Function A allocates and queues work item and waits on an event that gets signaled inside the work item routine. The work item routine frees the work item.
3) Function A allocates and queues work item and returns. The work item routine frees the work item.
We use both DelayedWorkQueue and CriticalWorkQueue depending on what the work item is used for.
When we dump FLT_GENERIC_WORKITEM that is included in the output of “!fltkd.filter <flt_filter> 8 1” we get erratic results. In some cases it points to our work item function but in other cases it points to garbage.
What is the preferred place to free a work item? Does Filter Manager guarantee that all work item executes before unloading your mini-filter? If not, how do you free the work item and avoid this problem?</flt_filter></flt_filter>
From the documentation (FltAllocateGenericWorkItem):
To free the work item, a minifilter driver typically calls FltFreeGenericWorkItem from the worker routine that was specified in FltQueueGenericWorkItem.
Of course, the real trick is that there’s no “right” answer. It’s just about making sure it gets done.
As I understand it, Filter Manager does protect the queue for rundown - otherwise, what’s the point in using it?
I’ve not seen this personally, since I eschew using the global work queue in the first place (I’ve been burned too many times in the past AND I don’t want my background activity using higher priorities than foreground activities do). But your mileage may vary.
Tony
OSR
All of the 3 cases you describe seem valid but what I would do to chase this down, is allow only cases 2 and 3 to happen and not case 1.
See if you have the same issue. If not, then work that case out somehow, I don’t know why but I suspect that one to be it since I always free the workitem in the workitem callback itself all the time and did not have this issue, but then again I don’t use the Flt infrastructure for the workitems but rather the IoQueueWorkItem and friends.