We received a BSOD, that happened in our minifilter’s DriverEntry right after the call to FltStartFiltering (!):
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
This is a very common BugCheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff802e2da878c, The address that the exception occurred at
Arg3: ffff960049a86388, Exception Record Address
Arg4: ffff960049a85bd0, Context Record Address
Call stack:
nt!KeBugCheckEx
nt!PspSystemThreadStartup$filt$0+0x44
nt!_C_specific_handler+0x9f
nt!RtlpExecuteHandlerForException+0xd
nt!RtlDispatchException+0x421
nt!KiDispatchException+0x1e4
nt!KiExceptionDispatch+0xc2
nt!KiPageFault+0x406
FLTMGR!FltpInitInstance+0x324
FLTMGR!FltpCreateInstanceFromName+0x1ad
FLTMGR!FltpEnumerateRegistryInstances+0x145
FLTMGR!FltpDoVolumeNotificationForNewFilter+0xb9
FLTMGR!FltStartFiltering+0x2c
OurDriver
Attempt to write to address 0000000000000030
FLTMGR!FltpInitInstance+0x324:
lock and dword ptr [rax+30h],0FFFFFBFFh
The only unusual thing I found was having multiple frames instead of just 0. MSDN and books like Windows kernel programming don’t explain the reason for this split too well (other than this being because of a legacy filter driver) as its a very rare case.
!fltkd.filters
Filter List: ffffaa8b881d1930 "Frame 1"
FLT_FILTER: ffffaa8b881dec50 "Our Minifilter" "313234"
FLT_INSTANCE: ffffaa8b881f8c70 "Our Minifilter Instance" "313234"
FLT_INSTANCE: ffffaa8b881f6840 "Our Minifilter Instance" "313234"
FLT_INSTANCE: ffffaa8b881f3c70 "Our Minifilter Instance" "313234"
FLT_INSTANCE: ffffaa8b881f34c0 "Our Minifilter Instance" "313234"
FLT_INSTANCE: ffffaa8b881f0c70 "Our Minifilter Instance" "313234"
FLT_INSTANCE: ffffaa8b881f04c0 "Our Minifilter Instance" "313234"
FLT_INSTANCE: ffffaa8b881dc490 "Our Minifilter Instance" "313234"
Filter List: ffffaa8b83bea300 "Frame 0"
FLT_FILTER: ffffaa8b827f2c40 "VirtFile" "280700"
FLT_INSTANCE: ffffaa8b84463c50 "VirtFile Instance" "280700"
FLT_INSTANCE: ffffaa8b87174490 "VirtFile Instance" "280700"
FLT_FILTER: ffffaa8b8739b010 "storqosflt" "244000"
FLT_FILTER: ffffaa8b8739d010 "wcifs" "189900"
FLT_FILTER: ffffaa8b8445e8b0 "FileCrypt" "141100"
FLT_FILTER: ffffaa8b873a8010 "luafv" "135000"
FLT_INSTANCE: ffffaa8b873a54b0 "luafv" "135000"
FLT_FILTER: ffffaa8b84496b10 "npsvctrig" "46000"
FLT_INSTANCE: ffffaa8b84a61010 "npsvctrig" "46000"
FLT_FILTER: ffffaa8b83bfd460 "Wof" "40700"
FLT_INSTANCE: ffffaa8b84a69b90 "Wof Instance" "40700"
My questions are :
- How can I find the legacy filter driver that is causing this split?
- What cause our minifilter to go to frame 1 instead of 0?
- Could this BSOD be related to this split? If not, how can I find the root cause of it, considering that we are simply calling FltStartFiltering?
Edit:
Based on reversing the functions in the stack, i think this could be related to pFltVolume->FrameZeroVolume being zero (and fltmgr trying to access the flag member of it which is offset 0x30)( pFltVolume is a PFLT_VOLUME), and it kinda makes sense this being related to this bugcheck, considering that we are on frame 1 and then for some reason its accessing FrameZeroVolume (which I have no Idea what this FrameZeroVolume even is…).
I came to this conclusion because of the following code :
__int64 __fastcall FltpDoVolumeNotificationForNewFilter(PFLT_FILTER ourFilter)
{
Frame = ourFilter->Frame;
ourFilter->Flags |= 2u;
v3 = 0;
KeEnterCriticalRegion();
p_rLock = &Frame->AttachedVolumes.rLock;
ExAcquireResourceSharedLite(&Frame->AttachedVolumes.rLock, 1u);
p_rList = &Frame->AttachedVolumes.rList;
Flink = Frame->AttachedVolumes.rList.Flink;
And then Flink[-1] is passed to FltpInitInstance as second argument which it seems like its a PFLT_VOLUME. (Note that these are just guesses, I dont even know what FrameZeroVolume is)
And years ago someone seems to have faces the same issue too :
https://community.osr.com/discussion/274512/flt-volume-with-a-null-framezerovolume
!fltkd.volumes
Volume List: ffffaa8b881d19b0 "Frame 1"
FLT_VOLUME: ffffaa8b881fe010 "\Device\Mup"
FLT_INSTANCE: ffffaa8b881f8c70 "Our Minifilter Instance" "313234"
FLT_VOLUME: ffffaa8b881fd010 "\Device\NamedPipe"
FLT_VOLUME: ffffaa8b881fc010 "\Device\Mailslot"
FLT_VOLUME: ffffaa8b881fb010 "\Device\HarddiskVolume1"
FLT_INSTANCE: ffffaa8b881f6840 "Our Minifilter Instance" "313234"
FLT_VOLUME: ffffaa8b881fa010 "\Device\HarddiskVolume7"
FLT_INSTANCE: ffffaa8b881f3c70 "Our Minifilter Instance" "313234"
FLT_VOLUME: ffffaa8b881f9010 "\Device\HarddiskVolume5"
FLT_INSTANCE: ffffaa8b881f34c0 "Our Minifilter Instance" "313234"
FLT_VOLUME: ffffaa8b881f8010 "\Device\HarddiskVolume3"
FLT_INSTANCE: ffffaa8b881f0c70 "Our Minifilter Instance" "313234"
FLT_VOLUME: ffffaa8b881f7010 "\Device\HarddiskVolume2"
FLT_INSTANCE: ffffaa8b881f04c0 "Our Minifilter Instance" "313234"
FLT_VOLUME: ffffaa8b881f6010 "\Device\Tape1"
FLT_INSTANCE: ffffaa8b881dc490 "Our Minifilter Instance" "313234"
FLT_VOLUME: ffffaa8b881f5010 "\Device\Tape0"
Volume List: ffffaa8b83bea380 "Frame 0"
FLT_VOLUME: ffffaa8b84680010 "\Device\Mup"
FLT_VOLUME: ffffaa8b84bfc010 "\Device\HarddiskVolume3"
FLT_VOLUME: ffffaa8b84866010 "\Device\HarddiskVolume2"
FLT_INSTANCE: ffffaa8b84463c50 "VirtFile Instance" "280700"
FLT_INSTANCE: ffffaa8b873a54b0 "luafv" "135000"
FLT_INSTANCE: ffffaa8b84a69b90 "Wof Instance" "40700"
FLT_VOLUME: ffffb284cc2d07e0 "\Device\NamedPipe"
FLT_INSTANCE: ffffaa8b84a61010 "npsvctrig" "46000"
FLT_VOLUME: ffffb284cc2cf7e0 "\Device\Mailslot"
FLT_VOLUME: ffffaa8b870e1010 "\Device\HarddiskVolume5"
FLT_INSTANCE: ffffaa8b87174490 "VirtFile Instance" "280700"
FLT_VOLUME: ffffaa8b8717f4c0 "\Device\HarddiskVolume7"
FLT_VOLUME: ffffaa8b81aa6010 "\Device\HarddiskVolume1"