BSOD KMODE_EXCEPTION_NOT_HANDL in FltNotifyFilterChangeDirectory for IRP_MN_NOTIFY_CHANGE_DIRECTORY

Hi All,

I am trying to implement IRP_MN_NOTIFY_CHANGE_DIRECTORY in minifilter driver.

FltGetVolumeFromInstance( FltObjects->Instance, &RetVolume_notify);
FltGetDeviceObject( RetVolume_notify, &VolumeDeviceObject);
Vcb = &((PVOLUME_DEVICE_OBJECT) VolumeDeviceObject)->Vcb;
FltNotifyFilterChangeDirectory(Vcb->NotifySync,
&Vcb->DirNotifyList,
fileObject->FsContext2,
(PSTRING)&fileObject->FileName,
TRUE,
TRUE,
iopb->Parameters.DirectoryControl.NotifyDirectory.CompletionFilter,
Cbd,
NULL,
NULL,
NULL);

					status = STATUS_PENDING;

but it results in BSOD :frowning:

I can check that Vcb->NotifySync and &Vcb->DirNotifyList are NULL. Who initializes it??

call stack:
2: kd> knL

Child-SP RetAddr Call Site

00 ffffdc8169c7bce8 fffff8018032330d nt!KeBugCheckEx
01 ffffdc8169c7bcf0 fffff8018038ba02 nt!KiDispatchException+0x22d
02 ffffdc8169c7c3a0 fffff80180388a40 nt!KiExceptionDispatch+0xc2
03 ffffdc8169c7c580 fffff801806489ff nt!KiPageFault+0x400
04 ffffdc8169c7c710 fffff80b82b20c4b nt!FsRtlNotifyFilterChangeDirectory+0x43
05 ffffdc8169c7c7a0 fffff80b84434255 FLTMGR!FltNotifyFilterChangeDirectory+0xfb
06 ffffdc8169c7c820 fffff80b82b26c47 sfntpffd!PfmPreCombinedCallback+0x8b5
07 ffffdc8169c7c990 fffff80b82ad46ca FLTMGR!FltvPreOperation+0xd7
08 ffffdc8169c7cac0 fffff80b82ad4278 FLTMGR!FltpPerformPreCallbacks+0x2ea
09 ffffdc8169c7cbd0 fffff80b82ad3386 FLTMGR!FltpPassThroughInternal+0x88
0a ffffdc8169c7cc00 fffff80b82ad312e FLTMGR!FltpPassThrough+0x1a6
0b ffffdc8169c7cc80 fffff8018091bd26 FLTMGR!FltpDispatch+0x9e
0c ffffdc8169c7cce0 fffff80180297de2 nt!IovCallDriver+0x252
0d ffffdc8169c7cd20 fffff80b8632689e nt!IofCallDriver+0x72
0e ffffdc8169c7cd60 fffff80b863266d9 srv2!Smb2IssueChangeNotify+0x1b2
0f ffffdc8169c7cda0 fffff80b8632c1d6 srv2!Smb2ExecuteChangeNotify+0x29
10 ffffdc8169c7cde0 fffff80b8632bc8b srv2!Smb2ExecuteProviderCallback+0x56
11 ffffdc8169c7ce40 fffff80b863222c2 srv2!Srv2ProcessPacket+0xeb
12 ffffdc8169c7cf00 fffff8018037ed77 srv2!RfspThreadPoolNodeWorkerProcessWorkItems+0x132
13 ffffdc8169c7cf80 fffff8018037ed3d nt!KxSwitchKernelStackCallout+0x27
14 ffffdc816972c9f0 fffff80180320841 nt!KiSwitchKernelStackContinue
15 ffffdc816972ca10 fffff801803204a6 nt!KiExpandKernelStackAndCalloutOnStackSegment+0x241
16 ffffdc816972caa0 fffff8018032036f nt!KiExpandKernelStackAndCalloutSwitchStack+0xa6
17 ffffdc816972cb00 fffff80b86322103 nt!KeExpandKernelStackAndCalloutInternal+0x2f
18 ffffdc816972cb50 fffff80180758628 srv2!RfspThreadPoolNodeWorkerRun+0xe3
19 ffffdc816972cbb0 fffff80180244005 nt!IopThreadStart+0x34
1a ffffdc816972cc10 fffff80180382c26 nt!PspSystemThreadStartup+0x41
1b ffffdc816972cc60 0000000000000000 nt!KiStartSystemThread+0x16

