FltCreateFileEx returns NULL FileObject with status SUCCESS

Hi,
I have a situation where I got NULL FIleObject from FltCreateFileEx() and
status is SUCCESS. Due to this, I got a blue screen. Here is the output of
!analyze -v

NTFS_FILE_SYSTEM (24)
If you see NtfsExceptionFilter on the stack then the 2nd and 3rd
parameters are the exception record and context record. Do a .cxr
on the 3rd parameter and then kb to obtain a more informative stack
trace.
Arguments:
Arg1: 0019033d
Arg2: b8bc7250
Arg3: b8bc6f4c
Arg4: baf70fef

Debugging Details:

PEB is paged out (Peb.Ldr = 7ffdf00c). Type “.hh dbgerr001” for details
PEB is paged out (Peb.Ldr = 7ffdf00c). Type “.hh dbgerr001” for details

EXCEPTION_RECORD: b8bc7250 – (.exr 0xffffffffb8bc7250)
ExceptionAddress: baf70fef (Ntfs!NtfsDecodeFileObject+0x00000008)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 0000000c
Attempt to read from address 0000000c

CONTEXT: b8bc6f4c – (.cxr 0xffffffffb8bc6f4c)
eax=00000000 ebx=89737350 ecx=00000000 edx=89737350 esi=89737528
edi=b8bc7458
eip=baf70fef esp=b8bc7318 ebp=b8bc7318 iopl=0 nv up ei pl zr na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
Ntfs!NtfsDecodeFileObject+0x8:
baf70fef 8b410c mov eax,dword ptr [ecx+0Ch]
ds:0023:0000000c=???
Resetting default scope

PROCESS_NAME: NSS Quota Serve

CURRENT_IRQL: 0

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced
memory at 0x%08lx. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1: 00000000

EXCEPTION_PARAMETER2: 0000000c

READ_ADDRESS: 0000000c

FOLLOWUP_IP:
Ntfs!NtfsDecodeFileObject+8
baf70fef 8b410c mov eax,dword ptr [ecx+0Ch]

FAULTING_IP:
Ntfs!NtfsDecodeFileObject+8
baf70fef 8b410c mov eax,dword ptr [ecx+0Ch]

BUGCHECK_STR: 0x24

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER: from bafe1c81 to baf70fef

