Is this status code so special? When I set this code (Data->IoStatus.Status) in pre-create and return FLT_PREOP_COMPLETE mup produces a Bugcheck MUP_FILE_SYSTEM ( MUP_BUGCHECK_NO_FILECONTEXT). FAT and NTFS work well.
MSDN says about PFLT_PRE_OPERATION_CALLBACK:
“If this routine returns FLT_PREOP_COMPLETE, it must set the callback data structure’s IoStatus.Status field to the final NTSTATUS value for the I/O operation. This NTSTATUS value cannot be STATUS_PENDING. For a cleanup or close operation, it must be a success NTSTATUS value other than STATUS_PENDING because cleanup and close operations cannot fail.”
Currently I found the way when MUP works well too. I don’t return FLT_PREOP_COMPLETE in this situation and simply return FLT_PREOP_SUCCESS_WITH_CALLBACK.
PS: Tested on Vista SP1 + all updates. MUP.sys has a date 18.01.2008.
If this is what I think it is, then it is a bug in MUP.
It always bugchecks if it sees a close for a file object for which it has
not seen a create. By returning FLT_PREOP_SUCCESS_WITH_CALLBACK that is
what you are causing to happen. This is, I believe is Win7 but I don’t know
about down rev hot fixes.
This is extremely unsavory, but you can probably spot the fact that you have
provoked such a case in your cleanup or close PreCall handler and just
return FLT_PREOP_SUCCESS_WITH_CALLBACK.
wrote in message news:xxxxx@ntfsd… > Hello, guru! > > Is this status code so special? When I set this code > (Data->IoStatus.Status) in pre-create and return FLT_PREOP_COMPLETE mup > produces a Bugcheck MUP_FILE_SYSTEM ( MUP_BUGCHECK_NO_FILECONTEXT). FAT > and NTFS work well. > > MSDN says about PFLT_PRE_OPERATION_CALLBACK: > > “If this routine returns FLT_PREOP_COMPLETE, it must set the callback data > structure’s IoStatus.Status field to the final NTSTATUS value for the I/O > operation. This NTSTATUS value cannot be STATUS_PENDING. For a cleanup or > close operation, it must be a success NTSTATUS value other than > STATUS_PENDING because cleanup and close operations cannot fail.” > > Currently I found the way when MUP works well too. I don’t return > FLT_PREOP_COMPLETE in this situation and simply return > FLT_PREOP_SUCCESS_WITH_CALLBACK. > > PS: Tested on Vista SP1 + all updates. MUP.sys has a date 18.01.2008. > >
I don’t have source with me so i’m not 100% sure but i think STATUS_OBJECT_NAME_EXISTS is a success code (in the sense that NT_SUCCESS will return true) so if you’re completing a create with this code it is possible that MUP believes the create has completed successfully and that the FILE_OBJECT should now be initialized. Based on the name of the bugcheck i’d guess that it checks if the FsContext is not null and bugchecks if it is.
Why (or when) are you returning STATUS_OBJECT_NAME_EXISTS ?
So yes- no high bit- not a fail code [technically it’s a warning code].
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Alexandru Carp
Sent: Wednesday, February 04, 2009 7:47 AM
To: Windows File Systems Devs Interest List
Subject: RE: Re:[ntfsd] STATUS_OBJECT_NAME_EXISTS in pre-create
I don’t have source with me so i’m not 100% sure but i think STATUS_OBJECT_NAME_EXISTS is a success code (in the sense that NT_SUCCESS will return true) so if you’re completing a create with this code it is possible that MUP believes the create has completed successfully and that the FILE_OBJECT should now be initialized. Based on the name of the bugcheck i’d guess that it checks if the FsContext is not null and bugchecks if it is.
Why (or when) are you returning STATUS_OBJECT_NAME_EXISTS ?