Cancel a CREATE request from IRP_MJ_CREATE dispatch routine

Hi

I’m writing a FSD filter that supposed to fiter some create and open
requests to files.
I’ve read several posts here regarding to cancelling CREATE requests,
and from what i’ve understood, i’m supposed to use IoCancelFileOpen()
in my completion routine for IRP_MJ_CREATE and return an error status
from it.

My questions regarding to this are:

  1. Is the above process of terminating correct? did i miss something?
  2. Why there is no documentation on IoCancelFileOpen()? and where can
    i find one?
  3. Who’s PDEVICE_OBJECT i need to pass as the first param to IoCancelFileOpen?
  4. Instead of the above method, i can complete the IRP in my filter
    and return error status instead of passing it down to the underlying
    file system. Any reason not to do so? what is the diff between this
    method and the above one ?

Thanks!

>1. Is the above process of terminating correct? did i miss something?

i’m supposed to use IoCancelFileOpen()
in my completion routine for IRP_MJ_CREATE and return an error status
from it.

Returning an error status from a completion routine is meaningless. You
need to set the the status in Irp->IoStatus.Status, and return it from your
dispatch routine (which you can do because you have synchronized completion
back to your dispatch routine.)

  1. Why there is no documentation on IoCancelFileOpen()? and where can
    i find one?

It’s documented in the IFS kit.

  1. Who’s PDEVICE_OBJECT i need to pass as the first param to IoCancelFileOpen?

The device object of the driver immediately below yours in the filesystem
stack.

  1. Instead of the above method, i can complete the IRP in my filter
    and return error status instead of passing it down to the underlying
    file system. Any reason not to do so? what is the diff between this
    method and the above one ?

Failing the create in dispatch is much better if you have the necessary
information there. Only use IoCancelFileOpen if you have no other way.

  • Dan.

At 04:32 PM 6/21/2005 +0200, you wrote:

Hi

I’m writing a FSD filter that supposed to fiter some create and open
requests to files.
I’ve read several posts here regarding to cancelling CREATE requests,
and from what i’ve understood, i’m supposed to use IoCancelFileOpen()
in my completion routine for IRP_MJ_CREATE and return an error status
from it.

My questions regarding to this are:

  1. Is the above process of terminating correct? did i miss something?
  2. Why there is no documentation on IoCancelFileOpen()? and where can
    i find one?
  3. Who’s PDEVICE_OBJECT i need to pass as the first param to IoCancelFileOpen?
  4. Instead of the above method, i can complete the IRP in my filter
    and return error status instead of passing it down to the underlying
    file system. Any reason not to do so? what is the diff between this
    method and the above one ?

Thanks!


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

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Look at the bugs in IoCancelFileOpen() for cluse as to why this will fail.
Once the file system has seen the create and not failed it, you cannot just
set an error and return it as if it was never opened. You must clean up the
file system’s knowledge of this file and also any other filters that may
have seen it.

