Deferring driver unload

I have a minifilter driver which shadows FILE_OBJECTs to create the illusion that create operations succeeded when the ACLs would normally have caused them to fail (see earlier post).
If I unload my driver while one of these FILE_OBJECTs is open, that FILE_OBJECT will find its way to the ntfs driver and cause a BSOD because the whole approach hangs on my driver being present in order to switch these invalid ‘upper’ FILE_OBJECTs for corresponding valid ‘lower’ ones. Is there a way I can defer my driver being unloaded until none of these upper FILE_OBJECTs are in existence?

Many thanks,

Ian

I usually deal with by making my driver not unloadable.

A trick for testing is to refuse the “may I detach” callback at that stage filter manager will refuse to unload. I suppose that that stage you could load a trigger to fire when the last GO goes away which would call FltUnload…

Great, thanks Rod. Will that still work if it’s a mandatory unload? Also, I half expected to be told that there’s some referencing mechanism I should use to achieve this, maybe a way of creating a relationship between open FOs and my filter. I presume that no such mechanism exists?

Will that still work if it’s a mandatory unload?
Put it another way if it doesn’t work because its mandatory then it won’t matter that you have dangling references (because the system is about to go away and file operations have mostly/usually stopped

I half expected to be told that there’s some referencing mechanism I should use to achieve this, maybe a way of creating a relationship
There’s a circularity issue here that gets in the way.

When your filter is unloaded all your data structures are detached and dereferenced. So if you are relying on the dereference to trigger a detach then you will go around and around unless you are careful.

Now, if I had to design something like this I would keep special note of the FilterContexts associated to the fileobjects which you own. Then when this list goes empty is it safe to allow unloads, and if you are in the “trying to unload” state it is safe to try and FltUnload. Of course you want to stop creating these file objects when you are trying to unload.

My bet is that your code may take a long time to fire, but you will be very glad of the fsutil volume dismount d: comment

Specifying the FLTFL_REGISTRATION_DO_NOT_SUPPORT_SERVICE_STOP in your flags in the filter registration structure before calling FltRegister filter will indicate you don’t unload, even if the mandatory flag would have otherwise been set.

Thank you both very much. After experimenting I decided to deny the unload if I still have active FOs and otherwise allow it.