Hi,
My minifilter driver redirects requests to some folder to other location using shadow file objects. I fill FsContext with a custom FSRTL_ADVANCED_FCB_HEADER and FsContext2 with other custom data.
The driver works fine but I would like to make it unloadable, if possible.
As you can imagine, if I unload the driver while a FO is opened, I got a BSOD because the lower driver (like NTFS.SYS) cannot understand the fields.
Is there a method to leave the original FO in some “safe” state? No matter if
subsequent calls returns errors but want to avoid a BSOD.
Might be setting both fields to NULL. No idea.
Thanks,
Mauro.
I don’t think that is possible at least in any conventional unload sense.
You of course keep track of all your opened and shadowed files. You could
first try to disable the redirect. This would render your minifilter as
passthrough.
Now all you have to do is wait until all your SFOs are gone and notifiy the
UM app that does the unloading that it is safe to unload. At that point the
unload could be sent safely.
I do not believe and “instant” unload would be possible without corrupting
the system.
Now you may be thinking how can I force the opened files to be closed. This
is another story and really there is no way.
Unless you terminate let’s say the parent process that has opened handles
to them, and then reopen the file
with no intermediate buffering and close them again. I think this should
get you rid of all the opened instances of the files. But again this would
mean killing the process that makes usage of your filter’s redirect, which
no product in its right mind would do.
Usually such filters do not have a requirement to be unloaded, I would be
surprised if you would give me a good reason why this cannot wait a reboot.
Regards,
Gabriel
www.kasardia.com
Windows Kernel Driver Consulting
On Wed, Jun 29, 2016 at 3:15 PM, wrote:
> Hi,
>
> My minifilter driver redirects requests to some folder to other location
> using shadow file objects. I fill FsContext with a custom
> FSRTL_ADVANCED_FCB_HEADER and FsContext2 with other custom data.
>
> The driver works fine but I would like to make it unloadable, if possible.
>
> As you can imagine, if I unload the driver while a FO is opened, I got a
> BSOD because the lower driver (like NTFS.SYS) cannot understand the fields.
>
> Is there a method to leave the original FO in some “safe” state? No matter
> if
> subsequent calls returns errors but want to avoid a BSOD.
>
> Might be setting both fields to NULL. No idea.
>
> Thanks,
> Mauro.
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
>
–
Bercea. G.</http:>
Hi Gabriel,
The problem I’m facing is the following: Although I cancel redirection and unmount the redirected volume, some times, explorer.exe holds references to some .ini files but because no i/o activity, those files remains opened without receiving some error.
The reason is basically to allow a software update without rebooting (not my decision).
With Process Hacker one can close handles in other processes (praying the process will not crash because of this), but wanted to know if there exists some “clean” method.
Regards,
Mauro.
>volume, some times, explorer.exe holds references to some .ini files
That’s really very strange.
Is there any PnP notification sent during your dismount? Explorer should listen to it and close the handles.
Anyway you can solve this. In your dismount path, turn all FOs to “killed” state (design this state, all activities must return errors), dissociate it from the lower FO and close the lower FO, so you will not hold any lower FOs open after your dismount.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
Hi Maxim,
I don’t understand very well what you mean. A scenario is the following:
Explorer opens C:\Users\admin\Downloads\desktop.ini. C:\Users\admin\Downloads is redirected to D:\Downloads. Drive C is a harddisk and drive D is a mounted VHD volume.
First I remove the redirection and after this I unmount the VHD image.
The upper FO is alive and the problem is it can take several minutes until explorer.exe decides to do some I/O and close the file because of the returned error.
Regards,
Mauro.