“Dan Kyler” wrote in message news:xxxxx@ntfsd…
>
>>1. Is the above process of terminating correct? did i miss something?
>> i’m supposed to use IoCancelFileOpen()
>>in my completion routine for IRP_MJ_CREATE and return an error status
>>from it.
>
> Returning an error status from a completion routine is meaningless. You
> need to set the the status in Irp->IoStatus.Status, and return it from
> your dispatch routine (which you can do because you have synchronized
> completion back to your dispatch routine.)
>
>>2. Why there is no documentation on IoCancelFileOpen()? and where can
>>i find one?
>
> It’s documented in the IFS kit.
>
>>3. Who’s PDEVICE_OBJECT i need to pass as the first param to
>>IoCancelFileOpen?
>
> The device object of the driver immediately below yours in the filesystem
> stack.
>
>>4. Instead of the above method, i can complete the IRP in my filter
>>and return error status instead of passing it down to the underlying
>>file system. Any reason not to do so? what is the diff between this
>>method and the above one ?
>
> Failing the create in dispatch is much better if you have the necessary
> information there. Only use IoCancelFileOpen if you have no other way.
>
> - Dan.
>
> At 04:32 PM 6/21/2005 +0200, you wrote:
>>Hi
>>
>>I’m writing a FSD filter that supposed to fiter some create and open
>>requests to files.
>>I’ve read several posts here regarding to cancelling CREATE requests,
>>and from what i’ve understood, i’m supposed to use IoCancelFileOpen()
>>in my completion routine for IRP_MJ_CREATE and return an error status
>>from it.
>>
>>My questions regarding to this are:
>>1. Is the above process of terminating correct? did i miss something?
>>2. Why there is no documentation on IoCancelFileOpen()? and where can
>>i find one?
>>3. Who’s PDEVICE_OBJECT i need to pass as the first param to
>>IoCancelFileOpen?
>>4. Instead of the above method, i can complete the IRP in my filter
>>and return error status instead of passing it down to the underlying
>>file system. Any reason not to do so? what is the diff between this
>>method and the above one ?
>>
>>Thanks!
>>
>>—
>>Questions? First check the IFS FAQ at
>>https://www.osronline.com/article.cfm?id=17
>>
>>You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

>Failing the create in dispatch is much better if you have the necessary

information there. Only use IoCancelFileOpen if you have no other way.

The only info i need is the file path and to know if the request came
from remote.
if i have these two, its preferred to fail the create in dispatch
routine and complete the irp myself ? what valuable information i can
get if I’ll send the request down ? (i ask cause most people do send
it down and try to cancel it afterwards…)

Returning an error status from a completion routine is meaningless. You
need to set the the status in Irp->IoStatus.Status, and return it from your
dispatch routine (which you can do because you have synchronized completion
.back to your dispatch routine.)

not that I’m gonna use it, but still, i don’t understand: i call
IoCancelFileOpen() from the completion routine and return error from
my dispatch routine ?! can you please describe this method (using
IoCancelFileOpen to cancel create) again ?

Look at the bugs in IoCancelFileOpen() for clues as to why this will fail.

David, i read about the bugs but still, most people ARE trying to use
this method instead of canceling the create from the dispatch routine.
Can you explain why?

Thank u all !

You never answered the question about having the IFS Kit for Windows Server
2003 SP1. If you don’t have it, you will not be successful. If you do,
then look at the FAQ on osronline and the docs and samples in the IFS Kit.
Also read the recent posts by Neal about IoCancelFileOpen(). There are some
patches for some versions of the OS that fix some of the problems with it.
Other filters, which I am certain you are not testing with, will actually
read from the file during their create processing. That will force cache
maps to be established that the unfixed version of IoCancelFileOpen() will
not handle correctly.

“Omer B” wrote in message news:xxxxx@ntfsd…
>Failing the create in dispatch is much better if you have the necessary
>information there. Only use IoCancelFileOpen if you have no other way.

The only info i need is the file path and to know if the request came
from remote.
if i have these two, its preferred to fail the create in dispatch
routine and complete the irp myself ? what valuable information i can
get if I’ll send the request down ? (i ask cause most people do send
it down and try to cancel it afterwards…)

>Returning an error status from a completion routine is meaningless. You
>need to set the the status in Irp->IoStatus.Status, and return it from your
>dispatch routine (which you can do because you have synchronized completion
.back to your dispatch routine.)

not that I’m gonna use it, but still, i don’t understand: i call
IoCancelFileOpen() from the completion routine and return error from
my dispatch routine ?! can you please describe this method (using
IoCancelFileOpen to cancel create) again ?

>Look at the bugs in IoCancelFileOpen() for clues as to why this will fail.

David, i read about the bugs but still, most people ARE trying to use
this method instead of canceling the create from the dispatch routine.
Can you explain why?

Thank u all !