STACK_TEXT:
b8bc7318 bafe1c81 b8bc7458 00000000 b8bc737c Ntfs!NtfsDecodeFileObject+0x8
b8bc73e0 baf9acf5 b8bc7458 89737350 8c4c23c0 Ntfs!NtfsCommonQueryEa+0x40
b8bc7444 bafac02f b8bc7458 89737350 00000001 Ntfs!NtfsFsdDispatchSwitch+0xd2
b8bc7560 8081df85 8c29a718 89737350 89737350 Ntfs!NtfsFsdDispatchWait+0x1c
b8bc7574 f7966d28 89d33008 8cbe8890 00000000 nt!IofCallDriver+0x45
b8bc75a0 8081df85 8c4c23c0 89737350 89737350 fltmgr!FltpDispatch+0x152
b8bc75b4 f7966b25 00000000 89d33064 00000000 nt!IofCallDriver+0x45
b8bc75d8 f796766f b8bc75f8 8c27a020 00000000
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
b8bc7610 f7976b9d 8ad6bb80 dcc204b6 b7bf662d
fltmgr!FltPerformSynchronousIo+0xb9
b8bc7628 b7bf1296 8ad6bb80 89d33064 dec2e008 fltmgr!FltQueryEaFile+0x91
b8bc7674 b7bf1de6 8ad6bb80 00000000 e04cab20 DxSpy!DxGetMigrationData+0xe2
b8bc76cc b7bf2087 8ad6bb80 89fd3b10 dcd47258
DxSpy!DxGetMigrationInfoDir+0x1ba
b8bc773c f7969d70 8ad77f68 b8bc77d4 89fd3b10 DxSpy!DxPostDirCtrlSafe+0x26d
b8bc775c b7bf1b9c 8924e9dc b8bc77d4 89288750
fltmgr!FltDoCompletionProcessingWhenSafe+0x78
b8bc7794 b7bf2239 8924e9dc b8bc77d4 89fd3b10
DxSpy!DxDoPostOperationWhenSafe+0x6e
b8bc77b0 f7963b73 8924e9dc b8bc77d4 89288750 DxSpy!DxPostDirCtrl+0x1b
b8bc7818 f7965fc2 0024e980 89b03423 8924e980
fltmgr!FltpPerformPostCallbacks+0x1c5
b8bc782c f79664f1 8924e980 89b03248 b8bc786c
fltmgr!FltpProcessIoCompletion+0x10
b8bc783c 8081e123 8c27a020 89b03248 8924e980
fltmgr!FltpPassThroughCompletion+0x89
b8bc786c baf711dc dbfba338 e016e6c0 b8bc7a90 nt!IopfCompleteRequest+0xcd
b8bc787c baface44 b8bc7ae0 89b03248 00000000 Ntfs!NtfsCompleteRequest+0xc8
b8bc788c bafad4cb 89b03248 89b03420 8a8598b0 Ntfs!NtfsQueryDirectory+0xcd5
b8bc7a90 bafacdaa b8bc7ae0 89b03248 8c29a7f8 Ntfs!NtfsQueryDirectory+0xbc3
b8bc7ac4 bafacd15 b8bc7ae0 db482d28 8c4c23c0
Ntfs!NtfsCommonDirectoryControl+0xbc
b8bc7c34 8081df85 8c29a718 89b03248 89b03248
Ntfs!NtfsFsdDirectoryControl+0xad
b8bc7c48 f7966d28 8924e980 8cbe8890 00000000 nt!IofCallDriver+0x45
b8bc7c74 8081df85 8c4c23c0 89b03248 89b03248 fltmgr!FltpDispatch+0x152
b8bc7c88 f7966b25 8c27a020 89b03248 8bf4c460 nt!IofCallDriver+0x45
b8bc7cac f7966cf5 b8bc7ccc 8c27a020 00000000
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
b8bc7ce4 8081df85 8c27a020 89b03248 0269d840 fltmgr!FltpDispatch+0x11f
b8bc7cf8 808f54f9 b8bc7d64 0269d840 808ef9c8 nt!IofCallDriver+0x45
b8bc7d0c 808efa25 8c27a020 89b03248 8a8598b0
nt!IopSynchronousServiceTail+0x10b
b8bc7d30 808897ec 00000ab0 00000000 00000000 nt!NtQueryDirectoryFile+0x5d
b8bc7d30 7c82847c 00000ab0 00000000 00000000 nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0269f08c 00000000 00000000 00000000 00000000 0x7c82847c

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: Ntfs!NtfsDecodeFileObject+8

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Ntfs

IMAGE_NAME: Ntfs.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 45d6a04b

STACK_COMMAND: .cxr 0xffffffffb8bc6f4c ; kb

FAILURE_BUCKET_ID: 0x24_Ntfs!NtfsDecodeFileObject+8

BUCKET_ID: 0x24_Ntfs!NtfsDecodeFileObject+8

Followup: MachineOwner

5: kd> ub Ntfs!NtfsDecodeFileObject+0x8
Ntfs!NtfsInitializeIrpContext+0x106:
baf70fe3 90 nop
baf70fe4 90 nop
baf70fe5 90 nop
baf70fe6 90 nop
Ntfs!NtfsDecodeFileObject:
baf70fe7 8bff mov edi,edi
baf70fe9 55 push ebp
baf70fea 8bec mov ebp,esp
baf70fec 8b4d0c mov ecx,dword ptr [ebp+0Ch]
5: kd> u Ntfs!NtfsDecodeFileObject+0x8
Ntfs!NtfsDecodeFileObject+0x8:
baf70fef 8b410c mov eax,dword ptr [ecx+0Ch]
baf70ff2 8b5518 mov edx,dword ptr [ebp+18h]
baf70ff5 53 push ebx
baf70ff6 33db xor ebx,ebx
baf70ff8 3bc3 cmp eax,ebx
baf70ffa 8902 mov dword ptr [edx],eax
baf70ffc 0f846a130000 je Ntfs!NtfsDecodeFileObject+0x74 (baf7236c)
baf71002 385d20 cmp byte ptr [ebp+20h],bl

From the above code snippet, it is clear that BSOD occured while trying to
access offset into FileObject.

This FileObject is passed by us. As Highlighted above in stack trace, the
FileObject is NULL. Here is the code snippet which creates this FileObject

