How should I handle with IRP_MJ_FILE_SYSTEM_CONTROL

NTFSD
1

Hi, I’m developing an encryption filter based on minifilter.
Now I use daemon tools to load an img file, this seems to lead to an IRP_MJ_FILE_SYSTEM_CONTROL request. I handle this request by returing FLT_PREOP_SUCCESS_NO_CALLBACK in Pre-Routine.
(I should say my filter use shadowFileObject technology, but I’m sure that in this situation, the Data->Iopb->TargetFileObject is a normal one, so I just ignore the process which is used for substituting the shadowFileObject)
So it should be a quite easy process, I just return FLT_PREOP_SUCCESS_NO_CALLBACK for IRP_MJ_FILE_SYSTEM_CONTROL, but my system(Windows XP Sp2) go into a no-responding state when I open explorer.exe, so I’m a little confused, shouldn’t I just return FLT_PREOP_SUCCESS_NO_CALLBACK for this kind of request?

2

> shouldn’t I just return FLT_PREOP_SUCCESS_NO_CALLBACK for this kind of

request?

Only if you think that it cannot possible be for you.

Have you considered Oplocks? have you considered Movefile? There are
probably others. As always start by looking just look at FAT and ask
yourself if this is something you care about.

/R

3

Thanks rod.
But what I mean is I do not interested in this kind of request in the current situation, so I just try to return FLT_PREOP_SUCCESS_NO_CALLBACK for it.
What I do not understand is how can system become unstable after return operation, my filter do nothing except bypass it to lower dirver.

4

I have get the answer, I should not return FAST_IO_DISALLOW for IRP_MJ_VOLUME_MOUNT, which is euqal to a MinorFunction in IRP_MJ_FILE_SYSTEM_CONTROL.
Now my filter runs well, thanks again! :slight_smile:

5

> But what I mean is I do not interested in this kind of request in the

current situation

I’d still think rather carefully about movefile.