Given that the estimable Mr. Craig apparently had problems with my first
response, I assume I was unclear.

Before we get to the meat of your problem, let me echo the admonitions of
others.

  1. Get the IFS kit and use the samples therein.
  2. Don’t steal filemon.
  3. As you say, you can use existing sources to learn. You can also learn
    very bad things from them. The IFS kit is your best source of samples.

As for your problem of failing a create, there are 2 ways to do it:

  1. Fail the request in create dispatch before sending it to the file system.
  2. Send it to the file system, and then use IoCancelFileOpen.

It sounds like you have the necessary information to do #1, and have
decided that you will take this route. So once you have decided in you
code that you need to fail the open, set the failure status in
Irp->IoStatus.Status, call IoCompleteRequest, and return the failure status
from your dispatch routine. Do this before calling IoCallDriver.

If you are going to use IoCancelFileOpen, first be familiar with its bugs
and limitations. On some versions of Windows, you will crash the system if
a filter below you has done I/O on the file object. On all versions, you
must not call it if FileObject->Flags has FO_HANDLE_CREATED set. To ensure
that IoCancelFileOpen is safe to use, you need certain operating system
patch levels. And as long as you are requiring those levels, you should
consider making your driver a Filter Manager minifilter. The minifilter
model is supported and documented in, of all places, the IFS kit.

Second, you need to be familiar with the rules for completing IRPs. You
must either return the same status value from your dispatch routine as is
in Irp->IoStatus.Status, OR you must mark the IRP pending and return
STATUS_PENDING from your dispatch routine. I do not recommend pending
create IRPs. First they are inherently synchronous, so there is seldom a
need to do so. Second, I have seen filters which cannot handle a return of
STATUS_PENDING from create. That’s their bug, but why provoke it if you
don’t have to?

In order to use IoCancelFileOpen, you first want to synchronize back to
your dispatch routine. Do this by setting a completion routine which sets
an event (passed as the Context arg), and returns
STATUS_MORE_PROCESSING_REQUIRED. In your dispatch routine, after calling
IoCallDriver, wait on the event before proceeding. There is an example of
how to synchronize back to dispatch in, of all places, the IFS kit.

Now you are back in dispatch, guaranteed to be at PASSIVE_LEVEL. The file
system has done it’s work to open the file, but the IRP has not been
completed and you own it. If you must fail the open at this point, call
IoCancelFileOpen, set the failure status in Irp->IoStatus.Status, call
IoCompleteRequest, and return the failure status from dispatch.

David, i read about the bugs but still, most people ARE trying to use
this method instead of canceling the create from the dispatch routine.
Can you explain why?

Who are “most people”? If you have the necessary information to fail the
create before sending it to the file system, there is absolutely no reason
to send it to the file system. It just causes unnecessary processing which
then needs to be undone.

  • Dan.

At 12:44 AM 6/22/2005 +0200, you wrote:

>Failing the create in dispatch is much better if you have the necessary
>information there. Only use IoCancelFileOpen if you have no other way.

The only info i need is the file path and to know if the request came
from remote.
if i have these two, its preferred to fail the create in dispatch
routine and complete the irp myself ? what valuable information i can
get if I’ll send the request down ? (i ask cause most people do send
it down and try to cancel it afterwards…)

>Returning an error status from a completion routine is meaningless. You
>need to set the the status in Irp->IoStatus.Status, and return it from your
>dispatch routine (which you can do because you have synchronized completion
.back to your dispatch routine.)

not that I’m gonna use it, but still, i don’t understand: i call
IoCancelFileOpen() from the completion routine and return error from
my dispatch routine ?! can you please describe this method (using
IoCancelFileOpen to cancel create) again ?

>Look at the bugs in IoCancelFileOpen() for clues as to why this will fail.

David, i read about the bugs but still, most people ARE trying to use
this method instead of canceling the create from the dispatch routine.
Can you explain why?

Thank u all !


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

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com