NTSTATUS DxGetMigrationInfoDir()
{
.
.
.
.
status = FltCreateFileEx(DxFltData.Filter, Instance, &hFile,
&pFO, FILE_READ_EA, &ObjectAttributes,
&IoStatus,
NULL, FILE_ATTRIBUTE_NORMAL, ShareAccess,
FILE_OPEN, CreateOptions,
NULL, 0, IO_IGNORE_SHARE_ACCESS_CHECK);

if ( !NT_SUCCESS(status) )
{
DbgPrint(“dxmfd!DxGetMigrationInfoDir: FltCreateFileEx failed!,
status: 0x%08X, file: %ws\n”, status, pFileName);
LOGERROR(EVTLOG_ERROR_MESSAGE, status, L"FltCreateFileEx failed");
goto ROUTINE_EXIT;
}

// Get migration information
status = DxGetMigrationData(Instance, pFO, MigrateInfo);
.
.
.

}

So FltCreateFileEx returned SUCCESS but fileobject is NULL. Documentation
does not indicate this possibility. Is It possible? Is it necessary that we
check for NULL FileObject also in addition to NT_SUCCESS(status).

Thanks
Ash

STATUS_REPARSE? What’s in the Iosb? And the Handle?

Is this reproducible? No other threads misbehaving?

“Ashish Goyal” wrote in message news:xxxxx@ntfsd…
Hi,
I have a situation where I got NULL FIleObject from FltCreateFileEx() and status is SUCCESS. Due to this, I got a blue screen. Here is the output of !analyze -v

NTFS_FILE_SYSTEM (24)
If you see NtfsExceptionFilter on the stack then the 2nd and 3rd
parameters are the exception record and context record. Do a .cxr
on the 3rd parameter and then kb to obtain a more informative stack
trace.
Arguments:
Arg1: 0019033d
Arg2: b8bc7250
Arg3: b8bc6f4c
Arg4: baf70fef

Debugging Details:
------------------

PEB is paged out (Peb.Ldr = 7ffdf00c). Type “.hh dbgerr001” for details
PEB is paged out (Peb.Ldr = 7ffdf00c). Type “.hh dbgerr001” for details

EXCEPTION_RECORD: b8bc7250 – (.exr 0xffffffffb8bc7250)
ExceptionAddress: baf70fef (Ntfs!NtfsDecodeFileObject+0x00000008)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 0000000c
Attempt to read from address 0000000c

CONTEXT: b8bc6f4c – (.cxr 0xffffffffb8bc6f4c)
eax=00000000 ebx=89737350 ecx=00000000 edx=89737350 esi=89737528 edi=b8bc7458
eip=baf70fef esp=b8bc7318 ebp=b8bc7318 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
Ntfs!NtfsDecodeFileObject+0x8:
baf70fef 8b410c mov eax,dword ptr [ecx+0Ch] ds:0023:0000000c=???
Resetting default scope

PROCESS_NAME: NSS Quota Serve

CURRENT_IRQL: 0

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1: 00000000

EXCEPTION_PARAMETER2: 0000000c

READ_ADDRESS: 0000000c

FOLLOWUP_IP:
Ntfs!NtfsDecodeFileObject+8
baf70fef 8b410c mov eax,dword ptr [ecx+0Ch]

FAULTING_IP:
Ntfs!NtfsDecodeFileObject+8
baf70fef 8b410c mov eax,dword ptr [ecx+0Ch]

BUGCHECK_STR: 0x24

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER: from bafe1c81 to baf70fef

