FO_FILE_OPEN_CANCELLED

Hi,
I need your help in a understating of concept of with FO_ flags.
In a shadow file object design what flags are set by the Filter driver’s Pre-Create
who does set the FO_FILE_OPEN_CANCELLED flag on FileObject ?
Is it an appropriate assumption that IO manager will do it after Handles are created

Thanks in advance.
-MAneesh

Set by IoCancelFileOpen or FltCancelFileOpen. File system and filter drivers do not set this flag directly.

It depends. There is no definitive guide so do not account for any particular behavior. FO_FILE_* flags are mostly managed by the IO Manager.

By design IoCancelFileOpen must be called before IRP_MJ_CREATE completes so no handles can exist for a file object and no handles are created if IoCancelFileOpen has been called as the IO Manager receives an error for IRP_MJ_CREATE request.
Sometimes you can find yourself in a situation where an underlying filter created a handle ( e.g. by a call to ObOpenObjectByPointer ) for a file object for which IoCancelFileOpen is being called by an upper filter. A workaround would be to check for the FO_HANDLE_CREATED flag.

Thanks Slava ,
its a great help ,allthough need more info in the same context.
As you said IoCancelFileOpen must be called after checking for
FO_HANDLE_CREATED. in a scenario it is called postCreate calls.
but , Who is responsible to set FO_HANDLE_CREATED on File Object.
is it the driver who sets complete on IRP (Create ) ( or who
returns FLT_PREOP_COMPLETE ).
or is it IO-manager.
Thanks and advance

  • Maneesh

On Sun, Jul 23, 2017 at 7:01 PM, xxxxx@hotmail.com
wrote:

>


>
> Set by IoCancelFileOpen or FltCancelFileOpen. File system and filter
> drivers do not set this flag directly.
>
>


>
> It depends. There is no definitive guide so do not account for any
> particular behavior. FO_FILE_* flags are mostly managed by the IO Manager.
>
>


>
> By design IoCancelFileOpen must be called before IRP_MJ_CREATE completes
> so no handles can exist for a file object and no handles are created if
> IoCancelFileOpen has been called as the IO Manager receives an error for
> IRP_MJ_CREATE request.
> Sometimes you can find yourself in a situation where an underlying filter
> created a handle ( e.g. by a call to ObOpenObjectByPointer ) for a file
> object for which IoCancelFileOpen is being called by an upper filter. A
> workaround would be to check for the FO_HANDLE_CREATED flag.
>
> —
> 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&gt;
>


मनीष आनंद सामरिया
Maneesh Anand.Samria</http:>

The IO Manager should set it after IRP_MJ_CREATE completes with STATUS_SUCCESS and a handle is created for a file object. So it is actually a bug when you need to call IoCancelFileOpen for a file object with FO_HANDLE_CREATED as it is too late to do this for a file object after IRP_MJ_CREATE completed. In the Filter Manager parlance “completed” means that all post create callbacks have been called and returned, though there is something left for the IO Manager to actually complete the request.

I can’t verify right now but I think ObOpenObjectByPointer doesn’t set FO_HANDLE_CREATED leaving an opportunity for a rogue filter to undermine the system. Calling ObOpenObjectByPointer for a file object without FO_HANDLE_CREATED set is a bug by itself but comes without consequences for a while.

There is a HandleCount field in the _OBJECT_HEADER structure, but it is not available from the driver without making it OS version dependent.

I believe that a file object with FO_HANDLE_CREATED in a post create callback might indicate a bug as it should not be set at this phase of IRP_MJ_CREATE processing. There should not be handles for a file object received in a post create callback.

Thanks Slava,
you explained it in very fine way :slight_smile: .
As I understand , a filter driver should not try to set FO_HANDLE_CREATED.
your explanation has helped a lot, I appreciate it.
Thanks once again.
-Maneesh

On Mon, Jul 24, 2017 at 1:08 AM, xxxxx@hotmail.com
wrote:

>


>
> The IO Manager should set it after IRP_MJ_CREATE completes with
> STATUS_SUCCESS and a handle is created for a file object. So it is actually
> a bug when you need to call IoCancelFileOpen for a file object with
> FO_HANDLE_CREATED as it is too late to do this for a file object after
> IRP_MJ_CREATE completed. In the Filter Manager parlance “completed” means
> that all post create callbacks have been called and returned, though there
> is something left for the IO Manager to actually complete the request.
>
> I can’t verify right now but I think ObOpenObjectByPointer doesn’t set
> FO_HANDLE_CREATED leaving an opportunity for a rogue filter to undermine
> the system. Calling ObOpenObjectByPointer for a file object without
> FO_HANDLE_CREATED set is a bug by itself but comes without consequences for
> a while.
>
> There is a HandleCount field in the _OBJECT_HEADER structure, but it is
> not available from the driver without making it OS version dependent.
>
> I believe that a file object with FO_HANDLE_CREATED in a post create
> callback might indicate a bug as it should not be set at this phase of
> IRP_MJ_CREATE processing. There should not be handles for a file object
> received in a post create callback.
>
> —
> 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&gt;
>


मनीष आनंद सामरिया
Maneesh Anand.Samria</http:>