Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Deferring driver unload

IanMIanM Member - All Emails Posts: 32

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

Comments

  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,017

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

  • IanMIanM Member - All Emails Posts: 32

    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?

  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,017

    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

  • Gabriel_BerceaGabriel_Bercea Member - All Emails Posts: 482

    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.

    Cheers,
    Gabriel

  • IanMIanM Member - All Emails Posts: 32

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

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 25 Feb 2019 OSR Seminar Space
Developing Minifilters 8 April 2019 OSR Seminar Space