Correct behavior for a XP 64 bit BSOD soln

NTFSD
1

We are having following call stack when we extend a doc file in Ms Word 2003. i.e. write several lines of data & save. This is a cached write call & later our filter received a read IRP (which is paging, nested, & requester mode is KernelMode).

: Args to Child : Call Site
: fffffadfcdcd7ed8 fffffadfc646de18 fffffadfcde16710 fffffadf00000000 : MyFilter!ScannerPostRead+0x3b7
: fffffadfcdcd7e30 0000000000000000 0000000000000000 fffffadfcdcd7e30 : fltmgr!FltpPerformPostCallbacks+0x286
: 0000000000000000 0000000000000000 fffffadfcdd2a600 fffffadfcdd2a660 : fltmgr!FltpPassThroughCompletion+0xe7
: fffff6fc00000000 fffffadfcdd2a660 fffffadfce9b5000 fffffadfcdd2a660 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x473
: fffffadfce9c6040 fffffadfce9b5010 fffffadfce9c6040 fffffadfce4d3af0 : fltmgr!FltpDispatch+0x17f
: 0000000000000000 0000000000000000 fffff6fcc01c6c10 0000000000000000 : nt!IoPageRead+0x224
: fffffadf00000000 fffff98038d82000 fffff6fcc01c6c10 fffffa80022c7020 : nt!MiDispatchFault+0x17f6
: 0000000000000001 00000000ffffffff 0000000000000000 0000000000000000 : nt!MmAccessFault+0xbb3
: fffff98038d82000 0000000000000000 fffff98038d82000 fffffadfc646e8c0 : nt!MmCheckCachedPageState+0x76a
: fffffadfc646e438 fffffadfc646e8c0 0000000000000002 0000000000000000 : nt!CcMapAndRead+0xba
: fffffadf00000000 fffffadfc646e438 fffffadf00000400 fffffadfcdc53d01 : nt!CcPinFileData+0x388
: fffffadfce4d3af0 fffffadfcdf31010 0000000000000200 000000000000122e : nt!CcZeroData+0x14e
: fffffadfcdc9e120 fffffa8002527cb0 fffffadfce4d3af0 fffffadfcdc9e101 : Ntfs!NtfsZeroData+0x340
: fffffadfcdc9e120 fffffadfcdf31010 fffffadfcdc9e120 fffffadfcdf31010 : Ntfs!NtfsCommonWrite+0x27da
: fffffadfcdf31010 fffffadfcdf31010 fffffadfcdf31010 fffffadfce9c6040 : Ntfs!NtfsFsdWrite+0x2e4
: fffffadfcdf31010 fffffadfc646eaa0 fffffadfcdf31010 fffffadfce6386a0 : fltmgr!FltpDispatch+0x1c2
: fffffadfce4d3af0 fffffadfcdf31010 fffffadfce9c6040 fffffadfcdfced10 : sr!SrWrite+0xef
: 0000000000000000 fffffadfcdf31010 fffffadfcdf31000 fffffadfcdf31010 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x3f2
: 0000000000000000 fffffadfc646ecf0 fffffadfce9c6040 fffffadfce4d3af0 : fltmgr!FltpDispatch+0x17f
: 0000000000000394 0000000000000000 0000000000000000 0000000000000000 : nt!NtWriteFile+0x993

From FastFat sample I observed that FatCommonWrite routine call FatZeroData if “write is beyond valid data length”. Which should be true in this case. Now later a call to CCZeroData results in AccessFault & a paging read is issued which is intercepted by our filter. If my PostRead handler flow fails for some reason & it tries to set Information as zero this call results in a BSOD later with code NTFS_FILE_SYSTEM (24).

following is the bugcheck occured

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

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: 000000000019033d
Arg2: fffffadfc646dd50
Arg3: fffffadfc646d760
Arg4: fffff8000109b3bb

Debugging Details:

EXCEPTION_RECORD: fffffadfc646dd50 – (.exr 0xfffffadfc646dd50)
ExceptionAddress: fffff8000109b3bb (nt!MiWaitForInPageComplete+0x0000000000000529)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: ffffffffffffffff
Attempt to read from address ffffffffffffffff

CONTEXT: fffffadfc646d760 – (.cxr 0xfffffadfc646d760)
rax=fffffadfce052bf0 rbx=fffffadfcab0a980 rcx=0000000000000000
rdx=0000000000000000 rsi=007ffadfce9b50a0 rdi=fffffadfce9b5070
rip=fffff8000109b3bb rsp=fffffadfc646df70 rbp=0000007ffffffff8
r8=0000fadfcedd1730 r9=fffffadfcedd2ab0 r10=0000000000000000
r11=0000fadfcedd1730 r12=fffff68000000000 r13=fffffadfce9b50a0
r14=fffff98038d82000 r15=0000000000000000
iopl=0 nv up ei pl nz na po cy
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010207
nt!MiWaitForInPageComplete+0x529:
fffff8000109b3bb 488b16 mov rdx,qword ptr [rsi] ds:002b:007ffadfce9b50a0=???
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: WINWORD.EXE

