Hello,
in PostCreate callback, I call MmCreateSection + ObInsertObject in the process context (using KeStackAttachProcess), then if something fails, I call NtClose to close the handle in that process context and call FltCancelFileOpen. It leads to bugcheck 0xF5 (0x6A, 0x8166BF10, 0, 0). Could you please reveal what that bugcheck means prior to plugfest yet?
thanks,
Petr Kurtin
ALWIL Software
I don’t know if this is exactly your problem,
but I remember that if ObInsertObject fails,
it dereferences the file object. So in this case,
you must not dereference the file object.
L.
You cannot cancel an open once a handle is created. That’s what the
bugcheck means. Granted you created the handle & closed it in kernel,
unfortunately the file object flags still reflect FO_HANDLE_CREATED,
even if it is closed. This is to prevent filters from trying to cancel
opens with outstanding handles. We could potentially change this to let
the cancel succeed if the handle count is zero -however: I’m very
curious why you are creating a handle for it yourself: the handle is
created when the create is successful automatically for the user. You
should not be doing ObInsertObject() on user file objects.
Creating yourself a handle for a user file object in the create path is
a bad practice because the filters above you may decide to fail the open
(which they cannot even if you didn’t fail, but let the handle exist
before your return). So since you will have to close the handle anyway
before you return from your create completion, there is really no point
for your filter to create a handle. If you wish to do i/o you can issue
i/o using the file object directly.
Ravi
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Petr Kurtin
Sent: Monday, November 29, 2004 3:47 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FilterManager and FltCancelFileOpen
Hello,
in PostCreate callback, I call MmCreateSection + ObInsertObject in
the process context (using KeStackAttachProcess), then if something
fails, I call NtClose to close the handle in that process context and
call FltCancelFileOpen. It leads to bugcheck 0xF5 (0x6A, 0x8166BF10, 0,
0). Could you please reveal what that bugcheck means prior to plugfest
yet?
thanks,
Petr Kurtin
ALWIL Software
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
Thanks for your answer. In postCreate callback I create pSectionObject (MmCreateSection with given FileObject), then ObInsertObject (I get mapHandle variable). Then I call user-mode scanning part of antivirus (via FltSendMessage - where I use that mapHandle), this handle is closed in user-mode. If file is infected, I’d like to call FltCancelFileOpen.
pk
“Ravisankar Pudipeddi” wrote in message news:xxxxx@ntfsd…
You cannot cancel an open once a handle is created. That’s what the bugcheck means. Granted you created the handle & closed it in kernel, unfortunately the file object flags still reflect FO_HANDLE_CREATED, even if it is closed. This is to prevent filters from trying to cancel opens with outstanding handles. We could potentially change this to let the cancel succeed if the handle count is zero -however: I’m very curious why you are creating a handle for it yourself: the handle is created when the create is successful automatically for the user. You should not be doing ObInsertObject() on user file objects.
Creating yourself a handle for a user file object in the create path is a bad practice because the filters above you may decide to fail the open (which they cannot even if you didn’t fail, but let the handle exist before your return). So since you will have to close the handle anyway before you return from your create completion, there is really no point for your filter to create a handle. If you wish to do i/o you can issue i/o using the file object directly.
Ravi
------------------------------------------------------------------------------
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Petr Kurtin
Sent: Monday, November 29, 2004 3:47 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FilterManager and FltCancelFileOpen
Hello,
in PostCreate callback, I call MmCreateSection + ObInsertObject in the process context (using KeStackAttachProcess), then if something fails, I call NtClose to close the handle in that process context and call FltCancelFileOpen. It leads to bugcheck 0xF5 (0x6A, 0x8166BF10, 0, 0). Could you please reveal what that bugcheck means prior to plugfest yet?
thanks,
Petr Kurtin
ALWIL Software
—
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
What are the parameters for FltCancelOpen() you are passing in ?
Has the handle for the file object been already created (i.e. you
returned from post-create and then attempted to cancel later)?
Like I said, this bugcheck happens only when a handle has already been
created for the file object you were attempting to cancel open for.
Make sure none of the APIs you are calling are producing a handle for
it. Check the file object flags for FO_HANDLE_CREATED
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Petr Kurtin
Sent: Monday, November 29, 2004 6:03 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] FilterManager and FltCancelFileOpen
Thanks for your answer. In postCreate callback I create pSectionObject
(MmCreateSection with given FileObject), then ObInsertObject (I get
mapHandle variable). Then I call user-mode scanning part of antivirus
(via FltSendMessage - where I use that mapHandle), this handle is closed
in user-mode. If file is infected, I’d like to call FltCancelFileOpen.
pk
“Ravisankar Pudipeddi” wrote in
message news:xxxxx@ntfsd…
You cannot cancel an open once a handle is created. That’s what
the bugcheck means. Granted you created the handle & closed it in
kernel, unfortunately the file object flags still reflect
FO_HANDLE_CREATED, even if it is closed. This is to prevent filters from
trying to cancel opens with outstanding handles. We could potentially
change this to let the cancel succeed if the handle count is zero
-however: I’m very curious why you are creating a handle for it
yourself: the handle is created when the create is successful
automatically for the user. You should not be doing ObInsertObject() on
user file objects.
Creating yourself a handle for a user file object in the create
path is a bad practice because the filters above you may decide to fail
the open (which they cannot even if you didn’t fail, but let the handle
exist before your return). So since you will have to close the handle
anyway before you return from your create completion, there is really no
point for your filter to create a handle. If you wish to do i/o you can
issue i/o using the file object directly.
Ravi
________________________________
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Petr Kurtin
Sent: Monday, November 29, 2004 3:47 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FilterManager and FltCancelFileOpen
Hello,
in PostCreate callback, I call MmCreateSection +
ObInsertObject in the process context (using KeStackAttachProcess), then
if something fails, I call NtClose to close the handle in that process
context and call FltCancelFileOpen. It leads to bugcheck 0xF5 (0x6A,
0x8166BF10, 0, 0). Could you please reveal what that bugcheck means
prior to plugfest yet?
thanks,
Petr Kurtin
ALWIL Software
—
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
—
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