I’m in a situation where my WDM driver (altitude: “Filter”) has problem with Microsoft miniFilter drivers and wondering what is the best way to handle this. What I would like to do is to prevent the minifilter driver from acceessing volume so that I can get exclusive access and send LOCK FSCTL. Any article on how legacy driver can co-exist with miniFilter drivers.
Thanks in advance.
It difficult to tell whether this is a bug in your driver (because you
should be able to handle behavior from filters both above and below you
regardless of implemention technology) or in the other driver (because they
should be listening to your IRP_MJ_LOCK).
If however, this is an altitude problem then your only tool is driver Start
type and load order group.
Rod
I’m in a situation where my WDM driver (altitude: “Filter”) has problem
with
Microsoft miniFilter drivers and wondering what is the best way to handle
this. What I would like to do is to prevent the minifilter driver from
acceessing volume so that I can get exclusive access and send LOCK
FSCTL. Any article on how legacy driver can co-exist with miniFilter
drivers.
One thing you could do is try your filter in conjunction with the
MetadataManager WDK minifilter sample and see if you see the same
behavior… If so you could start your investigation there.
If the altitudes are properly set up then there are no additional rules that
govern the interaction between legacy and minifilters with respect to the
lock operation (that I’m aware of).
Thanks,
Alex.
Here is the output of fltmc.exe utility
Filter Name Num Instances Altitude Frame
429998.99
Datascrn 0 261000 0
luafv 1 135000 0
Quota 0 125000 0
This tells me that I’m above the Quota driver, but my FSCTL_LOCK_VOLUME command fails with error 0xc0000022. That means driver below me, like quota, are blocking my request with STATUS_ACCESS_DENIED. So how would I prevent that. If I run “fltmc detach” and then issue lock comand, it would work. Bur from kernel, how can I do that.
BTW, I couldn’t find any refrence to IRP_MJ_LOCK command. So how would I handle it in my driver.
FSCTL_LOCK_VOLUME can fail. It doesn’t necessarily mean that a filter is
failing it, it could be the file system itself.
Quoting the documentation here
http://msdn.microsoft.com/en-us/library/aa364575(VS.85).aspx (or search for
" FSCTL_LOCK_VOLUME Control Code"):
"If the specified volume is a system volume or contains a page file, the
operation fails.
If there are any open files on the volume, this operation will fail.
Conversely, success of this operation indicates there are no open files.
"
Why do you need to lock the volume ? FSCTL_LOCK_VOLUME doesn’t only prevent
minifilters from accessing the volume, it prevents everyone from accessing
it.
Thanks,
Alex.
I know FSCTL_LOCK_VOLUME is brutal but that is what we have been doing. I agree with your comments but problem recently started showing up on servers with Quota. If you unload the Quota driver using command line tool fltmc.exe, problem doesn’t happen. So I’m tried to figure out what is the best way to go for locking the volume.
Well, in theory any minifilter (including Quota) should not prevent the user
to lock the volume. Have you tried issuing the lock request from user mode
?(from an account that has permission, of course).
If Quota in fact prevents the volume lock (by not closing its handles or by
failing the request), then one thing you could try is to get an implicit
volume lock (check out the Metadata Manager sample in the WDK), in the hope
that Quota would honor that one.
Finally, there are a lot of interfaces for managing the quota functionality
so perhaps you could simply use those to (temporarily) disable quota on the
volume you need to lock (in the hope that the Quota filter would no longer
interfere with volume locks if it’s not monitoring a volume).
Thanks,
Alex.