CURRENT_IRQL: 2

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

READ_ADDRESS: ffffffffffffffff

BUGCHECK_STR: 0x24

LAST_CONTROL_TRANSFER: from fffff80001017091 to fffff8000109b3bb

STACK_TEXT:
0000000000000000 fffffa80022c7020 fffff6fcc01c6c10 fffffadfc646e0a8 : nt!MiWaitForInPageComplete+0x529
fffffadf00000000 fffff98038d82000 fffff6fcc01c6c10 fffffa80022c7020 : nt!MiDispatchFault+0x1845
0000000000000001 00000000ffffffff 0000000000000000 0000000000000000 : nt!MmAccessFault+0xbb3
fffff98038d82000 0000000000000000 fffff98038d82000 fffffadfc646e8c0 : nt!MmCheckCachedPageState+0x76a
fffffadfc646e438 fffffadfc646e8c0 0000000000000002 0000000000000000 : nt!CcMapAndRead+0xba
fffffadf00000000 fffffadfc646e438 fffffadf00000400 fffffadfcdc53d01 : nt!CcPinFileData+0x388
fffffadfce4d3af0 fffffadfcdf31010 0000000000000200 000000000000122e : nt!CcZeroData+0x14e
fffffadfcdc9e120 fffffa8002527cb0 fffffadfce4d3af0 fffffadfcdc9e101 : Ntfs!NtfsZeroData+0x340
fffffadfcdc9e120 fffffadfcdf31010 fffffadfcdc9e120 fffffadfcdf31010 : Ntfs!NtfsCommonWrite+0x27da
fffffadfcdf31010 fffffadfcdf31010 fffffadfcdf31010 fffffadfce9c6040 : Ntfs!NtfsFsdWrite+0x2e4
fffffadfcdf31010 fffffadfc646eaa0 fffffadfcdf31010 fffffadfce6386a0 : fltmgr!FltpDispatch+0x1c2
fffffadfce4d3af0 fffffadfcdf31010 fffffadfce9c6040 fffffadfcdfced10 : sr!SrWrite+0xef
0000000000000000 fffffadfcdf31010 fffffadfcdf31000 fffffadfcdf31010 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x3f2
0000000000000000 fffffadfc646ecf0 fffffadfce9c6040 fffffadfce4d3af0 : fltmgr!FltpDispatch+0x17f
0000000000000394 0000000000000000 0000000000000000 0000000000000000 : nt!NtWriteFile+0x993
0000000077ef317f 0000000000000000 0000000000000000 000000006b07096e : nt!KiSystemServiceCopyEnd+0x3
0000000000000003 0000000000000000 0000000000000000 0000000003bdf7d0 : wow64cpu!ReadWriteFileFault+0x35
0000000003bdfd00 0000000003bdf1d0 0000000003bdf7d0 0000000000000000 : wow64!RunCpuSimulation+0xa
0000000000000000 0000000000000000 0000000000000000 000000007efdf000 : wow64!Wow64LdrpInitialize+0x2ed
0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!LdrpInitialize+0x2aa
0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!KiUserApcDispatcher+0x15
0000000000000000 0000000000000000 0000000000000000 0000000000000000 : kernel32!BaseThreadStartThunk

FOLLOWUP_IP:
Ntfs!NtfsZeroData+340
fffffadf`c850b450 84c0 test al,al

SYMBOL_STACK_INDEX: 7

SYMBOL_NAME: Ntfs!NtfsZeroData+340

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Ntfs

IMAGE_NAME: Ntfs.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 45d699ef

STACK_COMMAND: .cxr 0xfffffadfc646d760 ; kb

FAILURE_BUCKET_ID: X64_0x24_Ntfs!NtfsZeroData+340

BUCKET_ID: X64_0x24_Ntfs!NtfsZeroData+340

I have tried setting original value of information which I received in PostRead handler(obviously on the basis of some condition) & crash DISAPPEARS.

Though crash is not coming now but I am curious for the exact reason. Surprisingly we are not facing same thing in 32 bit Xp, Vista & 64 bit Vista.

Can somebody explain the role of Information field in this case & what should be the correct behavior that read handler should follow.

Regards,
Aditya

2

Well I think my previous post is so long to get any attention :-).

In Short after an Page AccessFault; my filter receives a read IRP (paging,nested) & if it set IoStatus.Information field value to zero, call results in BSODs. If I set IoStatus.information with its original value than every thing goes well. This is specific to 64bit XP.

What is the exact cause of BSOD when I set zero in Information.

Can anyone suggest what is the correct way to handle this(if setting orig value is not good)?

Thanks,
Aditya