Hello friends!
I'm using FltAllocateExtraCreateParameter in a kernel mini filter driver. Then I attach it to a file. What happens if my driver is unloaded after that? What happens with the cleanup routine? If the driver is unloaded before the cleanup routine is called, it’s not good.
According to the documentation of PFLT_INSTANCE_TEARDOWN_CALLBACK:
The filter manager calls the minifilter driver's InstanceTeardownCompleteCallback routine only after all outstanding I/O operations have been completed or drained.
So if my understanding is correct, if I attach an ECP at pre-create, the driver can’t be unloaded until it’s completed.
But what if I return a reparse status at pre-create? Then, a new pre-create operation is initiated, but the ECP is carried along. Is my driver still blocked from being unloaded? Or do I need to take care of it some way or another?
Thanks!
FltAllocateExtraCreateParameter takes out a rundown reference on your filter, so your call to FltUnregisterFilter is going to hang until this ECP goes away. If you attach it in PreCreate the ECP is associated with the underlying IRP and will be freed whenever it eventually completes.
Thanks, that’s what I hoped! And just to educate myself - is it documented somewhere? Some functions are listed here, but not that one.
Outstanding rundown references can also happen if the minifilter driver has called any routines that add a rundown reference to the minifilter driver's opaque filter pointer, such as FltObjectReference or FltGetFilterFromInstance, but did not subsequently call FltObjectDereference.
That is very strange documentation. Those should all be listed as “by way of example but not limitation” instead of making it sound like a comprehensive list.
Rule of thumb is that if an API takes a FLT_FILTER and/or a FLT_INSTANCE then it’s up to FltMgr to deal with “what happens if I unload before XYZ happens” problem. I’m not sure that this is clearly documented anywhere though.
1 Like