STACK_TEXT:
b8bc7318 bafe1c81 b8bc7458 00000000 b8bc737c Ntfs!NtfsDecodeFileObject+0x8
b8bc73e0 baf9acf5 b8bc7458 89737350 8c4c23c0 Ntfs!NtfsCommonQueryEa+0x40
b8bc7444 bafac02f b8bc7458 89737350 00000001 Ntfs!NtfsFsdDispatchSwitch+0xd2
b8bc7560 8081df85 8c29a718 89737350 89737350 Ntfs!NtfsFsdDispatchWait+0x1c
b8bc7574 f7966d28 89d33008 8cbe8890 00000000 nt!IofCallDriver+0x45
b8bc75a0 8081df85 8c4c23c0 89737350 89737350 fltmgr!FltpDispatch+0x152
b8bc75b4 f7966b25 00000000 89d33064 00000000 nt!IofCallDriver+0x45
b8bc75d8 f796766f b8bc75f8 8c27a020 00000000 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
b8bc7610 f7976b9d 8ad6bb80 dcc204b6 b7bf662d fltmgr!FltPerformSynchronousIo+0xb9
b8bc7628 b7bf1296 8ad6bb80 89d33064 dec2e008 fltmgr!FltQueryEaFile+0x91
b8bc7674 b7bf1de6 8ad6bb80 00000000 e04cab20 DxSpy!DxGetMigrationData+0xe2
b8bc76cc b7bf2087 8ad6bb80 89fd3b10 dcd47258 DxSpy!DxGetMigrationInfoDir+0x1ba
b8bc773c f7969d70 8ad77f68 b8bc77d4 89fd3b10 DxSpy!DxPostDirCtrlSafe+0x26d
b8bc775c b7bf1b9c 8924e9dc b8bc77d4 89288750 fltmgr!FltDoCompletionProcessingWhenSafe+0x78
b8bc7794 b7bf2239 8924e9dc b8bc77d4 89fd3b10 DxSpy!DxDoPostOperationWhenSafe+0x6e
b8bc77b0 f7963b73 8924e9dc b8bc77d4 89288750 DxSpy!DxPostDirCtrl+0x1b
b8bc7818 f7965fc2 0024e980 89b03423 8924e980 fltmgr!FltpPerformPostCallbacks+0x1c5
b8bc782c f79664f1 8924e980 89b03248 b8bc786c fltmgr!FltpProcessIoCompletion+0x10
b8bc783c 8081e123 8c27a020 89b03248 8924e980 fltmgr!FltpPassThroughCompletion+0x89
b8bc786c baf711dc dbfba338 e016e6c0 b8bc7a90 nt!IopfCompleteRequest+0xcd
b8bc787c baface44 b8bc7ae0 89b03248 00000000 Ntfs!NtfsCompleteRequest+0xc8
b8bc788c bafad4cb 89b03248 89b03420 8a8598b0 Ntfs!NtfsQueryDirectory+0xcd5
b8bc7a90 bafacdaa b8bc7ae0 89b03248 8c29a7f8 Ntfs!NtfsQueryDirectory+0xbc3
b8bc7ac4 bafacd15 b8bc7ae0 db482d28 8c4c23c0 Ntfs!NtfsCommonDirectoryControl+0xbc
b8bc7c34 8081df85 8c29a718 89b03248 89b03248 Ntfs!NtfsFsdDirectoryControl+0xad
b8bc7c48 f7966d28 8924e980 8cbe8890 00000000 nt!IofCallDriver+0x45
b8bc7c74 8081df85 8c4c23c0 89b03248 89b03248 fltmgr!FltpDispatch+0x152
b8bc7c88 f7966b25 8c27a020 89b03248 8bf4c460 nt!IofCallDriver+0x45
b8bc7cac f7966cf5 b8bc7ccc 8c27a020 00000000 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
b8bc7ce4 8081df85 8c27a020 89b03248 0269d840 fltmgr!FltpDispatch+0x11f
b8bc7cf8 808f54f9 b8bc7d64 0269d840 808ef9c8 nt!IofCallDriver+0x45
b8bc7d0c 808efa25 8c27a020 89b03248 8a8598b0 nt!IopSynchronousServiceTail+0x10b
b8bc7d30 808897ec 00000ab0 00000000 00000000 nt!NtQueryDirectoryFile+0x5d
b8bc7d30 7c82847c 00000ab0 00000000 00000000 nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0269f08c 00000000 00000000 00000000 00000000 0x7c82847c

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: Ntfs!NtfsDecodeFileObject+8

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Ntfs

IMAGE_NAME: Ntfs.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 45d6a04b

STACK_COMMAND: .cxr 0xffffffffb8bc6f4c ; kb

FAILURE_BUCKET_ID: 0x24_Ntfs!NtfsDecodeFileObject+8

BUCKET_ID: 0x24_Ntfs!NtfsDecodeFileObject+8

Followup: MachineOwner
---------

