FltCreateFile() problem

NTFSD
1

Hi,

we are facing problems with using FltCreateFile();

Our current implementation goes as this:

status = FltCreateFile( Filter, /* filter */
FltObjects->FilterInstance, /*instance*/ //
&fileHandle, // fileHandle
GENERIC_READ|GENERIC_WRITE|DELETE, // desired access
&objectAttributes, // object attributes
&ioStatusBlock, // iostatusblock
NULL, // allocation size
FILE_ATTRIBUTE_NORMAL, // file attributes
0, //share access
FILE_OPEN,
FILE_NON_DIRECTORY_FILE ,
NULL, 0, IO_IGNORE_SHARE_ACCESS_CHECK
);

We are passing FilterInstace of our MiniFilter to this function, but we are still getting back create requests on callback routine for our mini filter.

We were in the impression that passing FilterInstance will generate and forward the IRP, only to filter instances that are below us.

We are using FLtObjects->FilterInstance, received in call back routine for IRP_MJ_SET_INFORMATION;

we also tried using FilterInstance put in InstanceContext (using FltSetInstanceContext in instancesetup call back routine), but the result was same.

Has any body faced similar problem, or is there any thing wrong in our approach:

basically What we want to achieve is when we call FltCreateFile() from our FIlter the IRP generated should not come back to our filter but should be directed towards filters attached at lower levels in the stack, then our filter.

sorry for my bad english any help suggestion would be greatly appreciated.

2

You need to read the documentation for FltCreateFile, specifically for the
Instance parameter.

Then you need to remove FILE_NON_DIRECTORY_FILE from your call.

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@rsystems.com
Sent: Monday, January 08, 2007 7:44 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltCreateFile() problem

Hi,

we are facing problems with using FltCreateFile();

Our current implementation goes as this:

status = FltCreateFile( Filter, /* filter */
FltObjects->FilterInstance, /*instance*/ //
&fileHandle, // fileHandle
GENERIC_READ|GENERIC_WRITE|DELETE, // desired access &objectAttributes, //
object attributes &ioStatusBlock, // iostatusblock NULL, // allocation size
FILE_ATTRIBUTE_NORMAL, // file attributes 0, //share access FILE_OPEN,
FILE_NON_DIRECTORY_FILE , NULL, 0, IO_IGNORE_SHARE_ACCESS_CHECK );

We are passing FilterInstace of our MiniFilter to this function, but we are
still getting back create requests on callback routine for our mini filter.

We were in the impression that passing FilterInstance will generate and
forward the IRP, only to filter instances that are below us.

We are using FLtObjects->FilterInstance, received in call back routine for
IRP_MJ_SET_INFORMATION;

we also tried using FilterInstance put in InstanceContext (using
FltSetInstanceContext in instancesetup call back routine), but the result
was same.

Has any body faced similar problem, or is there any thing wrong in our
approach:

basically What we want to achieve is when we call FltCreateFile() from our
FIlter the IRP generated should not come back to our filter but should be
directed towards filters attached at lower levels in the stack, then our
filter.

sorry for my bad english any help suggestion would be greatly appreciated.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Hi Dan,
Thanks for the reply,
We did implemented what you suggested, surprisingly that does not change the resutls,

What we found is that on the Target Machine we have CA Anti-Virus installed and running, when it is running , any create operation performed by our MiniFilter comes back to as in the form of IRP_MJ_CREATE, which we are not able to handle.

So to be summarize what I meant is :

The scenario that gives problem is:

When an Anti-Virus is installed, and our MiniFilter calls FltCreateFile() with appropriate FilterInstance, we get the create request back in our IRP_MJ_CREATE call back implementation, analyzing it in FileSpy also shows the newly generated IRP, the IRP is not nested either,it is thsi IRP that we are not able to differentiate and the call seems to get looped infinitely.

The scenario that works:
When the Anti-Virus is not installed our implementation works we don;t get nested create requests.

Any suggestions of how to handle/avoid the second create requested generated most probably by Anti Virus or what we could be doing wrong here.

we are using CA Anti-Virus, approved for Vista.

