Hi,
I've a minifilter driver that's calling FltQueryInformationFile (FILE_INFORMATION_CLASS being FileBasicInformation) from PreCleanup.
It succeeds on most of the occasions (i.e. we have not been able to reproduce it in-house so far) however it looks like in the field there are no. of occasions
when systems (all client WinOS, win10 upwards) are crashing with SYSTEM_SERVICE_EXCEPTION bug check and our driver is found in the call stack making call to
FltQueryInformationFile(). Since the dumps are being reported under the MS analytics program, I only have dumps to work with and do not know exact steps
/ actions that lead to the crash. The instance of the filter is attached to an NTFS volume.
From the crash dump, it looks like a completely invalid address is being accessed.
However, it is unclear to me why that is the case - I'm passing all the valid pointers i.e. instance, file object (what I received in callback data) and also
a valid pointer to buffer that shall receive the information.
It's also worth noting that call stack is not always consistent - they differ but there are always couple of function frames corresponding to our driver that
call FltQueryInformationFile.
I don't think there is anything wrong with the call itself. Just thinking, are there any special circumstances under which this API should not be called?
Here's pasting important bits from !analyze -v:
9: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the BugCheck
Arg2: fffff8028070b73f, Address of the instruction which caused the BugCheck
Arg3: ffff860375e43480, Address of the context record for the exception that caused the BugCheck
Arg4: 0000000000000000, zero.
Debugging Details:
------------------
BUGCHECK_CODE: 3b
BUGCHECK_P1: c0000005
BUGCHECK_P2: fffff8028070b73f
BUGCHECK_P3: ffff860375e43480
BUGCHECK_P4: 0
FILE_IN_CAB: MEMORY.DMP
TAG_NOT_DEFINED_202b: *** Unknown TAG in analysis list 202b
DUMP_FILE_ATTRIBUTES: 0x1800
CONTEXT: ffff860375e43480 -- (.cxr 0xffff860375e43480)
rax=0000000000000000 rbx=ffff860375e44160 rcx=00007802805e0000
rdx=ffffb08f832b73c0 rsi=ffffc5875c978920 rdi=ffffc5875d426890
rip=fffff8028070b73f rsp=ffff860375e43ea0 rbp=ffffb08f80de61d0
r8=ffffb08f5cdbc1b0 r9=0000000000000001 r10=ffffc58758a4b5a0
r11=ffff860375e43e70 r12=0000000000000000 r13=ffffb08f7ea44ae0
r14=ffffb08f80de61d0 r15=0000000000000000
iopl=0 nv up ei ng nz ac po cy
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00050297
Ntfs!NtfsCommonQueryInformation+0x8bf:
fffff802`8070b73f 8b948118c80700 mov edx,dword ptr [rcx+rax*4+7C818h] ds:002b:00007802`8065c818=????????
Resetting default scope
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXPNP: 1 (!blackboxpnp)
BLACKBOXWINLOGON: 1
PROCESS_NAME: Dropbox.exe
STACK_TEXT:
Ntfs!NtfsCommonQueryInformation+0x8bf
Ntfs!NtfsFsdDispatchSwitch+0x156
Ntfs!NtfsFsdDispatchWait+0x40
nt!IofCallDriver+0x55
FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x15b
FLTMGR!FltPerformSynchronousIo+0x2d8
FLTMGR!FltQueryInformationFile+0x6c
mydriver!mydriver::My_QueryInformationFile+0xf1
mydriver!`anonymous namespace'::FileCleanupPre+0xae
FLTMGR!FltpPerformPreCallbacksWorker+0x37a
FLTMGR!FltpPassThroughInternal+0xd1
FLTMGR!FltpPassThrough+0x179
FLTMGR!FltpDispatch+0x8b
nt!IofCallDriver+0x55
nt!IopCloseFile+0x18f
nt!ObpCloseHandle+0x313
nt!NtClose+0x39
nt!KiSystemServiceCopyEnd+0x28
0x00007fff`8762fb34
).