Doug_N
January 11, 2023, 6:40pm
1
According to my understanding of the docs, this should not happen. Since it is happening…
Code in a PostOp callback:
KIRQL irqLevel = KeGetCurrentIrql();
NTSTATUS status = 0;
PFLT_FILE_NAME_INFORMATION pFileNameInformation = NULL;
if ( (FlagOn(Data->Iopb->OperationFlags, SL_OPEN_PAGING_FILE)) ||
(FlagOn(Flags, FLTFL_POST_OPERATION_DRAINING)) )
return FLT_POSTOP_FINISHED_PROCESSING;
if (PASSIVE_LEVEL == irqLevel)
{
status = FltGetFileNameInformation(Data, FLT_FILE_NAME_OPENED | FLT_FILE_NAME_QUERY_DEFAULT, &pFileNameInformation);
The above line causes a crash with the following stack:
nt!DbgBreakPointWithStatus
nt!KiBugCheckDebugBreak+0x12
nt!KeBugCheck2+0x957
nt!KeBugCheckEx+0x107
nt!KiBugCheckDispatch+0x69
nt!KiSystemServiceHandler+0x7c
nt!RtlpExecuteHandlerForException+0xf
nt!RtlDispatchException+0x430
nt!KiDispatchException+0x144
nt!KiExceptionDispatch+0xc2
nt!KiPageFault +0x428
FLTMGR!FltGetFileNameInformation+0x7b
FLTMGR!FltvGetFileNameInformation+0x51
(code shown above in a PostOp function)
FLTMGR!FltpPerformPostMountCallbacks+0x90
FLTMGR!FltpFsControlMountVolume+0x2a5
FLTMGR!FltpFsControl+0x12c
nt!IopfCallDriver+0x56
This is on a fully patched Windows Server 2019. Are there additional cases to check for with FltGetFileNameInformation?
Thanks for any light you can share on this.
Doug
What’s the bugcheck and IRP path?
This is not a simple PostOp, but a mount callback. Possibly aftet a
format/lock combo.
The call should not bugcheck, though, IMO, but return an error. I never
tested/tried that path though.
Dejan.
Doug_N
January 11, 2023, 8:44pm
3
Assuming I can trust what I see in WinDbg (I’m pretty sure this is a checked build), Iopb->MajorFunction is 0xED which I don’t recognize. And FltObjects->FileObject is NULL. Maybe FltGetFileNameInformation doesn’t handle the NULL FileObject? That might be the case from this output
FLTMGR!FltGetFileNameInformation+7b
fffff802`d339553b 48395f18 cmp qword ptr [rdi+18h],rbx
CONTEXT: ffff808485a95070 -- (.cxr 0xffff808485a95070)
rax=0000000000000103 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000102 rsi=0000000000000000 rdi=0000000000000000 #### looks to be null
SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff802d339553b, Address of the instruction which caused the bugcheck
Arg3: ffff808485a95070, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.
Mind sending the complete !analyze -v output?
Looks more like a corruption to me, if MajorFunc is invalid.
I am not sure if FGFNI handles NULL FO, but IMO it should at least not
bugcheck
Dejan.
Doug_N
January 12, 2023, 6:26pm
5
Sure, not a problem. Checking for NULL prevents the crash (not surprising I guess). Here is the full output with some more stack shown at the bottom. Drive name changed to protect the guilty
1: kd> !analyze -v
Connected to Windows 10 17763 x64 target at (Thu Jan 12 12:15:26.008 2023 (UTC - 6:00)), ptr64 TRUE
Loading Kernel Symbols
...............................................................
................................................................
..............................
Loading User Symbols
.....................................................
Loading unloaded module list
................................................
*******************************************************************************
* *
* 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: fffff80eb4cd553b, Address of the instruction which caused the bugcheck
Arg3: ffffc9053fb0d070, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.
Debugging Details:
------------------
KEY_VALUES_STRING: 1
PROCESSES_ANALYSIS: 1
SERVICE_ANALYSIS: 1
STACKHASH_ANALYSIS: 1
TIMELINE_ANALYSIS: 1
DUMP_CLASS: 1
DUMP_QUALIFIER: 0
BUILD_VERSION_STRING: 17763.1.amd64fre.rs5_release.180914-1434
DUMP_TYPE: 0
BUGCHECK_P1: c0000005
BUGCHECK_P2: fffff80eb4cd553b
BUGCHECK_P3: ffffc9053fb0d070
BUGCHECK_P4: 0
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.
FAULTING_IP:
FLTMGR!FltGetFileNameInformation+7b
fffff80e`b4cd553b 48395f18 cmp qword ptr [rdi+18h],rbx
CONTEXT: ffffc9053fb0d070 -- (.cxr 0xffffc9053fb0d070)
rax=0000000000000103 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000102 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80eb4cd553b rsp=ffffc9053fb0da60 rbp=00000000000000ed
r8=ffffc9053fb0db58 r9=ffffce0f2c999ba0 r10=ffffce0f2d10cea0
r11=ffffce0f2cf61550 r12=0000000000000102 r13=ffffc9053fb0db58
r14=ffffce0f2c999b48 r15=fffff80eb4cec4e3
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010246
FLTMGR!FltGetFileNameInformation+0x7b:
fffff80e`b4cd553b 48395f18 cmp qword ptr [rdi+18h],rbx ds:002b:00000000`00000018=????????????????
Resetting default scope
BUGCHECK_STR: 0x3B_c0000005
CPU_COUNT: 4
CPU_MHZ: d50
CPU_VENDOR: GenuineIntel
CPU_FAMILY: 6
CPU_MODEL: 5e
CPU_STEPPING: 3
CPU_MICROCODE: 6,5e,3,0 (F,M,S,R) SIG: FFFFFFFF'00000000 (cache) FFFFFFFF'00000000 (init)
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
PROCESS_NAME: svchost.exe
CURRENT_IRQL: 0
ANALYSIS_SESSION_HOST: D2
ANALYSIS_SESSION_TIME: 01-12-2023 12:15:29.0530
ANALYSIS_VERSION: 10.0.18362.1 amd64fre
LAST_CONTROL_TRANSFER: from fffff80eb4d2e451 to fffff80eb4cd553b
STACK_TEXT:
ffffc905`3fb0da60 fffff80e`b4d2e451 : ffffce0f`2b11f010 ffffce0f`2b11f010 ffffc905`3fb0e201 fffff804`00000001 : FLTMGR!FltGetFileNameInformation+0x7b
ffffc905`3fb0dae0 fffff804`80112851 : ffffce0f`2c999a60 00000000`00000000 fffff804`8011b093 ffffce0f`2c1c3860 : FLTMGR!FltvGetFileNameInformation+0x51
ffffc905`3fb0db10 fffff804`80116673 : ffffce0f`2c999b48 fffff804`8011b470 fffff804`80ef6fc0 ffffc905`3fb0e040 : MYDRIVER!LogToDbgPrintWithFileName+0x141
ffffc905`3fb0df90 fffff804`80116cc9 : ffffce0f`2c999b48 ffffc905`3fb0f0a0 00000000`00000000 ffffce0f`00000000 : MYDRIVER!RCPostOperationCallback+0x73
ffffc905`3fb0e030 fffff80e`b4d1292c : ffffce0f`2c999b48 ffffc905`3fb0f0a0 00000000`00000000 ffffce0f`00000000 : MYDRIVER!PostOperationCallback+0x1a9
ffffc905`3fb0f070 fffff80e`b4d124e9 : 00000000`c0000013 ffffce0f`2d0b7920 ffffce0f`2d2ec060 ffffce0f`29ed8010 : FLTMGR!FltpPerformPostMountCallbacks+0x90
ffffc905`3fb0f0e0 fffff80e`b4d0cb8c : ffffce0f`2a902c10 fffff804`c0000013 00000000`00000000 ffffce0f`2c8ca0a0 : FLTMGR!FltpFsControlMountVolume+0x2a5
ffffc905`3fb0f1d0 fffff804`80c2b63a : ffffce0f`2d0b7920 00000000`00000001 ffffce0f`2a902c10 ffffce0f`00000000 : FLTMGR!FltpFsControl+0x12c
ffffc905`3fb0f230 fffff804`813def49 : ffffce0f`2d0b7920 ffffce0f`2a902c10 fffff804`80eef8e0 fffff804`80ae39de : nt!IopfCallDriver+0x56
ffffc905`3fb0f270 fffff804`80c9f4c7 : ffffce0f`2a902c10 ffffc905`3fb0f3a1 fffff804`80eef8e0 ffffce0f`2cf629a0 : nt!IovCallDriver+0x275
ffffc905`3fb0f2b0 fffff804`810ea31d : ffffce0f`2a4248f0 ffffc905`3fb0f3a1 ffffce0f`2a185940 fffff804`80eef8e0 : nt!IofCallDriver+0x1b74f7
ffffc905`3fb0f2f0 fffff804`80ae1353 : 00000001`00000001 ffffce0f`2a8d6220 00000000`00000000 ffffad2a`b7b77597 : nt!IopMountVolume+0x31d
ffffc905`3fb0f400 fffff804`81086f3f : 00000000`00000085 00000000`00000000 ffffc905`3fb0f6d0 00000000`00000000 : nt!IopCheckVpbMounted+0x1b3
ffffc905`3fb0f460 fffff804`8108ff29 : ffffce0f`2a4248f0 ffffce0f`2a4248c0 ffffce0f`2d662520 ffffe587`08ec0e01 : nt!IopParseDevice+0x8ff
ffffc905`3fb0f5d0 fffff804`8108ea2f : ffffce0f`2d662500 ffffc905`3fb0f838 00000000`00000040 ffffce0f`26f134e0 : nt!ObpLookupObjectName+0x719
ffffc905`3fb0f7a0 fffff804`8106cafd : ffffc905`00000001 000000a5`aa3fe450 00000000`00000001 00000000`00004021 : nt!ObOpenObjectByNameEx+0x1df
ffffc905`3fb0f8e0 fffff804`8106c438 : 000000a5`aa3fe428 00000000`00100000 000000a5`aa3fe450 000000a5`aa3fe440 : nt!IopCreateFile+0x61d
ffffc905`3fb0f980 fffff804`80c86ff5 : 00000000`00000400 00000000`00000000 00000000`00000000 00000000`00000000 : nt!NtOpenFile+0x58
ffffc905`3fb0fa10 00007ffc`f59b0e54 : 00007ffc`f1b34536 00000232`05eb7c60 000000a5`aa3fee00 00000000`00000027 : nt!KiSystemServiceCopyEnd+0x25
000000a5`aa3fe3d8 00007ffc`f1b34536 : 00000232`05eb7c60 000000a5`aa3fee00 00000000`00000027 00007ffc`dfda2be6 : ntdll!NtOpenFile+0x14
000000a5`aa3fe3e0 00007ffc`dfdd1ef8 : 00000000`00000000 000000a5`aa3fee00 00000232`05eb7c60 000000a5`aa3fed38 : KERNELBASE!GetVolumeInformationW+0xd6
000000a5`aa3fe4a0 00007ffc`dfdd18d0 : 00000000`00000000 000000a5`aa3ff190 00000000`00000000 00000000`00000003 : sdprov!cmn::QueryVolumeInfoObject+0x1d0
000000a5`aa3fed00 00007ffc`dfdc9b8e : 00000232`04007dd0 00000232`040149e0 00000000`00000032 00007ffc`dfdd40f8 : sdprov!cmn::EnumVolumesAndQueryVolumeInfoObjects+0xcc
000000a5`aa3ff090 00007ffc`dfdca100 : 00000000`00000000 00000000`00000000 00000232`040149e0 00000000`00000000 : sdprov!sdp::SruVolumeProvider::QueryStats+0x6e
000000a5`aa3ff290 00007ffc`dfea13f5 : 00000232`040082c0 00000232`040082c0 00000232`040082c0 000000a5`aa3ff410 : sdprov!sdp::QueryStatsEx+0x90
000000a5`aa3ff380 00007ffc`dfea1100 : 00000232`00000000 00000000`00000000 00000232`03fc7b48 00000000`00000000 : srumsvc!SruStatsUpdateStores+0x245
000000a5`aa3ff470 00007ffc`dfea23ce : 00000232`04008428 00000232`05d474e0 00000232`03fe5390 000000a5`aa3ff6b8 : srumsvc!SruWorkItemQueryProvider+0x80
000000a5`aa3ff4c0 00007ffc`f597bb90 : 00000232`04012cf0 00000232`04012db8 00000232`05d474e0 00000000`00000000 : srumsvc!SruWorkQueueThreadPoolCallback+0xfe
000000a5`aa3ff500 00007ffc`f5926964 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000010 : ntdll!TppWorkpExecuteCallback+0x130
000000a5`aa3ff550 00007ffc`f3587ad4 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!TppWorkerThread+0x644
000000a5`aa3ff840 00007ffc`f596a371 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!BaseThreadInitThunk+0x14
000000a5`aa3ff870 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x21
THREAD_SHA1_HASH_MOD_FUNC: a5cc8f1136917a5e11f2181585704b591118414c
THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 0f3aac9e769ec3afe2079931775a6e5f1ac525fd
THREAD_SHA1_HASH_MOD: d2653f49bae8b1749f9f8658ab5e20566350e50d
FOLLOWUP_IP:
MYDRIVER!LogToDbgPrintWithFileName+141
fffff804`80112851 89442454 mov dword ptr [rsp+54h],eax
FAULT_INSTR_CODE: 54244489
FAULTING_SOURCE_LINE: mf.c
FAULTING_SOURCE_FILE: mf.c
FAULTING_SOURCE_LINE_NUMBER: 2043
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: MYDRIVER!LogToDbgPrintWithFileName+141
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: MYDRIVER
IMAGE_NAME: MYDRIVER.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 63c04de8
STACK_COMMAND: .cxr 0xffffc9053fb0d070 ; kb
BUCKET_ID_FUNC_OFFSET: 141
FAILURE_BUCKET_ID: 0x3B_c0000005_VRF_MYDRIVER!LogToDbgPrintWithFileName
BUCKET_ID: 0x3B_c0000005_VRF_MYDRIVER!LogToDbgPrintWithFileName
PRIMARY_PROBLEM_CLASS: 0x3B_c0000005_VRF_MYDRIVER!LogToDbgPrintWithFileName
TARGET_TIME: 2023-01-12T18:15:09.000Z
OSBUILD: 17763
OSSERVICEPACK: 0
SERVICEPACK_NUMBER: 0
OS_REVISION: 0
SUITE_MASK: 272
PRODUCT_TYPE: 3
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
OSEDITION: Windows 10 Server TerminalServer SingleUserTS
OS_LOCALE:
USER_LCID: 0
OSBUILD_TIMESTAMP: unknown_date
BUILDDATESTAMP_STR: 180914-1434
BUILDLAB_STR: rs5_release
BUILDOSVER_STR: 10.0.17763.1.amd64fre.rs5_release.180914-1434
ANALYSIS_SESSION_ELAPSED_TIME: d9c7
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:0x3b_c0000005_vrf_MYDRIVER!logtodbgprintwithfilename
FAILURE_ID_HASH: {0a4ecf97-c93c-8c12-e1ef-b60409191a06}
Followup: MachineOwner
---------
Doug_N
January 12, 2023, 6:29pm
6
Hmmm, for some reason the extra stack I’m trying to post isn’t showing up right. I guess I won’t mark it as code…
Child-SP RetAddr : Args to Child : Call Site
00 ffffc9053fb0bf78 fffff804
80d4b582 : 00000000c0000005 00000000
00000003 ffffc9053fb0c0e0 fffff804
80c19ab0 : nt!DbgBreakPointWithStatus
01 ffffc9053fb0bf80 fffff804
80d4ad07 : 0000000000000003 ffffc905
3fb0c0e0 fffff80480c8a3e0 00000000
0000003b : nt!KiBugCheckDebugBreak+0x12
02 ffffc9053fb0bfe0 fffff804
80c73fa7 : fffff804164ae8c3 fffff804
816198cf ffffc9053fb0fa80 fffff804
81623508 : nt!KeBugCheck2+0x957
03 ffffc9053fb0c700 fffff804
80c87829 : 000000000000003b 00000000
c0000005 fffff80eb4cd553b ffffc905
3fb0d070 : nt!KeBugCheckEx+0x107
04 ffffc9053fb0c740 fffff804
80c86a3c : ffffc9053fb0d828 ffffc905
3fb0d070 ffffc9053fb0d828 00000000
00000000 : nt!KiBugCheckDispatch+0x69
05 ffffc9053fb0c880 fffff804
80c7e1df : fffff80480f9c000 fffff804
80abb000 0005b02000a6d000 00000000
0010001f : nt!KiSystemServiceHandler+0x7c
06 ffffc9053fb0c8c0 fffff804
80b3a990 : ffffc9053fb0cf10 00000000
00000000 ffffc9053fb0ce30 fffff804
80e4a10c : nt!RtlpExecuteHandlerForException+0xf
07 ffffc9053fb0c8f0 fffff804
80b3cc94 : ffffc9053fb0d828 ffffc905
3fb0d570 ffffc9053fb0d828 00000000
00000000 : nt!RtlDispatchException+0x430
08 ffffc9053fb0d040 fffff804
80c87902 : 0000000000000000 ffffc905
3fb0d8d0 0000000000001000 00000000
00000018 : nt!KiDispatchException+0x144
09 ffffc9053fb0d6f0 fffff804
80c834e8 : ffffad2ab7b75187 fffff804
80bd5117 fffff80400000000 00000000
00000004 : nt!KiExceptionDispatch+0xc2
0a ffffc9053fb0d8d0 fffff80e
b4cd553b : 0000000000000000 fffff804
80a1faf6 ffffce0f2d10cea0 fffff80e
b4cd2c8b : nt!KiPageFault+0x428 (TrapFrame @ ffffc9053fb0d8d0) 0b ffffc905
3fb0da60 fffff80eb4d2e451 : ffffce0f
2b11f010 ffffce0f2b11f010 ffffc905
3fb0e201 fffff80400000001 : FLTMGR!FltGetFileNameInformation+0x7b 0c ffffc905
3fb0dae0 fffff80480112851 : ffffce0f
2c999a60 0000000000000000 fffff804
8011b093 ffffce0f2c1c3860 : FLTMGR!FltvGetFileNameInformation+0x51 0d ffffc905
3fb0db10 fffff80480116673 : ffffce0f
2c999b48 fffff8048011b470 fffff804
80ef6fc0 ffffc9053fb0e040 : MYDRIVER!LogToDbgPrintWithFileName(struct _FLT_CALLBACK_DATA * Data = 0xffffce0f
2c999b48, char * str = 0xfffff8048011b470 "PAFS: RCPost with ")+0x141 0e ffffc905
3fb0df90 fffff80480116cc9 : ffffce0f
2c999b48 ffffc9053fb0f0a0 00000000
00000000 ffffce0f00000000 : MYDRIVER!RCPostOperationCallback(struct _FLT_CALLBACK_DATA * Data = 0xffffce0f
2c999b48, struct _FLT_RELATED_OBJECTS * FltObjects = 0xffffc9053fb0f0a0, void * CompletionContext = 0x00000000
00000000, unsigned long Flags = 0)+0x73
0f ffffc9053fb0e030 fffff80e
b4d1292c : ffffce0f2c999b48 ffffc905
3fb0f0a0 0000000000000000 ffffce0f
00000000 : MYDRIVER!PostOperationCallback(struct _FLT_CALLBACK_DATA * Data = 0xffffce0f2c999b48, struct _FLT_RELATED_OBJECTS * FltObjects = 0xffffc905
3fb0f0a0, void * CompletionContext = 0x0000000000000000, unsigned long Flags = 0)+0x1a9 10 ffffc905
3fb0f070 fffff80eb4d124e9 : 00000000
c0000013 ffffce0f2d0b7920 ffffce0f
2d2ec060 ffffce0f29ed8010 : FLTMGR!FltpPerformPostMountCallbacks+0x90 11 ffffc905
3fb0f0e0 fffff80eb4d0cb8c : ffffce0f
2a902c10 fffff804c0000013 00000000
00000000 ffffce0f2c8ca0a0 : FLTMGR!FltpFsControlMountVolume+0x2a5 12 ffffc905
3fb0f1d0 fffff80480c2b63a : ffffce0f
2d0b7920 0000000000000001 ffffce0f
2a902c10 ffffce0f00000000 : FLTMGR!FltpFsControl+0x12c 13 ffffc905
3fb0f230 fffff804813def49 : ffffce0f
2d0b7920 ffffce0f2a902c10 fffff804
80eef8e0 fffff804`80ae39de : nt!IopfCallDriver+0x56
Ye, the stack agrees that address 0x18 was accessed, which caused the
bugcheck. That would be FsContext.
I would have thought FGFNI could handle (with an error code) such a case
(where FO is NULL), but seems not. Maybe that is why I added
IgnoreIfFSIsNull in CREATE two decades ago
To answer your original question, FGFNI is safe to call in your test cade;
it should simply return an error if if should not be called, as long as
Data is not corrupted.
This seems like another case, that needs adding, in the list of 200KB of
FGFNI workaround code that I already have
You could test if it fails for opening of the volume in PreCreate? It
should be a NULL FO IIRC, so calling FGFNI would bugcheck here also? Not
sure about this, it was 2 decades or so since I started adding ignoring of
NULL FO in any of my code.
Regards, Dejan.
This is an IRP_MJ_VOLUME_MOUNT:
#define IRP_MJ_VOLUME_MOUNT ((UCHAR)-19)
There’s no File Object for this operation (and no name) so just don’t call FGFNI.