5: kd> ub Ntfs!NtfsDecodeFileObject+0x8
Ntfs!NtfsInitializeIrpContext+0x106:
baf70fe3 90 nop
baf70fe4 90 nop
baf70fe5 90 nop
baf70fe6 90 nop
Ntfs!NtfsDecodeFileObject:
baf70fe7 8bff mov edi,edi
baf70fe9 55 push ebp
baf70fea 8bec mov ebp,esp
baf70fec 8b4d0c mov ecx,dword ptr [ebp+0Ch]
5: kd> u Ntfs!NtfsDecodeFileObject+0x8
Ntfs!NtfsDecodeFileObject+0x8:
baf70fef 8b410c mov eax,dword ptr [ecx+0Ch]
baf70ff2 8b5518 mov edx,dword ptr [ebp+18h]
baf70ff5 53 push ebx
baf70ff6 33db xor ebx,ebx
baf70ff8 3bc3 cmp eax,ebx
baf70ffa 8902 mov dword ptr [edx],eax
baf70ffc 0f846a130000 je Ntfs!NtfsDecodeFileObject+0x74 (baf7236c)
baf71002 385d20 cmp byte ptr [ebp+20h],bl

From the above code snippet, it is clear that BSOD occured while trying to access offset into FileObject.

This FileObject is passed by us. As Highlighted above in stack trace, the FileObject is NULL. Here is the code snippet which creates this FileObject

NTSTATUS DxGetMigrationInfoDir()
{
.
.
.
.
status = FltCreateFileEx(DxFltData.Filter, Instance, &hFile,
&pFO, FILE_READ_EA, &ObjectAttributes, &IoStatus,
NULL, FILE_ATTRIBUTE_NORMAL, ShareAccess, FILE_OPEN, CreateOptions,
NULL, 0, IO_IGNORE_SHARE_ACCESS_CHECK);

if ( !NT_SUCCESS(status) )
{
DbgPrint(“dxmfd!DxGetMigrationInfoDir: FltCreateFileEx failed!, status: 0x%08X, file: %ws\n”, status, pFileName);
LOGERROR(EVTLOG_ERROR_MESSAGE, status, L"FltCreateFileEx failed");
goto ROUTINE_EXIT;
}

// Get migration information
status = DxGetMigrationData(Instance, pFO, MigrateInfo);
.
.
.

}

So FltCreateFileEx returned SUCCESS but fileobject is NULL. Documentation does not indicate this possibility. Is It possible? Is it necessary that we check for NULL FileObject also in addition to NT_SUCCESS(status).

Thanks
Ash

Hi Rod,
Thanks for replying. I was trying to get answers to your question.

Here is the output from current IRP.

6: kd> !irp 8ac1dcd0

Irp is active with 12 stacks 11 is current (= 0x8ac1dea8)

No Mdl: No System Buffer: Thread 8b75cdb0: Irp stack trace.

cmd flg cl Device File Completion-Context

