BSOD (0x0A) observed with my encryption filter driver

NTFSD
1

Hi,

I am getting a BSOD with my encryption mini filter driver.
This mini filter can be configured to encrypt all files being written to a particular folder.
Now when I try installing TrendMicro AV to this encrypted folder, I get the following BSOD.

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {100060040, 2, 1, fffff8000169c898}

Probably caused by : ntkrnlmp.exe ( nt!KiTryUnwaitThread+28 )

Followup: MachineOwner

WARNING: Whitespace at start of path element
3: kd> .reload
Loading Kernel Symbols
…
…
…
Loading User Symbols
Loading unloaded module list
…
3: kd> .reload /f /i MiniFilter.sys
3: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000000100060040, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff8000169c898, address which referenced memory

Debugging Details:

WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff800018be0e8
GetUlongFromAddress: unable to read from fffff800018be198
0000000100060040 Nonpaged pool

CURRENT_IRQL: 2

FAULTING_IP:
nt!KiTryUnwaitThread+28
fffff800`0169c898 f0480fba6b4000 lock bts qword ptr [rbx+40h],0

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT_SERVER

BUGCHECK_STR: 0xA

PROCESS_NAME: svchost.exe

TRAP_FRAME: fffff880042e4570 – (.trap 0xfffff880042e4570)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffffa80103e5488 rbx=0000000000000000 rcx=fffff88001ecc180
rdx=fffffa80103e5488 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8000169c898 rsp=fffff880042e4700 rbp=0000000000000000
r8=0000000000000100 r9=0000000000000000 r10=fffff80001809880
r11=fffff880042e4790 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
nt!KiTryUnwaitThread+0x28:
fffff8000169c898 f0480fba6b4000 lock bts qword ptr [rbx+40h],0 ds:0000000000000040=???
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff8000168cbe9 to fffff8000168d640

STACK_TEXT:
fffff880042e4428 fffff8000168cbe9 : 000000000000000a 0000000100060040 0000000000000002 0000000000000001 : nt!KeBugCheckEx
fffff880042e4430 fffff8000168b860 : fffffa800f4059b0 fffff800016a2a7c fffffa8010401250 0000000100060000 : nt!KiBugCheckDispatch+0x69
fffff880042e4570 fffff8000169c898 : fffffa800f4059b0 fffff880042e4780 fffffa800f405c78 0000000000000000 : nt!KiPageFault+0x260
fffff880042e4700 fffff80001694823 : fffffa80104012d8 0000000000000000 fffffa80104012d0 fffffa800da31748 : nt!KiTryUnwaitThread+0x28
fffff880042e4760 fffff80001691706 : 0000000000000000 fffff880012f96df 0000000000000000 fffff880042e4a01 : nt!KiSignalSynchronizationObject+0x203
fffff880042e47b0 fffff80001971d31 : fffffa8000000000 0000000000000000 fffffa800f405900 00000000000001dc : nt!KeSetEvent+0x106
fffff880042e4820 fffff8000196c9bd : 0000000000000003 0000000000000004 fffff880042e4ca0 00000000000007ff : nt!IopQueryXxxInformation+0x161
fffff880042e48b0 fffff8000196cec2 : fffffa8010401250 fffff88000000000 fffff880042e4a00 0000000003466b80 : nt!IopQueryNameInternal+0x27d
fffff880042e4950 fffff800019652d0 : fffff880042e4bc8 fffffa800f8ec1e0 fffffa80103e1400 0000000000000000 : nt!IopQueryName+0x26
fffff880042e49a0 fffff8000196e6f9 : fffffa8010401250 0000000003466b80 0000000000000218 fffff880042e4af8 : nt!ObpQueryNameString+0xb0
fffff880042e4aa0 fffff8000168c8d3 : fffffa80103e1400 0000000002f4f5b8 fffff880042e4bc8 0000000000000000 : nt!NtQueryObject+0x1c7
fffff880042e4bb0 00000000772d141a : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13
0000000002f4f598 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x772d141a

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!KiTryUnwaitThread+28
fffff800`0169c898 f0480fba6b4000 lock bts qword ptr [rbx+40h],0

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: nt!KiTryUnwaitThread+28

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4ce7951a

FAILURE_BUCKET_ID: X64_0xA_nt!KiTryUnwaitThread+28

BUCKET_ID: X64_0xA_nt!KiTryUnwaitThread+28

Followup: MachineOwner

3: kd> .trap 0xfffff880042e4570
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffffa80103e5488 rbx=0000000000000000 rcx=fffff88001ecc180
rdx=fffffa80103e5488 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8000169c898 rsp=fffff880042e4700 rbp=0000000000000000
r8=0000000000000100 r9=0000000000000000 r10=fffff80001809880
r11=fffff880042e4790 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
nt!KiTryUnwaitThread+0x28:
fffff8000169c898 f0480fba6b4000 lock bts qword ptr [rbx+40h],0 ds:0000000000000040=???

2

KiTryUnwaitThread is attempting to grab a spin lock, but the pointer to it is not valid. I’m not sure what the origin of that spin lock is (you should walk backwards in the code stream to figure that out) but something is corrupted. My first guess had been the KWAIT_BLOCK, but there’s no spin lock in it directly.

This isn’t an obvious problem - it is going to require that you do some debugging to figure it out.

Tony
OSR

3

Hi Tony,
Thanks for your reply.
One of my team mates solved this issue by progressively commenting out code in the driver and
checking what was causing this BSOD.

The cause was found to be in a function in our PreCreate, where we copy the
attributes of the Shadow File Object to the FltObjects->FileObject.

Here’s the exact code which was commented out to fix the crash:
//fileObject->LastLock = LowerFileObject->LastLock;
//fileObject->Lock = LowerFileObject->Lock;

Now my question is, what all fields of the FltObjects->FileObject can be safely replaced with the corresponding fields of the LowerFileObject.
Btw, we get the LowerFileObject by simpling calling a FltCreateFileEx2() inside the PreCreate.

regards,
V.N.Raju

4

Are you implementing your own byte range locking?

Tony
OSR

5

Hi Tony,
Sorry for replying late.
Yes, we do implement byte range locking in our PreRead and PreWrite and on conflicts we complete with status set as STATUS_FILE_LOCK_CONFLICT.