What is the purpose of fileobject->lock structure in file system filter driver?


I am working on minifilter file system encryption driver based on shadow fileobject design.

I can see 2 members in FILE_OBJECT structure.

When should I initialize these and how?

Thanks in advance,

> When should I initialize these and how?

I never have.

Why you need this tell us your use case first. why u even think about them…


Use case: I am trying to export .pst file on an encrypted network share path.

Bugcheck is observed as per below call stack:

00 (Inline Function) ---------------- nt!InsertTailList+0xf ? the head here is NULL 01 ffffd00021ab8a30 fffff804004949ed nt!KeWaitForSingleObject+0x1ff 02 (Inline Function) ---------------- nt!IopWaitForLockAlertable+0x39
03 ffffd00021ab8ac0 fffff80400584687 nt!IopAcquireFileObjectLock+0x85
04 ffffd00021ab8b10 fffff804001627b3 nt!NtUnlockFile+0xeb70b
05 ffffd00021ab8bd0 00007ffae63ec5ea nt!KiSystemServiceCopyEnd+0x13
06 0000003cf538cf68 00007ffae37edfad ntdll!ZwUnlockFile+0xa
07 0000003cf538cf70 00007ffae37edffc KERNELBASE!UnlockFileEx+0x3d
08 0000003cf538cfc0 00007ffaae808522 KERNELBASE!UnlockFile+0x34
09 0000003cf538d020 00007ffaae8082e2 mspst32!MSProviderInit+0x6e2a
0a 0000003cf538d060 00007ffaae8081d8 mspst32!MSProviderInit+0x6bea
0b 0000003cf538d0e0 00007ffaae8c8950 mspst32!MSProviderInit+0x6ae0
0c 0000003cf538d160 0000000000000000 mspst32!PSTCrashRecovery+0x954

IopAcquireFileObjectLock is trying to acquire lock on file object and fileobject->Lock is not intialized as observed.

In IRP_MJ_CREATE , we are initializing FileObject and completing it.

I tried to modify behavior of IRP_MJ_CREATE by calling KeInitializeEvent( &(FileObject->Lock), SynchronizationEvent , FALSE);

This helps for this BSOD,but I am not sure if this expected to do it in a shadow FileObject design.

Can you please suggest about this.


The Lock field is automatically initialized by the I/O Manager for
synchronous file opens. I can see three possible reasons for your crash:

  1. You’ve opened a file asychronous and then played with the File Object

  2. You have a reference counting problem and the File Object was freed

  3. The File Object became corrupt somehow

You need to dig out the File Object and look at it in the debugger. What
does !pool say? If you dump out the File Object (dt nt!_FILE_OBJECT address)
does it look OK or like garbage?

Also, make sure you turn Driver Verifier on for your driver and FltMgr.sys.
This might point you to the problem much earlier.


Like you said its a shadow file object based design so I think you can do initialize it at the time of creation of a file object. did you tried without encryption ? if yes what IO mgr is sending at the first place? if IO mgr is sending it as non initialized then there is noting to worry.
if he sends it initialized the your driver somehow poking it…
If at all in both cases it is uninitialized then use driver verifire and try to reproduce it with verifier soon you will get to why it is coming.