[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[7, 0] 3 e0 8c5d1308 00000000 f7965f8e-89e852f0 Success Error Cancel

\FileSystem\Ntfs fltmgr!FltpSynchronizedOperationCompletion

Args: 00000508 d73a06b8 00000010 00000000

[7, 0] 3 0 8d1eb250 00000000
00000000-00000000?---------------------------------File
object is absent

\FileSystem\FltMgr
Args: 00000508 d73a06b8 00000010 00000000

I was not able to get status of FltCreateFileEx call as the code was
optimized and return value was stored in register instead of Stack variable.

Since everywhere FileObject is NULL so I am not sure if another misbehaving
thread can set it to NULL at so many places.

The customer is using some Quota management software and I am trying to find
if they reparse the filenames.

Question - If the return status is STATUS_REPARSE then how to get
FileObject? What are the recommended steps to handle STATUS_REPARSE from
FltCreateFileEx?

Thanks
Ashish

On Sun, Feb 20, 2011 at 1:20 AM, Rod Widdowson wrote:

> STATUS_REPARSE? What?s in the Iosb? And the Handle?
>
> Is this reproducible? No other threads misbehaving?
>
>
> “Ashish Goyal” wrote in message
> news:xxxxx@ntfsd…
> Hi,
> I have a situation where I got NULL FIleObject from FltCreateFileEx() and
> status is SUCCESS. Due to this, I got a blue screen. Here is the output of
> !analyze -v
>
> NTFS_FILE_SYSTEM (24)
> If you see NtfsExceptionFilter on the stack then the 2nd and 3rd
> parameters are the exception record and context record. Do a .cxr
> on the 3rd parameter and then kb to obtain a more informative stack
> trace.
> Arguments:
> Arg1: 0019033d
> Arg2: b8bc7250
> Arg3: b8bc6f4c
> Arg4: baf70fef
>
> Debugging Details:
> ------------------
>
> PEB is paged out (Peb.Ldr = 7ffdf00c). Type “.hh dbgerr001” for details
> PEB is paged out (Peb.Ldr = 7ffdf00c). Type “.hh dbgerr001” for details
>
> EXCEPTION_RECORD: b8bc7250 – (.exr 0xffffffffb8bc7250)
> ExceptionAddress: baf70fef (Ntfs!NtfsDecodeFileObject+0x00000008)
> ExceptionCode: c0000005 (Access violation)
> ExceptionFlags: 00000000
> NumberParameters: 2
> Parameter[0]: 00000000
> Parameter[1]: 0000000c
> Attempt to read from address 0000000c
>
> CONTEXT: b8bc6f4c – (.cxr 0xffffffffb8bc6f4c)
> eax=00000000 ebx=89737350 ecx=00000000 edx=89737350 esi=89737528
> edi=b8bc7458
> eip=baf70fef esp=b8bc7318 ebp=b8bc7318 iopl=0 nv up ei pl zr na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010246
> Ntfs!NtfsDecodeFileObject+0x8:
> baf70fef 8b410c mov eax,dword ptr [ecx+0Ch]
> ds:0023:0000000c=???
> Resetting default scope
>
> PROCESS_NAME: NSS Quota Serve
>
> CURRENT_IRQL: 0
>
> ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced
> memory at 0x%08lx. The memory could not be %s.
>
> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
> referenced memory at 0x%08lx. The memory could not be %s.
>
> EXCEPTION_PARAMETER1: 00000000
>
> EXCEPTION_PARAMETER2: 0000000c
>
> READ_ADDRESS: 0000000c
>
> FOLLOWUP_IP:
> Ntfs!NtfsDecodeFileObject+8
> baf70fef 8b410c mov eax,dword ptr [ecx+0Ch]
>
> FAULTING_IP:
> Ntfs!NtfsDecodeFileObject+8
> baf70fef 8b410c mov eax,dword ptr [ecx+0Ch]
>
> BUGCHECK_STR: 0x24
>
> DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE
>
> LAST_CONTROL_TRANSFER: from bafe1c81 to baf70fef
>
> STACK_TEXT:
> b8bc7318 bafe1c81 b8bc7458 00000000 b8bc737c Ntfs!NtfsDecodeFileObject+0x8
> b8bc73e0 baf9acf5 b8bc7458 89737350 8c4c23c0 Ntfs!NtfsCommonQueryEa+0x40
> b8bc7444 bafac02f b8bc7458 89737350 00000001
> Ntfs!NtfsFsdDispatchSwitch+0xd2
> b8bc7560 8081df85 8c29a718 89737350 89737350 Ntfs!NtfsFsdDispatchWait+0x1c
> b8bc7574 f7966d28 89d33008 8cbe8890 00000000 nt!IofCallDriver+0x45
> b8bc75a0 8081df85 8c4c23c0 89737350 89737350 fltmgr!FltpDispatch+0x152
> b8bc75b4 f7966b25 00000000 89d33064 00000000 nt!IofCallDriver+0x45
> b8bc75d8 f796766f b8bc75f8 8c27a020 00000000
> fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
> b8bc7610 f7976b9d 8ad6bb80 dcc204b6 b7bf662d
> fltmgr!FltPerformSynchronousIo+0xb9
> b8bc7628 b7bf1296 8ad6bb80 89d33064 dec2e008 fltmgr!FltQueryEaFile+0x91
> b8bc7674 b7bf1de6 8ad6bb80 00000000 e04cab20 DxSpy!DxGetMigrationData+0xe2
>
> b8bc76cc b7bf2087 8ad6bb80 89fd3b10 dcd47258
> DxSpy!DxGetMigrationInfoDir+0x1ba
> b8bc773c f7969d70 8ad77f68 b8bc77d4 89fd3b10 DxSpy!DxPostDirCtrlSafe+0x26d
> b8bc775c b7bf1b9c 8924e9dc b8bc77d4 89288750
> fltmgr!FltDoCompletionProcessingWhenSafe+0x78
> b8bc7794 b7bf2239 8924e9dc b8bc77d4 89fd3b10
> DxSpy!DxDoPostOperationWhenSafe+0x6e
> b8bc77b0 f7963b73 8924e9dc b8bc77d4 89288750 DxSpy!DxPostDirCtrl+0x1b
> b8bc7818 f7965fc2 0024e980 89b03423 8924e980
> fltmgr!FltpPerformPostCallbacks+0x1c5
> b8bc782c f79664f1 8924e980 89b03248 b8bc786c
> fltmgr!FltpProcessIoCompletion+0x10
> b8bc783c 8081e123 8c27a020 89b03248 8924e980
> fltmgr!FltpPassThroughCompletion+0x89
> b8bc786c baf711dc dbfba338 e016e6c0 b8bc7a90 nt!IopfCompleteRequest+0xcd
> b8bc787c baface44 b8bc7ae0 89b03248 00000000 Ntfs!NtfsCompleteRequest+0xc8
> b8bc788c bafad4cb 89b03248 89b03420 8a8598b0 Ntfs!NtfsQueryDirectory+0xcd5
> b8bc7a90 bafacdaa b8bc7ae0 89b03248 8c29a7f8 Ntfs!NtfsQueryDirectory+0xbc3
> b8bc7ac4 bafacd15 b8bc7ae0 db482d28 8c4c23c0
> Ntfs!NtfsCommonDirectoryControl+0xbc
> b8bc7c34 8081df85 8c29a718 89b03248 89b03248
> Ntfs!NtfsFsdDirectoryControl+0xad
> b8bc7c48 f7966d28 8924e980 8cbe8890 00000000 nt!IofCallDriver+0x45
> b8bc7c74 8081df85 8c4c23c0 89b03248 89b03248 fltmgr!FltpDispatch+0x152
> b8bc7c88 f7966b25 8c27a020 89b03248 8bf4c460 nt!IofCallDriver+0x45
> b8bc7cac f7966cf5 b8bc7ccc 8c27a020 00000000
> fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
> b8bc7ce4 8081df85 8c27a020 89b03248 0269d840 fltmgr!FltpDispatch+0x11f
> b8bc7cf8 808f54f9 b8bc7d64 0269d840 808ef9c8 nt!IofCallDriver+0x45
> b8bc7d0c 808efa25 8c27a020 89b03248 8a8598b0
> nt!IopSynchronousServiceTail+0x10b
> b8bc7d30 808897ec 00000ab0 00000000 00000000 nt!NtQueryDirectoryFile+0x5d
> b8bc7d30 7c82847c 00000ab0 00000000 00000000 nt!KiFastCallEntry+0xfc
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 0269f08c 00000000 00000000 00000000 00000000 0x7c82847c
>
>
> SYMBOL_STACK_INDEX: 0
>
> SYMBOL_NAME: Ntfs!NtfsDecodeFileObject+8
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: Ntfs
>
> IMAGE_NAME: Ntfs.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 45d6a04b
>
> STACK_COMMAND: .cxr 0xffffffffb8bc6f4c ; kb
>
> FAILURE_BUCKET_ID: 0x24_Ntfs!NtfsDecodeFileObject+8
>
> BUCKET_ID: 0x24_Ntfs!NtfsDecodeFileObject+8
>
> Followup: MachineOwner
> ---------
>
> 5: kd> ub Ntfs!NtfsDecodeFileObject+0x8
> Ntfs!NtfsInitializeIrpContext+0x106:
> baf70fe3 90 nop
> baf70fe4 90 nop
> baf70fe5 90 nop
> baf70fe6 90 nop
> Ntfs!NtfsDecodeFileObject:
> baf70fe7 8bff mov edi,edi
> baf70fe9 55 push ebp
> baf70fea 8bec mov ebp,esp
> baf70fec 8b4d0c mov ecx,dword ptr [ebp+0Ch]
> 5: kd> u Ntfs!NtfsDecodeFileObject+0x8
> Ntfs!NtfsDecodeFileObject+0x8:
> baf70fef 8b410c mov eax,dword ptr [ecx+0Ch]
> baf70ff2 8b5518 mov edx,dword ptr [ebp+18h]
> baf70ff5 53 push ebx
> baf70ff6 33db xor ebx,ebx
> baf70ff8 3bc3 cmp eax,ebx
> baf70ffa 8902 mov dword ptr [edx],eax
> baf70ffc 0f846a130000 je Ntfs!NtfsDecodeFileObject+0x74 (baf7236c)
> baf71002 385d20 cmp byte ptr [ebp+20h],bl
>
> From the above code snippet, it is clear that BSOD occured while trying to
> access offset into FileObject.
>
> This FileObject is passed by us. As Highlighted above in stack trace, the
> FileObject is NULL. Here is the code snippet which creates this FileObject
>
> NTSTATUS DxGetMigrationInfoDir()
> {
> .
> .
> .
> .
> status = FltCreateFileEx(DxFltData.Filter, Instance, &hFile,
> &pFO, FILE_READ_EA, &ObjectAttributes,
> &IoStatus,
> NULL, FILE_ATTRIBUTE_NORMAL, ShareAccess,
> FILE_OPEN, CreateOptions,
> NULL, 0, IO_IGNORE_SHARE_ACCESS_CHECK);
>
> if ( !NT_SUCCESS(status) )
> {
> DbgPrint(“dxmfd!DxGetMigrationInfoDir: FltCreateFileEx failed!,
> status: 0x%08X, file: %ws\n”, status, pFileName);
> LOGERROR(EVTLOG_ERROR_MESSAGE, status, L"FltCreateFileEx failed");
> goto ROUTINE_EXIT;
> }
>
> // Get migration information
> status = DxGetMigrationData(Instance, pFO, MigrateInfo);
> .
> .
> .
>
> }
>
> So FltCreateFileEx returned SUCCESS but fileobject is NULL. Documentation
> does not indicate this possibility. Is It possible? Is it necessary that we
> check for NULL FileObject also in addition to NT_SUCCESS(status).
>
> Thanks
> Ash
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Handling STATUS_REPARSE after you perform a FltCreateFile operation can be a bit painful - it’s also not the only place where you can run into this problem.

First, you get back the error STATUS_MOUNT_POINT_NOT_RESOLVED. When that happens, what you have to do is find out where the reparse point occurs - and the only way to do this is systematically walk the path from root to leaf until you get that error back. When you DO get that error back, you will need to open that as a reparse point and then query for the reparse point data (FltFsControlFile using FSCTL_GET_REPARSE_POINT) and then you have the data you need to format your response - copy the reparse buffer contents into the auxiliary buffer and make sure to set the “Reserved” field to point to the size of the name parsed up to the point of the reparse point.

I don’t have a pure filter sample of this code, but I know we’ve had to do this for both create and hard link cases. It’s around 170 lines of code in our encryption toolkit (including comments and white space.)

This is a nice example of how something that’s trivial in a legacy filter (since you get the auxiliary buffer back in that case) is quite a bit more work in a mini-filter.

Tony
OSR

Thanks Toni…I will follow your advice and see what I get back…

On Fri, Feb 25, 2011 at 1:22 AM, Tony Mason wrote:

> Handling STATUS_REPARSE after you perform a FltCreateFile operation can be
> a bit painful ? it?s also not the only place where you can run into this
> problem.
>
>
>
> First, you get back the error STATUS_MOUNT_POINT_NOT_RESOLVED. When that
> happens, what you have to do is find out where the reparse point occurs ?
> and the only way to do this is systematically walk the path from root to
> leaf until you get that error back. When you DO get that error back, you
> will need to open that as a reparse point and then query for the reparse
> point data (FltFsControlFile using FSCTL_GET_REPARSE_POINT) and then you
> have the data you need to format your response ? copy the reparse buffer
> contents into the auxiliary buffer and make sure to set the ?Reserved? field
> to point to the size of the name parsed up to the point of the reparse
> point.
>
>
>
> I don?t have a pure filter sample of this code, but I know we?ve had to do
> this for both create and hard link cases. It?s around 170 lines of code in
> our encryption toolkit (including comments and white space.)
>
>
>
> This is a nice example of how something that?s trivial in a legacy filter
> (since you get the auxiliary buffer back in that case) is quite a bit more
> work in a mini-filter.
>
>
>
> Tony
>
> OSR
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>