: kd> dx -r1 ((sfntpffd!_VCB *)0xffff93861c738bc8)
((sfntpffd!_VCB *)0xffff93861c738bc8) : 0xffff93861c738bc8 [Type: _VCB *]
[+0x000] VolumeFileHeader [Type: _FSRTL_ADVANCED_FCB_HEADER]
[+0x068] VcbLinks [Type: _LIST_ENTRY]
[+0x078] TargetDeviceObject : 0x0 [Type: _DEVICE_OBJECT *]
[+0x080] Vpb : 0x0 [Type: _VPB *]
[+0x088] VcbState : 0x0 [Type: unsigned long]
[+0x08c] VcbCondition : 0 [Type: _VCB_CONDITION]
[+0x090] RootDcb : 0x0 [Type: _PFM_FCB *]
[+0x098] DirectAccessOpenCount : 0x0 [Type: unsigned long]
[+0x09c] ShareAccess [Type: _SHARE_ACCESS]
[+0x0b8] OpenFileCount : 0x0 [Type: unsigned long]
[+0x0bc] ReadOnlyCount : 0x0 [Type: unsigned long]
[+0x0c0] InternalOpenCount : 0x0 [Type: unsigned long]
[+0x0c4] ResidualOpenCount : 0x0 [Type: unsigned long]
[+0x0c8] AllocationSupport [Type: ]
[+0x0e8] DirtyFatMcb [Type: _LARGE_MCB]
[+0x108] FreeClusterBitMap [Type: _RTL_BITMAP]
[+0x118] FreeClusterBitMapMutex [Type: _FAST_MUTEX]
[+0x150] Resource [Type: _ERESOURCE]
[+0x1b8] ChangeBitMapResource [Type: _ERESOURCE]
[+0x220] VirtualVolumeFile : 0xffff93861c738e90 [Type: _FILE_OBJECT *]
[+0x228] SectionObjectPointers [Type: _SECTION_OBJECT_POINTERS]
[+0x240] ClusterHint : 0x1c738e08 [Type: unsigned long]
[+0x248] CurrentDevice : 0xffff93861c738e08 : Device for “” [Type: _DEVICE_OBJECT *]
[+0x250] VirtualEaFile : 0xffff93861c738e18 [Type: _FILE_OBJECT *]
[+0x258] EaFcb : 0xffff93861c738e18 [Type: _PFM_FCB *]
[+0x260] FileObjectWithVcbLocked : 0xffff93861c738e90 [Type: _FILE_OBJECT ]
[+0x268] DirNotifyList [Type: _LIST_ENTRY]
** [+0x278] NotifySync : 0x0 [Type: _REAL_NOTIFY_SYNC ]
[+0x280] DirectoryFileCreationMutex [Type: _FAST_MUTEX]

[+0x2b8] VerifyThread : 0x0 [Type: _KTHREAD *]
[+0x2c0] CleanVolumeDpc [Type: _KDPC]
[+0x300] CleanVolumeTimer [Type: _KTIMER]
[+0x340] LastFatMarkVolumeDirtyCall : {0} [Type: _LARGE_INTEGER]
[+0x348] Statistics : 0x0 [Type: _FILE_SYSTEM_STATISTICS *]
[+0x350] Tunnel [Type: TUNNEL]
[+0x3a8] ChangeCount : 0x0 [Type: unsigned long]
[+0x3b0] SwapVpb : 0x0 [Type: _VPB *]
[+0x3b8] AsyncCloseList [Type: _LIST_ENTRY]
[+0x3c8] DelayedCloseList [Type: _LIST_ENTRY]
[+0x3d8] AdvancedFcbHeaderMutex [Type: _FAST_MUTEX]
[+0x410] CloseContext : 0x0 [Type: CLOSE_CONTEXT *]
[+0x418] CloseContextCount : 0x0 [Type: unsigned long]

I am bit new to this. Can anyone give me any clue whats is missing from my end.

Thanks alot!
Pooja

You don’t own the volume device object, its extension, or its private structure. As best I can tell you’re basically pointing off to random memory with a random definition of the lower file system’s structures. Unless I’m mistaken and this is your volume, your file system, and your structure??

Step back and tell us what you’re trying to do…

Hi Scott,

Thanks for your reply.

We have shadow file object design for our encryption based minifilter driver.

Test scenario is like this:
We have 3 windows machines, 1st machine is having our product installed and encryption policy is applied to shared path C:\enc .
From 2nd machine, we are trying to create a new directory/file on shared path \ip_of_1stMAchine\enc\New_folder.
now, issue is on 3rd machine, we don’t see any file/directory added in shared path \ip_of_1stMAchine\enc

Currently we are bypassing IRP_MN_NOTIFY_CHANGE_DIRECTORY call to lower file object.

Are we supposed to mandatory call FltNotifyFilterChangeDirectory() to handle IRP_MN_NOTIFY_CHANGE_DIRECTORY for this issue ?

Thanks
Pooja

No, you shouldn’t need to do anything with notify change directory. The file system will process these as you create/modify the lower file.

Thanks Scott!

Is it related to directory caching??
I tried below registry settings and it worked
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters
Setting all 3 entries to zero.
a. DirectoryCacheLifetime
b. FileNotFoundCacheLifetime
c. FileInfoCacheLifetime

But still not sure, how should I take care of directory updates in minifilter??

Any help is really appreciated!!
Pooja

The file system is responsible for handling the directory change notification requests and calling the FsRtlNotifyDirectory package when necessary to notify the application. If you are reflecting operations down the lower file system (e.g. when you get an IRP_MJ_CREATE you send an equivalent lower FltCreateFile) then you don’t need to do anythign with directory change notifications. They’ll fire in the lower file system when it receives your operations. The only time you really need to care about directory change notifications in a filter is if you’re virtualizing the directory (e.g. the directory you present doesn’t exist on the lower file system) or if you want to hide your modifications from the user (e.g. you don’t want the user to know you created a file on the lower file system).