regards
Mohan

4

Then you need to make sure you are loaded below CA AV.

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@rsystems.com
Sent: Tuesday, January 09, 2007 9:39 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] FltCreateFile() problem

Hi Dan,
Thanks for the reply,
We did implemented what you suggested, surprisingly that does not change the
resutls,

What we found is that on the Target Machine we have CA Anti-Virus installed
and running, when it is running , any create operation performed by our
MiniFilter comes back to as in the form of IRP_MJ_CREATE, which we are not
able to handle.

So to be summarize what I meant is :

The scenario that gives problem is:

When an Anti-Virus is installed, and our MiniFilter calls FltCreateFile()
with appropriate FilterInstance, we get the create request back in our
IRP_MJ_CREATE call back implementation, analyzing it in FileSpy also shows
the newly generated IRP, the IRP is not nested either,it is thsi IRP that we
are not able to differentiate and the call seems to get looped infinitely.

The scenario that works:
When the Anti-Virus is not installed our implementation works we don;t get
nested create requests.

Any suggestions of how to handle/avoid the second create requested generated
most probably by Anti Virus or what we could be doing wrong here.

we are using CA Anti-Virus, approved for Vista.

regards
Mohan

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

Okay, a couple things here if I understand what your problems are:

First, if you want to be sure a create/open doesn’t re-enter the top of the
stack directly from your call and is targeted below you, use
IoCreateFileSpecifyDeviceObjectHint(). If you’re on Vista, there’s
IoCreateFileEx() with is similar but with more functionality. Both are
documented in the WDK.

Second, if you’re seeing another create for the file you’re opening and you
know there’s an AV filter below you, what might be happening is that the
AV filter blocks the create and notifies a service to scan it. Now, it
could be that the service is performing another open and hence you see
another create. If the AV filter is doing that, there’s not much you can do
other than layer below the AV filter as Dan suggested or make your mini
robust enough to handle this situation.

You should request an altitude and make sure you correctly identify what
type of driver you’re using so that your altitude is lower than AV filters.
If your altitude is at the AV level or higher and you can’t or won’t change
it then you’d better make your mini handle this case. For in-house testing
purposes, try an altitude lower than the AV filter group and see if you get
the same results.

Just some suggestions.

jerry

wrote in message news:xxxxx@ntfsd…
> Hi,
>
> we are facing problems with using FltCreateFile();
>
> Our current implementation goes as this:
>
> status = FltCreateFile( Filter, /* filter */
> FltObjects->FilterInstance, /instance/ //
> &fileHandle, // fileHandle
> GENERIC_READ|GENERIC_WRITE|DELETE, // desired access
> &objectAttributes, // object attributes
> &ioStatusBlock, // iostatusblock
> NULL, // allocation size
> FILE_ATTRIBUTE_NORMAL, // file attributes
> 0, //share access
> FILE_OPEN,
> FILE_NON_DIRECTORY_FILE ,
> NULL, 0, IO_IGNORE_SHARE_ACCESS_CHECK
> );
>
> We are passing FilterInstace of our MiniFilter to this function, but we
> are still getting back create requests on callback routine for our mini
> filter.
>
> We were in the impression that passing FilterInstance will generate and
> forward the IRP, only to filter instances that are below us.
>
> We are using FLtObjects->FilterInstance, received in call back routine for
> IRP_MJ_SET_INFORMATION;
>
> we also tried using FilterInstance put in InstanceContext (using
> FltSetInstanceContext in instancesetup call back routine), but the result
> was same.
>
> Has any body faced similar problem, or is there any thing wrong in our
> approach:
>
> basically What we want to achieve is when we call FltCreateFile() from
> our FIlter the IRP generated should not come back to our filter but should
> be directed towards filters attached at lower levels in the stack, then
> our filter.
>
> sorry for my bad english any help suggestion would be greatly appreciated.
>

6

Thanks Jerry,
It seems you are right, that the Anti-virus sends the request to some services which generates a totally new create IRP, which our filter is not able to handle, lowering the filter altitude resolved that problem.

Thanks alot for all the help.

regards
Mohan Bisht