BSOD in Windows 10

mike_rich · September 10, 2015, 4:20pm

Hi All,

I have a layer file system filter driver, it works fine in windows 2012 R2 or before versions. But when I tested in windows 10, I will get this BSOD from time to time.

I enabled the driver verifier for my driver, but it didn’t catch anything.

!analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6)
N bytes of memory was allocated and more than N bytes are being referenced.
This cannot be protected by try-except.
When possible, the guilty driver’s name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: ffffcf80c05ab050, memory referenced
Arg2: 0000000000000000, value 0 = read operation, 1 = write operation
Arg3: fffff80103ec1171, if non-zero, the address which referenced memory.
Arg4: 0000000000000000, (reserved)

Debugging Details:

BUGCHECK_P1: ffffcf80c05ab050

BUGCHECK_P2: 0

BUGCHECK_P3: fffff80103ec1171

BUGCHECK_P4: 0

READ_ADDRESS: ffffcf80c05ab050 Special pool

FAULTING_IP:
NTFS!NtfsFindStartingNode+651
fffff801`03ec1171 498b80b0000000 mov rax,qword ptr [r8+0B0h]

MM_INTERNAL_CODE: 0

IMAGE_NAME: NTFS.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 55b99edf

MODULE_NAME: NTFS

FAULTING_MODULE: fffff80103e00000 NTFS

CPU_COUNT: 1

CPU_MHZ: 703

CPU_VENDOR: GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 2d

CPU_STEPPING: 7

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0xD6

PROCESS_NAME: svchost.exe

CURRENT_IRQL: 2

ANALYSIS_VERSION: 10.0.10240.9 amd64fre

TRAP_FRAME: ffffd001f641daf0 – (.trap 0xffffd001f641daf0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=ffffc000403c7630 rbx=0000000000000000 rcx=0000000000000001
rdx=0000000000000020 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80103ec1171 rsp=ffffd001f641dc80 rbp=ffffe001a19ca2f0
r8=ffffcf80c05aafa0 r9=ffffd001f641deb0 r10=0000000000000001
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc
NTFS!NtfsFindStartingNode+0x651:
fffff80103ec1171 498b80b0000000 mov rax,qword ptr [r8+0B0h] ds:ffffcf80c05ab050=???
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff8002ae78136 to fffff8002add7920

STACK_TEXT:
ffffd001f641d0f8 fffff8002ae78136 : 0000000000000050 0000000000000003 ffffd001f641d260 fffff8002ad0ccc8 : nt!DbgBreakPointWithStatus
ffffd001f641d100 fffff8002ae77a66 : 0000000000000003 ffffd001f641d260 fffff8002added60 ffffd001f641d7b0 : nt!KiBugCheckDebugBreak+0x12
ffffd001f641d160 fffff8002add2344 : 0000000000000000 0000000000000000 78002afc60000000 0000000000000001 : nt!KeBugCheck2+0x93e
ffffd001f641d870 fffff8002ae21f58 : 0000000000000050 ffffcf80c05ab050 0000000000000000 ffffd001f641daf0 : nt!KeBugCheckEx+0x104
ffffd001f641d8b0 fffff8002aca3536 : 0000000000000000 0000000000000000 ffffd001f641daf0 ffffc000403c5558 : nt! ?? ::FNODOBFM::string'+0x41158 ffffd001f641d9a0 fffff8002addb2bd : ffffe001a1cb9080 fffff80103ee7c27 ffffc000403c51d0 ffffc000403c5558 : nt!MmAccessFault+0x696 ffffd001f641daf0 fffff80103ec1171 : ffffe001a08b3520 fffff8002b3c7da3 0000000000000030 ffffe001a08b3520 : nt!KiPageFault+0x13d ffffd001f641dc80 fffff80103ec1d8a : ffffe001a06df8c8 ffffcf80bff60b40 0000000000000000 ffffd001f641deb0 : NTFS!NtfsFindStartingNode+0x651 ffffd001f641dd40 fffff80103ec182d : ffffe001a06df8c8 ffffcf80bff60b40 ffffd001fafe4050 ffffe001a1cb9001 : NTFS!NtfsCommonCreate+0x52a ffffd001f641df50 fffff8002add4da7 : ffffd001fafe4000 0000000000000000 0000000000000000 0000000000000000 : NTFS!NtfsCommonCreateCallout+0x1d ffffd001f641df80 fffff8002add4d6d : 0000000000006000 0000000000000012 ffffd001f641e000 fffff8002ad00564 : nt!KxSwitchKernelStackCallout+0x27 ffffd001fafe3e40 fffff8002ad00564 : 0000000000000006 0000000000006000 ffffe001a1fc5000 0000000000000006 : nt!KiSwitchKernelStackContinue ffffd001fafe3e60 fffff8002ad002d6 : 0000000000000009 0000000000006000 0000000000000000 ffffd001fafe3ee0 : nt!KiExpandKernelStackAndCalloutOnStackSegment+0x134 ffffd001fafe3ee0 fffff8002ad0019f : ffffe001a0bf1030 ffffd001fafe4000 0000000000000001 ffffcf80bff60b40 : nt!KiExpandKernelStackAndCalloutSwitchStack+0xa6 ffffd001fafe3f40 fffff80103ec4f9d : 0000000000000000 0000000000000000 ffffe001a06df8c8 ffffcf80bff60b40 : nt!KeExpandKernelStackAndCalloutInternal+0x2f ffffd001fafe3f90 fffff8002b3b2044 : ffffe001a0bf1030 ffffcf80bff60b40 ffffd001fafe4100 fffff8002b3c8a96 : NTFS!NtfsFsdCreate+0x1dd ffffd001fafe41b0 fffff8002ad166c2 : ffffe001a0904a90 0000000000000000 ffffcf80bff60b40 ffffe001a25d2010 : nt!IovCallDriver+0x3d8 ffffd001fafe4210 fffff801033351c4 : ffffd001fafe4319 ffffcf80bff60b40 ffffe001a1bcbe20 ffffe001a1bcbe78 : nt!IofCallDriver+0x72 ffffd001fafe4250 fffff8010336383a : ffffe001a0bdd6c0 ffffe001a01627f0 0000000000000001 fffff80000000000 : FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2a4 ffffd001fafe42d0 fffff8002b3b2044 : ffffcf80bff60b00 ffffcf80bff60b40 6d4e6f4900000005 0000000000000000 : FLTMGR!FltpCreate+0x34a ffffd001fafe4380 fffff8002ad166c2 : 0000000000000004 ffffd001fafe4701 0000000000000000 ffffe001a073db70 : nt!IovCallDriver+0x3d8 ffffd001fafe43e0 fffff8002b0b0866 : 0000000000000004 ffffd001fafe4701 0000000000000000 ffffe00100000000 : nt!IofCallDriver+0x72 ffffd001fafe4420 fffff8002b19752a : 00000000000001bc ffffe001a01627f0 0000000000000200 ffffe001a19ca2f0 : nt!IopParseDevice+0x9a6 ffffd001fafe4630 fffff8002b0ab9d1 : 00000000000001bc ffffd001fafe4790 ffffe001a19ca2c0 fffff8002b197474 : nt!IopParseFile+0xb6 ffffd001fafe4690 fffff8002b10a38c : ffffe001a185c901 ffffd001fafe48b8 00ffffe000000040 ffffe0019ed4f080 : nt!ObpLookupObjectName+0x711 ffffd001fafe4830 fffff8002b10669c : ffffe00100000001 ffffe001a01627f0 000000e768b1e018 000000e768b1e008 : nt!ObOpenObjectByName+0x1ec ffffd001fafe4960 fffff8002b10625c : 000000e768b1e070 000000e768b1df78 000000e768b1e018 000000e768b1e008 : nt!IopCreateFile+0x38c ffffd001fafe4a00 fffff8002addc863 : ffffc00046592b40 fffff8002b0a505d 0000000000023dd3 0000000000000000 : nt!NtOpenFile+0x58 ffffd001fafe4a90 00007ffdb4c6382a : 00007ffd95f6f93a 000000e768b1e128 00000000000001bc 000000e767ad47d0 : nt!KiSystemServiceCopyEnd+0x13 000000e768b1df88 00007ffd95f6f93a : 000000e768b1e128 00000000000001bc 000000e767ad47d0 0000000000000001 : ntdll!NtOpenFile+0xa 000000e768b1df90 00007ffd95f7022c : ffffffffffffffff 00000000000001bc 0000000000000000 ffffffffffffffff : defragsvc!FsOpenAlternateStream+0x12e 000000e768b1e070 00007ffd95f703a0 : 0000000000000000 00000000000001bc 000000e767d07300 ffffffffffffffff : defragsvc!CNtfsVolume::_GetHandleToFile+0x1ec 000000e768b1e110 00007ffd95f7996e : 00007ffd95f702f0 000000e7f0000f74 000000e768f0ee60 000000e768b1e310 : defragsvc!CNtfsVolume::_GetHandleToFile+0xb0 000000e768b1e190 00007ffd95f7ee77 : ffffffffffffffff 000000e767d06d20 000000e767d07300 0000000000000000 : defragsvc!CVolume::MovePieceOfFile+0x9e 000000e768b1e230 00007ffd95f525b2 : 000000e767d06d20 000000e767d04ff0 000000e767d06d20 0000000000000000 : defragsvc!CFileOperation::MoveFileExtents+0x547 000000e768b1e380 00007ffd95f52c86 : 000000e767d050e0 0000000000000001 000000e7f0000f74 000000e767d04ff0 : defragsvc!CDefragOperation::_Defragment+0x862 000000e768b1e540 00007ffd95f516ee : 000000e767d06d20 000000e768b1e7b0 000000e700000000 000000e768b1e730 : defragsvc!CRunBootOptimize::_DefragmentBootOpt+0x546 000000e768b1e6a0 00007ffd95f4e4fe : 00007ffd95f3fa00 00007ffd95f50db0 000000e767d06d20 000000e767d06330 : defragsvc!CRunBootOptimize::RunOperation+0x93e 000000e768b1ed00 00007ffd95f3c9a4 : 0000000000000000 0000000000000000 00007ffd95f4e2d0 000000e767d061f0 : defragsvc!CDefragOperation::Run+0x22e 000000e768b1ed90 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 00000000`00000000 : defragsvc!CDefragAsyncWorker::InvokeRunnable+0x124

STACK_COMMAND: kb

FOLLOWUP_IP:
NTFS!NtfsFindStartingNode+651
fffff801`03ec1171 498b80b0000000 mov rax,qword ptr [r8+0B0h]

SYMBOL_STACK_INDEX: 7

SYMBOL_NAME: NTFS!NtfsFindStartingNode+651

FOLLOWUP_NAME: MachineOwner

IMAGE_VERSION: 10.0.10240.16412

BUCKET_ID_FUNC_OFFSET: 651

FAILURE_BUCKET_ID: 0xD6_VRF_R_INVALID_NTFS!NtfsFindStartingNode

BUCKET_ID: 0xD6_VRF_R_INVALID_NTFS!NtfsFindStartingNode

PRIMARY_PROBLEM_CLASS: 0xD6_VRF_R_INVALID_NTFS!NtfsFindStartingNode

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0xd6_vrf_r_invalid_ntfs!ntfsfindstartingnode

FAILURE_ID_HASH: {04038402-84a3-c185-fa0a-8006e288fbae}

Followup: MachineOwner

kd> !verifier 0x80 ffffcf80c05ab050

Log of recent kernel pool Allocate and Free operations:

There are up to 0x10000 entries in the log.

Parsing 0x0000000000010000 log entries, searching for address 0xffffcf80c05ab050.

Parsed entry 0000000000010000/0000000000010000…
Finished parsing all pool tracking information.
No entries matching address ffffcf80c05ab050 have been found.

Any suggestion how to debug it?

Thanks
Mike

Pavel_Lebedinsky · September 11, 2015, 12:47am

Does !verifier 80 ffffcf80c05aafa0 show anything?

From: xxxxx@hotmail.com mailto:xxxxx
Sent: ?9/?10/?2015 1:20 PM
To: Windows File Systems Devs Interest Listmailto:xxxxx
Subject: [ntfsd] BSOD in Windows 10

Hi All,

I have a layer file system filter driver, it works fine in windows 2012 R2 or before versions. But when I tested in windows 10, I will get this BSOD from time to time.

I enabled the driver verifier for my driver, but it didn’t catch anything.

!analyze -v

Bugcheck Analysis

DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6)
N bytes of memory was allocated and more than N bytes are being referenced.
This cannot be protected by try-except.
When possible, the guilty driver’s name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: ffffcf80c05ab050, memory referenced
Arg2: 0000000000000000, value 0 = read operation, 1 = write operation
Arg3: fffff80103ec1171, if non-zero, the address which referenced memory.
Arg4: 0000000000000000, (reserved)

Debugging Details:
------------------

BUGCHECK_P1: ffffcf80c05ab050

BUGCHECK_P2: 0

BUGCHECK_P3: fffff80103ec1171

BUGCHECK_P4: 0

READ_ADDRESS: ffffcf80c05ab050 Special pool

FAULTING_IP:
NTFS!NtfsFindStartingNode+651
fffff80103ec1171 498b80b0000000 mov rax,qword ptr [r8+0B0h] MM_INTERNAL_CODE: 0 IMAGE_NAME: NTFS.sys DEBUG_FLR_IMAGE_TIMESTAMP: 55b99edf MODULE_NAME: NTFS FAULTING_MODULE: fffff80103e00000 NTFS CPU_COUNT: 1 CPU_MHZ: 703 CPU_VENDOR: GenuineIntel CPU_FAMILY: 6 CPU_MODEL: 2d CPU_STEPPING: 7 DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT BUGCHECK_STR: 0xD6 PROCESS_NAME: svchost.exe CURRENT_IRQL: 2 ANALYSIS_VERSION: 10.0.10240.9 amd64fre TRAP_FRAME: ffffd001f641daf0 -- (.trap 0xffffd001f641daf0) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=ffffc000403c7630 rbx=0000000000000000 rcx=0000000000000001 rdx=0000000000000020 rsi=0000000000000000 rdi=0000000000000000 rip=fffff80103ec1171 rsp=ffffd001f641dc80 rbp=ffffe001a19ca2f0 r8=ffffcf80c05aafa0 r9=ffffd001f641deb0 r10=0000000000000001 r11=0000000000000000 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei ng nz na po nc NTFS!NtfsFindStartingNode+0x651: fffff80103ec1171 498b80b0000000 mov rax,qword ptr [r8+0B0h] ds:ffffcf80c05ab050=???????????????? Resetting default scope LAST_CONTROL_TRANSFER: from fffff8002ae78136 to fffff8002add7920 STACK_TEXT: ffffd001f641d0f8 fffff8002ae78136 : 0000000000000050 0000000000000003 ffffd001f641d260 fffff8002ad0ccc8 : nt!DbgBreakPointWithStatus ffffd001f641d100 fffff8002ae77a66 : 0000000000000003 ffffd001f641d260 fffff8002added60 ffffd001f641d7b0 : nt!KiBugCheckDebugBreak+0x12 ffffd001f641d160 fffff8002add2344 : 0000000000000000 0000000000000000 78002afc60000000 0000000000000001 : nt!KeBugCheck2+0x93e ffffd001f641d870 fffff8002ae21f58 : 0000000000000050 ffffcf80c05ab050 0000000000000000 ffffd001f641daf0 : nt!KeBugCheckEx+0x104 ffffd001f641d8b0 fffff8002aca3536 : 0000000000000000 0000000000000000 ffffd001f641daf0 ffffc000403c5558 : nt! ?? ::FNODOBFM::string’+0x41158
ffffd001f641d9a0 fffff8002addb2bd : ffffe001a1cb9080 fffff80103ee7c27 ffffc000403c51d0 ffffc000403c5558 : nt!MmAccessFault+0x696
ffffd001f641daf0 fffff80103ec1171 : ffffe001a08b3520 fffff8002b3c7da3 0000000000000030 ffffe001a08b3520 : nt!KiPageFault+0x13d
ffffd001f641dc80 fffff80103ec1d8a : ffffe001a06df8c8 ffffcf80bff60b40 0000000000000000 ffffd001f641deb0 : NTFS!NtfsFindStartingNode+0x651
ffffd001f641dd40 fffff80103ec182d : ffffe001a06df8c8 ffffcf80bff60b40 ffffd001fafe4050 ffffe001a1cb9001 : NTFS!NtfsCommonCreate+0x52a
ffffd001f641df50 fffff8002add4da7 : ffffd001fafe4000 0000000000000000 0000000000000000 0000000000000000 : NTFS!NtfsCommonCreateCallout+0x1d
ffffd001f641df80 fffff8002add4d6d : 0000000000006000 0000000000000012 ffffd001f641e000 fffff8002ad00564 : nt!KxSwitchKernelStackCallout+0x27
ffffd001fafe3e40 fffff8002ad00564 : 0000000000000006 0000000000006000 ffffe001a1fc5000 0000000000000006 : nt!KiSwitchKernelStackContinue
ffffd001fafe3e60 fffff8002ad002d6 : 0000000000000009 0000000000006000 0000000000000000 ffffd001fafe3ee0 : nt!KiExpandKernelStackAndCalloutOnStackSegment+0x134
ffffd001fafe3ee0 fffff8002ad0019f : ffffe001a0bf1030 ffffd001fafe4000 0000000000000001 ffffcf80bff60b40 : nt!KiExpandKernelStackAndCalloutSwitchStack+0xa6
ffffd001fafe3f40 fffff80103ec4f9d : 0000000000000000 0000000000000000 ffffe001a06df8c8 ffffcf80bff60b40 : nt!KeExpandKernelStackAndCalloutInternal+0x2f
ffffd001fafe3f90 fffff8002b3b2044 : ffffe001a0bf1030 ffffcf80bff60b40 ffffd001fafe4100 fffff8002b3c8a96 : NTFS!NtfsFsdCreate+0x1dd
ffffd001fafe41b0 fffff8002ad166c2 : ffffe001a0904a90 0000000000000000 ffffcf80bff60b40 ffffe001a25d2010 : nt!IovCallDriver+0x3d8
ffffd001fafe4210 fffff801033351c4 : ffffd001fafe4319 ffffcf80bff60b40 ffffe001a1bcbe20 ffffe001a1bcbe78 : nt!IofCallDriver+0x72
ffffd001fafe4250 fffff8010336383a : ffffe001a0bdd6c0 ffffe001a01627f0 0000000000000001 fffff80000000000 : FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2a4
ffffd001fafe42d0 fffff8002b3b2044 : ffffcf80bff60b00 ffffcf80bff60b40 6d4e6f4900000005 0000000000000000 : FLTMGR!FltpCreate+0x34a
ffffd001fafe4380 fffff8002ad166c2 : 0000000000000004 ffffd001fafe4701 0000000000000000 ffffe001a073db70 : nt!IovCallDriver+0x3d8
ffffd001fafe43e0 fffff8002b0b0866 : 0000000000000004 ffffd001fafe4701 0000000000000000 ffffe00100000000 : nt!IofCallDriver+0x72
ffffd001fafe4420 fffff8002b19752a : 00000000000001bc ffffe001a01627f0 0000000000000200 ffffe001a19ca2f0 : nt!IopParseDevice+0x9a6
ffffd001fafe4630 fffff8002b0ab9d1 : 00000000000001bc ffffd001fafe4790 ffffe001a19ca2c0 fffff8002b197474 : nt!IopParseFile+0xb6
ffffd001fafe4690 fffff8002b10a38c : ffffe001a185c901 ffffd001fafe48b8 00ffffe000000040 ffffe0019ed4f080 : nt!ObpLookupObjectName+0x711
ffffd001fafe4830 fffff8002b10669c : ffffe00100000001 ffffe001a01627f0 000000e768b1e018 000000e768b1e008 : nt!ObOpenObjectByName+0x1ec
ffffd001fafe4960 fffff8002b10625c : 000000e768b1e070 000000e768b1df78 000000e768b1e018 000000e768b1e008 : nt!IopCreateFile+0x38c
ffffd001fafe4a00 fffff8002addc863 : ffffc00046592b40 fffff8002b0a505d 0000000000023dd3 0000000000000000 : nt!NtOpenFile+0x58
ffffd001fafe4a90 00007ffdb4c6382a : 00007ffd95f6f93a 000000e768b1e128 00000000000001bc 000000e767ad47d0 : nt!KiSystemServiceCopyEnd+0x13
000000e768b1df88 00007ffd95f6f93a : 000000e768b1e128 00000000000001bc 000000e767ad47d0 0000000000000001 : ntdll!NtOpenFile+0xa
000000e768b1df90 00007ffd95f7022c : ffffffffffffffff 00000000000001bc 0000000000000000 ffffffffffffffff : defragsvc!FsOpenAlternateStream+0x12e
000000e768b1e070 00007ffd95f703a0 : 0000000000000000 00000000000001bc 000000e767d07300 ffffffffffffffff : defragsvc!CNtfsVolume::_GetHandleToFile+0x1ec
000000e768b1e110 00007ffd95f7996e : 00007ffd95f702f0 000000e7f0000f74 000000e768f0ee60 000000e768b1e310 : defragsvc!CNtfsVolume::_GetHandleToFile+0xb0
000000e768b1e190 00007ffd95f7ee77 : ffffffffffffffff 000000e767d06d20 000000e767d07300 0000000000000000 : defragsvc!CVolume::MovePieceOfFile+0x9e
000000e768b1e230 00007ffd95f525b2 : 000000e767d06d20 000000e767d04ff0 000000e767d06d20 0000000000000000 : defragsvc!CFileOperation::MoveFileExtents+0x547
000000e768b1e380 00007ffd95f52c86 : 000000e767d050e0 0000000000000001 000000e7f0000f74 000000e767d04ff0 : defragsvc!CDefragOperation::_Defragment+0x862
000000e768b1e540 00007ffd95f516ee : 000000e767d06d20 000000e768b1e7b0 000000e700000000 000000e768b1e730 : defragsvc!CRunBootOptimize::_DefragmentBootOpt+0x546
000000e768b1e6a0 00007ffd95f4e4fe : 00007ffd95f3fa00 00007ffd95f50db0 000000e767d06d20 000000e767d06330 : defragsvc!CRunBootOptimize::RunOperation+0x93e
000000e768b1ed00 00007ffd95f3c9a4 : 0000000000000000 0000000000000000 00007ffd95f4e2d0 000000e767d061f0 : defragsvc!CDefragOperation::Run+0x22e
000000e768b1ed90 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : defragsvc!CDefragAsyncWorker::InvokeRunnable+0x124

STACK_COMMAND: kb

FOLLOWUP_IP:
NTFS!NtfsFindStartingNode+651
fffff801`03ec1171 498b80b0000000 mov rax,qword ptr [r8+0B0h]

SYMBOL_STACK_INDEX: 7

SYMBOL_NAME: NTFS!NtfsFindStartingNode+651

FOLLOWUP_NAME: MachineOwner

IMAGE_VERSION: 10.0.10240.16412

BUCKET_ID_FUNC_OFFSET: 651

FAILURE_BUCKET_ID: 0xD6_VRF_R_INVALID_NTFS!NtfsFindStartingNode

BUCKET_ID: 0xD6_VRF_R_INVALID_NTFS!NtfsFindStartingNode

PRIMARY_PROBLEM_CLASS: 0xD6_VRF_R_INVALID_NTFS!NtfsFindStartingNode

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0xd6_vrf_r_invalid_ntfs!ntfsfindstartingnode

FAILURE_ID_HASH: {04038402-84a3-c185-fa0a-8006e288fbae}

Followup: MachineOwner
---------

kd> !verifier 0x80 ffffcf80c05ab050

Log of recent kernel pool Allocate and Free operations:

There are up to 0x10000 entries in the log.

Parsing 0x0000000000010000 log entries, searching for address 0xffffcf80c05ab050.

Parsed entry 0000000000010000/0000000000010000…
Finished parsing all pool tracking information.
No entries matching address ffffcf80c05ab050 have been found.

Any suggestion how to debug it?

Thanks
Mike

—
NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>

mike_rich · September 11, 2015, 1:28pm

Here is the output:

!verifier 80 ffffcf80c05aafa0

Log of recent kernel pool Allocate and Free operations:

There are up to 0x10000 entries in the log.

Parsing 0x0000000000010000 log entries, searching for address 0xffffcf80c05aafa0.

======================================================================
Pool block ffffcf80c05aafa0, Size 0000000000000058, Thread ffffe001a1cb9080
fffff8002b3b352d nt!VeAllocatePoolWithTagPriority+0x2f5
fffff80103479592 VerifierExt!ExAllocatePoolWithTagPriority_internal_wrapper+0x82
fffff8002b3b362f nt!VerifierExAllocatePoolEx+0x4f
fffff80105833cdc MyFilter!AllocatePool+0x3c
fffff8010587d9e5 MyFilter!InitializeFCB+0x55
fffff8010587e09a MyFilter!ProcessFileRequest+0x48a
fffff8010587eafc MyFilter!ProcessPreCreate+0x2fc
fffff8010587f47f MyFilter!PreCreateOperationHandler+0x32f
fffff8010583d5a1 MyFilter!PreOperationHandler+0x161
fffff80103386c3d FLTMGR!FltvPreOperation+0xdd
fffff80103334621 FLTMGR!FltpPerformPreCallbacks+0x2f1
fffff801033341dc FLTMGR!FltpPassThroughInternal+0x8c
fffff80103363826 FLTMGR!FltpCreate+0x336

Pool block ffffcf80c05aab40, Size 00000000000004c0, Thread ffffe001a0d5d080
fffff8002b3c3225 nt!VfFreePoolNotification+0x5d
fffff8002aef7d65 nt!ExFreePool+0x9d
fffff8002b3be4d3 nt!VfIoFreeIrp+0x20b
fffff8002b3b2331 nt!IovFreeIrpPrivate+0x61
fffff8002b0b0955 nt!IopParseDevice+0xa95
fffff8002b0ab9d1 nt!ObpLookupObjectName+0x711
fffff8002b10a38c nt!ObOpenObjectByName+0x1ec
fffff8002b10669c nt!IopCreateFile+0x38c
fffff8002b1061e3 nt!IoCreateFileEx+0x103
fffff80103361f32 FLTMGR!FltpExpandFilePathWorker+0x292
fffff801033652f6 FLTMGR!FltpExpandFilePath+0x1a
fffff80103364cec FLTMGR!FltpGetNormalizedFileNameWorker+0xb4
fffff80103364bce FLTMGR!FltpGetNormalizedFileName+0x1a

Pool block ffffcf80c05aab40, Size 00000000000004c0, Thread ffffe001a0d5d080
fffff8002b3b352d nt!VeAllocatePoolWithTagPriority+0x2f5
fffff8002b3be947 nt!ViIrpAllocateLockedPacket+0x5f
fffff8002b3b1862 nt!IovAllocateIrp+0x5e
fffff8002b0b05f3 nt!IopParseDevice+0x733
fffff8002b0ab9d1 nt!ObpLookupObjectName+0x711
fffff8002b10a38c nt!ObOpenObjectByName+0x1ec
fffff8002b10669c nt!IopCreateFile+0x38c
fffff8002b1061e3 nt!IoCreateFileEx+0x103
fffff80103361f32 FLTMGR!FltpExpandFilePathWorker+0x292
fffff801033652f6 FLTMGR!FltpExpandFilePath+0x1a
fffff80103364cec FLTMGR!FltpGetNormalizedFileNameWorker+0xb4
fffff80103364bce FLTMGR!FltpGetNormalizedFileName+0x1a
fffff801033643ec FLTMGR!FltpCreateFileNameInformation+0x32c

Pool block ffffcf80c05aaea0, Size 0000000000000160, Thread ffffe001a0524080
fffff8002b3c3225 nt!VfFreePoolNotification+0x5d
fffff8002aef7d65 nt!ExFreePool+0x9d
fffff8002b3be4d3 nt!VfIoFreeIrp+0x20b
fffff8002b3b2331 nt!IovFreeIrpPrivate+0x61
fffff8002accde01 nt!IopCompleteRequest+0x331
fffff8002acc5556 nt!KiDeliverApc+0x136
fffff8002acc9396 nt!KiSwapThread+0x426
fffff8002acc8ae8 nt!KiCommitThreadWait+0x148
fffff8002accad35 nt!KeWaitForSingleObject+0x385
fffff8002b0a6512 nt!NtWaitForSingleObject+0xf2
fffff8002addc863 nt!KiSystemServiceCopyEnd+0x13

Pool block ffffcf80c05aaea0, Size 0000000000000160, Thread ffffe001a0524080
fffff8002b3b352d nt!VeAllocatePoolWithTagPriority+0x2f5
fffff8002b3be947 nt!ViIrpAllocateLockedPacket+0x5f
fffff8002b3b1862 nt!IovAllocateIrp+0x5e
fffff8002b0b1edd nt!IopXxxControlFile+0x47d
fffff8002b0b1a56 nt!NtDeviceIoControlFile+0x56
fffff8002addc863 nt!KiSystemServiceCopyEnd+0x13

Pool block ffffcf80c05aab40, Size 00000000000004c0, Thread ffffe001a0524080
fffff8002b3c3225 nt!VfFreePoolNotification+0x5d
fffff8002aef7d65 nt!ExFreePool+0x9d
fffff8002b3be4d3 nt!VfIoFreeIrp+0x20b
fffff8002b3b2331 nt!IovFreeIrpPrivate+0x61
fffff8002accde01 nt!IopCompleteRequest+0x331
fffff8002ad17a01 nt!NtSetInformationFile+0x861
fffff8002addc863 nt!KiSystemServiceCopyEnd+0x13

Pool block ffffcf80c05aab40, Size 00000000000004c0, Thread ffffe001a0524080
fffff8002b3b352d nt!VeAllocatePoolWithTagPriority+0x2f5
fffff8002b3be947 nt!ViIrpAllocateLockedPacket+0x5f
fffff8002b3b1862 nt!IovAllocateIrp+0x5e
fffff8002ad17696 nt!NtSetInformationFile+0x4f6
fffff8002addc863 nt!KiSystemServiceCopyEnd+0x13
Parsed entry 0000000000010000/0000000000010000…
Finished parsing all pool tracking information.

So the address is the pool for FSRTL_ADVANCED_FCB_HEADER I allocated.

The structure I used for FSRTL_ADVANCED_FCB_HEADER is:

typedef struct _FSRTL_ADVANCED_FCB_HEADER
{

FSRTL_COMMON_FCB_HEADER DUMMYSTRUCTNAME;
PFAST_MUTEX FastMutex;
LIST_ENTRY FilterContexts;

} FSRTL_ADVANCED_FCB_HEADER;

Is this structure cause the issue?

Thanks
Mike

Alexandru_Gurzou · September 11, 2015, 2:07pm

Well you’re allocating a structure of size 0x58 bytes (as seen by the last
log entry) and you’re trying to access the offset +0xB0 as can be seen at:

fffff80103ec1171 498b80b0000000 mov rax,qword ptr [r8+\*0B0\*h] ds:ffffcf80c05ab050=???

Are you doing some pointer arithmetic? The reason why I’m asking is that
offset 0xB0 (2 * 0x58) would be the entry at index 2 in a
FSRTL_ADVANCED_FCB_HEADER array :).

On 11 September 2015 at 20:28, wrote:

> Here is the output:
>
> !verifier 80 ffffcf80c05aafa0
>
> Log of recent kernel pool Allocate and Free operations:
>
> There are up to 0x10000 entries in the log.
>
> Parsing 0x0000000000010000 log entries, searching for address
> 0xffffcf80c05aafa0.
>
>
> ======================================================================
> Pool block ffffcf80c05aafa0, Size 0000000000000058, Thread ffffe001a1cb9080
> fffff8002b3b352d nt!VeAllocatePoolWithTagPriority+0x2f5
> fffff80103479592
> VerifierExt!ExAllocatePoolWithTagPriority_internal_wrapper+0x82
> fffff8002b3b362f nt!VerifierExAllocatePoolEx+0x4f
> fffff80105833cdc MyFilter!AllocatePool+0x3c
> fffff8010587d9e5 MyFilter!InitializeFCB+0x55
> fffff8010587e09a MyFilter!ProcessFileRequest+0x48a
> fffff8010587eafc MyFilter!ProcessPreCreate+0x2fc
> fffff8010587f47f MyFilter!PreCreateOperationHandler+0x32f
> fffff8010583d5a1 MyFilter!PreOperationHandler+0x161
> fffff80103386c3d FLTMGR!FltvPreOperation+0xdd
> fffff80103334621 FLTMGR!FltpPerformPreCallbacks+0x2f1
> fffff801033341dc FLTMGR!FltpPassThroughInternal+0x8c
> fffff80103363826 FLTMGR!FltpCreate+0x336
> ======================================================================
> Pool block ffffcf80c05aab40, Size 00000000000004c0, Thread ffffe001a0d5d080
> fffff8002b3c3225 nt!VfFreePoolNotification+0x5d
> fffff8002aef7d65 nt!ExFreePool+0x9d
> fffff8002b3be4d3 nt!VfIoFreeIrp+0x20b
> fffff8002b3b2331 nt!IovFreeIrpPrivate+0x61
> fffff8002b0b0955 nt!IopParseDevice+0xa95
> fffff8002b0ab9d1 nt!ObpLookupObjectName+0x711
> fffff8002b10a38c nt!ObOpenObjectByName+0x1ec
> fffff8002b10669c nt!IopCreateFile+0x38c
> fffff8002b1061e3 nt!IoCreateFileEx+0x103
> fffff80103361f32 FLTMGR!FltpExpandFilePathWorker+0x292
> fffff801033652f6 FLTMGR!FltpExpandFilePath+0x1a
> fffff80103364cec FLTMGR!FltpGetNormalizedFileNameWorker+0xb4
> fffff80103364bce FLTMGR!FltpGetNormalizedFileName+0x1a
> ======================================================================
> Pool block ffffcf80c05aab40, Size 00000000000004c0, Thread ffffe001a0d5d080
> fffff8002b3b352d nt!VeAllocatePoolWithTagPriority+0x2f5
> fffff8002b3be947 nt!ViIrpAllocateLockedPacket+0x5f
> fffff8002b3b1862 nt!IovAllocateIrp+0x5e
> fffff8002b0b05f3 nt!IopParseDevice+0x733
> fffff8002b0ab9d1 nt!ObpLookupObjectName+0x711
> fffff8002b10a38c nt!ObOpenObjectByName+0x1ec
> fffff8002b10669c nt!IopCreateFile+0x38c
> fffff8002b1061e3 nt!IoCreateFileEx+0x103
> fffff80103361f32 FLTMGR!FltpExpandFilePathWorker+0x292
> fffff801033652f6 FLTMGR!FltpExpandFilePath+0x1a
> fffff80103364cec FLTMGR!FltpGetNormalizedFileNameWorker+0xb4
> fffff80103364bce FLTMGR!FltpGetNormalizedFileName+0x1a
> fffff801033643ec FLTMGR!FltpCreateFileNameInformation+0x32c
> ======================================================================
> Pool block ffffcf80c05aaea0, Size 0000000000000160, Thread ffffe001a0524080
> fffff8002b3c3225 nt!VfFreePoolNotification+0x5d
> fffff8002aef7d65 nt!ExFreePool+0x9d
> fffff8002b3be4d3 nt!VfIoFreeIrp+0x20b
> fffff8002b3b2331 nt!IovFreeIrpPrivate+0x61
> fffff8002accde01 nt!IopCompleteRequest+0x331
> fffff8002acc5556 nt!KiDeliverApc+0x136
> fffff8002acc9396 nt!KiSwapThread+0x426
> fffff8002acc8ae8 nt!KiCommitThreadWait+0x148
> fffff8002accad35 nt!KeWaitForSingleObject+0x385
> fffff8002b0a6512 nt!NtWaitForSingleObject+0xf2
> fffff8002addc863 nt!KiSystemServiceCopyEnd+0x13
> ======================================================================
> Pool block ffffcf80c05aaea0, Size 0000000000000160, Thread ffffe001a0524080
> fffff8002b3b352d nt!VeAllocatePoolWithTagPriority+0x2f5
> fffff8002b3be947 nt!ViIrpAllocateLockedPacket+0x5f
> fffff8002b3b1862 nt!IovAllocateIrp+0x5e
> fffff8002b0b1edd nt!IopXxxControlFile+0x47d
> fffff8002b0b1a56 nt!NtDeviceIoControlFile+0x56
> fffff8002addc863 nt!KiSystemServiceCopyEnd+0x13
> ======================================================================
> Pool block ffffcf80c05aab40, Size 00000000000004c0, Thread ffffe001a0524080
> fffff8002b3c3225 nt!VfFreePoolNotification+0x5d
> fffff8002aef7d65 nt!ExFreePool+0x9d
> fffff8002b3be4d3 nt!VfIoFreeIrp+0x20b
> fffff8002b3b2331 nt!IovFreeIrpPrivate+0x61
> fffff8002accde01 nt!IopCompleteRequest+0x331
> fffff8002ad17a01 nt!NtSetInformationFile+0x861
> fffff8002addc863 nt!KiSystemServiceCopyEnd+0x13
> ======================================================================
> Pool block ffffcf80c05aab40, Size 00000000000004c0, Thread ffffe001a0524080
> fffff8002b3b352d nt!VeAllocatePoolWithTagPriority+0x2f5
> fffff8002b3be947 nt!ViIrpAllocateLockedPacket+0x5f
> fffff8002b3b1862 nt!IovAllocateIrp+0x5e
> fffff8002ad17696 nt!NtSetInformationFile+0x4f6
> fffff8002addc863 nt!KiSystemServiceCopyEnd+0x13
> Parsed entry 0000000000010000/0000000000010000…
> Finished parsing all pool tracking information.
>
>
> So the address is the pool for FSRTL_ADVANCED_FCB_HEADER I allocated.
>
> The structure I used for FSRTL_ADVANCED_FCB_HEADER is:
>
> typedef struct _FSRTL_ADVANCED_FCB_HEADER
> {
>
> FSRTL_COMMON_FCB_HEADER DUMMYSTRUCTNAME;
> PFAST_MUTEX FastMutex;
> LIST_ENTRY FilterContexts;
>
> } FSRTL_ADVANCED_FCB_HEADER;
>
>
> Is this structure cause the issue?
>
> Thanks
> Mike
>
>
>
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

mike_rich · September 11, 2015, 4:08pm

I didn’t any change for the pointer.
I allocated pool for FSRTL_ADVANCED_FCB_HEADER with following code:

ExAllocatePoolWithTag(NonPagedPool,sizeof(FSRTL_ADVANCED_FCB_HEADER),‘TFCB’);

so the size is 0x58, I dont know why the offset 0xb0 was accessed.

Also I should complete all the pre-create I/O which was set with my own FCB structure.

k

Child-SP RetAddr Call Site

00 ffffd001f641d0f8 fffff8002ae78136 nt!DbgBreakPointWithStatus
01 ffffd001f641d100 fffff8002ae77a66 nt!KiBugCheckDebugBreak+0x12
02 ffffd001f641d160 fffff8002add2344 nt!KeBugCheck2+0x93e
03 ffffd001f641d870 fffff8002ae21f58 nt!KeBugCheckEx+0x104
04 ffffd001f641d8b0 fffff8002aca3536 nt! ?? ::FNODOBFM::string'+0x41158 05 ffffd001f641d9a0 fffff8002addb2bd nt!MmAccessFault+0x696 06 ffffd001f641daf0 fffff80103ec1171 nt!KiPageFault+0x13d 07 ffffd001f641dc80 fffff80103ec1d8a NTFS!NtfsFindStartingNode+0x651 08 ffffd001f641dd40 fffff80103ec182d NTFS!NtfsCommonCreate+0x52a 09 ffffd001f641df50 fffff8002add4da7 NTFS!NtfsCommonCreateCallout+0x1d 0a ffffd001f641df80 fffff8002add4d6d nt!KxSwitchKernelStackCallout+0x27 0b ffffd001fafe3e40 fffff8002ad00564 nt!KiSwitchKernelStackContinue 0c ffffd001fafe3e60 fffff8002ad002d6 nt!KiExpandKernelStackAndCalloutOnStackSegment+0x134 0d ffffd001fafe3ee0 fffff8002ad0019f nt!KiExpandKernelStackAndCalloutSwitchStack+0xa6 0e ffffd001fafe3f40 fffff80103ec4f9d nt!KeExpandKernelStackAndCalloutInternal+0x2f 0f ffffd001fafe3f90 fffff8002b3b2044 NTFS!NtfsFsdCreate+0x1dd 10 ffffd001fafe41b0 fffff8002ad166c2 nt!IovCallDriver+0x3d8 11 ffffd001fafe4210 fffff801033351c4 nt!IofCallDriver+0x72 12 ffffd001fafe4250 fffff8010336383a FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2a4 13 ffffd001fafe42d0 fffff800`2b3b2044 FLTMGR!FltpCreate+0x34a

!thread
THREAD ffffe001a1cb9080 Cid 0e88.0260 Teb: 00007ff7ab2d6000 Win32Thread: 0000000000000000 RUNNING on processor 0
IRP List:
ffffcf80bff60b40: (0006,04c0) Flags: 40000884 Mdl: 00000000
Not impersonating
DeviceMap ffffc0003cc1ba20
Owning Process ffffe001a086d080 Image: svchost.exe
Attached Process N/A Image: N/A
Wait Start TickCount 103818 Ticks: 1 (0:00:00:00.015)
Context Switch Count 16630 IdealProcessor: 0
UserTime 00:00:02.343
KernelTime 00:00:14.015
Win32 Start Address defragsvc!CDefragAsyncWorker::_ThreadFunction (0x00007ffd95f3f0c0)
Stack Init ffffd001f641dfd0 Current ffffd001fafe3d80
Base ffffd001f641e000 Limit ffffd001f6418000 Call 0
Priority 4 BasePriority 4 UnusualBoost 0 ForegroundBoost 0 IoPriority 0 PagePriority 1

!irp ffffcf80bff60b40 1
Irp is active with 13 stacks 12 is current (= 0xffffcf80bff60f28)
No Mdl: No System Buffer: Thread ffffe001a1cb9080: Irp stack trace.
Flags = 40000884
ThreadListEntry.Flink = ffffe001a1cb96e0
ThreadListEntry.Blink = ffffe001a1cb96e0
IoStatus.Status = 00000000
IoStatus.Information = 00000000
RequestorMode = 00000001
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = ffffd001fafe4520
UserEvent = 00000000
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 00000000
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = 00000000
UserBuffer = 00000000
&Tail.Overlay.DeviceQueueEntry = ffffcf80bff60bb8
Tail.Overlay.Thread = ffffe001a1cb9080
Tail.Overlay.AuxiliaryBuffer = 00000000
Tail.Overlay.ListEntry.Flink = 00000000
Tail.Overlay.ListEntry.Blink = 00000000
Tail.Overlay.CurrentStackLocation = ffffcf80bff60f28
Tail.Overlay.OriginalFileObject = ffffe001a1bcbe20

!FileObj ffffe001a1bcbe20

::$REPARSE_POINT

Related File Object: 0xffffe001a19ca2f0

Device Object: 0xffffe001a0b75bc0 \Driver\volmgr
Vpb: 0xffffe001a0b75b00

Flags: 0x2
Synchronous IO

CurrentByteOffset: 0

!FileObj 0xffffe001a19ca2f0

?

Related File Object: 0xffffe001a0578330

Device Object: 0xffffe001a0b75bc0 \Driver\volmgr
Vpb: 0xffffe001a0b75b00
Event signalled

Flags: 0x40000
Handle Created

FsContext: 0xffffcf80c05aafa0 FsContext2: 0x00000000
CurrentByteOffset: 0
Cache Data:
Section Object Pointers: ffffcf80c0060f20
Shared Cache Map: 00000000

Here Fscontext 0xffffcf80c05aafa0 is my FCB header.

Scott_Noone_OSR · September 14, 2015, 12:24pm

Because NTFS is treating *your* FCB as an NTFS FCB. +0xB0 might not be valid
for your FCB, but it (presumably) is for an NTFS FCB.

NTFS has been given one of your file objects. This is always a bug, you have
violated the rules of the isolation layer you created. You need to figure
out how one of your file objects has “leaked” into NTFS.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntfsd…

I didn’t any change for the pointer.
I allocated pool for FSRTL_ADVANCED_FCB_HEADER with following code:

ExAllocatePoolWithTag(NonPagedPool,sizeof(FSRTL_ADVANCED_FCB_HEADER),‘TFCB’);

so the size is 0x58, I dont know why the offset 0xb0 was accessed.

Also I should complete all the pre-create I/O which was set with my own FCB
structure.

k

Child-SP RetAddr Call Site

00 ffffd001f641d0f8 fffff8002ae78136 nt!DbgBreakPointWithStatus
01 ffffd001f641d100 fffff8002ae77a66 nt!KiBugCheckDebugBreak+0x12
02 ffffd001f641d160 fffff8002add2344 nt!KeBugCheck2+0x93e
03 ffffd001f641d870 fffff8002ae21f58 nt!KeBugCheckEx+0x104
04 ffffd001f641d8b0 fffff8002aca3536 nt! ?? ::FNODOBFM::string'+0x41158 05 ffffd001f641d9a0 fffff8002addb2bd nt!MmAccessFault+0x696 06 ffffd001f641daf0 fffff80103ec1171 nt!KiPageFault+0x13d 07 ffffd001f641dc80 fffff80103ec1d8a NTFS!NtfsFindStartingNode+0x651 08 ffffd001f641dd40 fffff80103ec182d NTFS!NtfsCommonCreate+0x52a 09 ffffd001f641df50 fffff8002add4da7 NTFS!NtfsCommonCreateCallout+0x1d 0a ffffd001f641df80 fffff8002add4d6d nt!KxSwitchKernelStackCallout+0x27 0b ffffd001fafe3e40 fffff8002ad00564 nt!KiSwitchKernelStackContinue 0c ffffd001fafe3e60 fffff8002ad002d6 nt!KiExpandKernelStackAndCalloutOnStackSegment+0x134 0d ffffd001fafe3ee0 fffff8002ad0019f nt!KiExpandKernelStackAndCalloutSwitchStack+0xa6 0e ffffd001fafe3f40 fffff80103ec4f9d nt!KeExpandKernelStackAndCalloutInternal+0x2f 0f ffffd001fafe3f90 fffff8002b3b2044 NTFS!NtfsFsdCreate+0x1dd 10 ffffd001fafe41b0 fffff8002ad166c2 nt!IovCallDriver+0x3d8 11 ffffd001fafe4210 fffff801033351c4 nt!IofCallDriver+0x72 12 ffffd001fafe4250 fffff8010336383a FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2a4 13 ffffd001fafe42d0 fffff800`2b3b2044 FLTMGR!FltpCreate+0x34a

!thread
THREAD ffffe001a1cb9080 Cid 0e88.0260 Teb: 00007ff7ab2d6000 Win32Thread:
0000000000000000 RUNNING on processor 0
IRP List:
ffffcf80bff60b40: (0006,04c0) Flags: 40000884 Mdl: 00000000
Not impersonating
DeviceMap ffffc0003cc1ba20
Owning Process ffffe001a086d080 Image: svchost.exe
Attached Process N/A Image: N/A
Wait Start TickCount 103818 Ticks: 1 (0:00:00:00.015)
Context Switch Count 16630 IdealProcessor: 0
UserTime 00:00:02.343
KernelTime 00:00:14.015
Win32 Start Address defragsvc!CDefragAsyncWorker::_ThreadFunction
(0x00007ffd95f3f0c0)
Stack Init ffffd001f641dfd0 Current ffffd001fafe3d80
Base ffffd001f641e000 Limit ffffd001f6418000 Call 0
Priority 4 BasePriority 4 UnusualBoost 0 ForegroundBoost 0 IoPriority 0
PagePriority 1

!irp ffffcf80bff60b40 1
Irp is active with 13 stacks 12 is current (= 0xffffcf80bff60f28)
No Mdl: No System Buffer: Thread ffffe001a1cb9080: Irp stack trace.
Flags = 40000884
ThreadListEntry.Flink = ffffe001a1cb96e0
ThreadListEntry.Blink = ffffe001a1cb96e0
IoStatus.Status = 00000000
IoStatus.Information = 00000000
RequestorMode = 00000001
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = ffffd001fafe4520
UserEvent = 00000000
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 00000000
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = 00000000
UserBuffer = 00000000
&Tail.Overlay.DeviceQueueEntry = ffffcf80bff60bb8
Tail.Overlay.Thread = ffffe001a1cb9080
Tail.Overlay.AuxiliaryBuffer = 00000000
Tail.Overlay.ListEntry.Flink = 00000000
Tail.Overlay.ListEntry.Blink = 00000000
Tail.Overlay.CurrentStackLocation = ffffcf80bff60f28
Tail.Overlay.OriginalFileObject = ffffe001a1bcbe20

!FileObj ffffe001a1bcbe20

::$REPARSE_POINT

Related File Object: 0xffffe001a19ca2f0

Device Object: 0xffffe001a0b75bc0 \Driver\volmgr
Vpb: 0xffffe001a0b75b00

Flags: 0x2
Synchronous IO

CurrentByteOffset: 0

!FileObj 0xffffe001a19ca2f0

?

Related File Object: 0xffffe001a0578330

Device Object: 0xffffe001a0b75bc0 \Driver\volmgr
Vpb: 0xffffe001a0b75b00
Event signalled

Flags: 0x40000
Handle Created

FsContext: 0xffffcf80c05aafa0 FsContext2: 0x00000000
CurrentByteOffset: 0
Cache Data:
Section Object Pointers: ffffcf80c0060f20
Shared Cache Map: 00000000

Here Fscontext 0xffffcf80c05aafa0 is my FCB header.

mike_rich · September 14, 2015, 1:22pm

Thanks Scott,

That’s the question I am asking, why the file object was passed down to the NTFS?

the file object was processed by NTFS is not my file object, it is the file object:

!FileObj ffffe001a1bcbe20
::$REPARSE_POINT

But the related file object is my file object.

So do I need to handle the file open with related file object, if the related file object is my file object I need to process it and complete the file open?

Another question is we only see this issue in Windows 10, didn’t see it in other OS, is it something new in Windows 10 we didn’t handle properly?

Thanks
Mike

OSR_Community_User · September 14, 2015, 1:36pm

Absolutely. You also need to deal with similar issues in the rename and hard link paths (for the target file object).

Tony
OSR

mike_rich · September 14, 2015, 2:01pm

Thanks Tony,

Could you explain a bit more what do I need to handle for hard link paths?

Mike

OSR_Community_User · September 14, 2015, 2:19pm

Both rename and hard links will send you the “target file object” that was created previously with the SL_OPEN_TARGET_DIRECTORY option set. If you pass that file object down to NTFS, you will see a crash.

Thus, you must swap that target file object.

We really need to get our isolation filter kit out there for you folks to use - these are exactly the kinds of issues that we deal with every day.

Tony

mike_rich · September 16, 2015, 11:36am

Hi,

Now I complete all create I/O with related file object which was created by myself, so it didn’t get the issue in create I/O.

But it happens in FILE_SYSTEM_CONTROL I/O, in this request, I will check the FileObject first, if the fileObject is my file object, then I will complete the I/O.

Now the file object ffffe001d9fcaf20 I found is not my file object, but the place which caused the issue is my FCB header, so where can I find out my file object?

NTFS!NtfsDefragFile+0x102:
fffff801b2bed51e 4d8b8ab0000000 mov r9,qword ptr [r10+0B0h] ds:ffffcf8151841050=???

r10=ffffcf8151840fa0 (this is my FCB header)

DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6)
N bytes of memory was allocated and more than N bytes are being referenced.
This cannot be protected by try-except.
When possible, the guilty driver’s name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: ffffcf8151841050, memory referenced
Arg2: 0000000000000000, value 0 = read operation, 1 = write operation
Arg3: fffff801b2bed51e, if non-zero, the address which referenced memory.
Arg4: 0000000000000000, (reserved)

Debugging Details:

BUGCHECK_P1: ffffcf8151841050

BUGCHECK_P2: 0

BUGCHECK_P3: fffff801b2bed51e

BUGCHECK_P4: 0

READ_ADDRESS: ffffcf8151841050 Special pool

FAULTING_IP:
NTFS!NtfsDefragFile+102
fffff801`b2bed51e 4d8b8ab0000000 mov r9,qword ptr [r10+0B0h]

MM_INTERNAL_CODE: 0

IMAGE_NAME: NTFS.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 55b99edf

MODULE_NAME: NTFS

FAULTING_MODULE: fffff801b2b60000 NTFS

CPU_COUNT: 1

CPU_MHZ: 703

CPU_VENDOR: GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 2d

CPU_STEPPING: 7

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0xD6

PROCESS_NAME: svchost.exe

CURRENT_IRQL: 2

ANALYSIS_VERSION: 10.0.10240.9 amd64fre

TRAP_FRAME: ffffd00091fa9230 – (.trap 0xffffd00091fa9230)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=ffffe001da3223f0 rbx=0000000000000000 rcx=ffffd00091fa9468
rdx=ffffe001dae8fe80 rsi=0000000000000000 rdi=0000000000000000
rip=fffff801b2bed51e rsp=ffffd00091fa93c0 rbp=ffffe001da356030
r8=ffffe001dae8ff20 r9=ffffe001da356180 r10=ffffcf8151840fa0
r11=ffffe001d9e28018 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc
NTFS!NtfsDefragFile+0x102:
fffff801b2bed51e 4d8b8ab0000000 mov r9,qword ptr [r10+0B0h] ds:ffffcf8151841050=???
Resetting default scope

kd> !thread
THREAD ffffe001da12a840 Cid 11dc.1274 Teb: 00007ff73fba8000 Win32Thread: 0000000000000000 RUNNING on processor 0
IRP List:
ffffcf8151ea6b40: (0006,04c0) Flags: 40020830 Mdl: 00000000
Not impersonating
DeviceMap ffffc00187e1ba20
Owning Process ffffe001d9b05840 Image: svchost.exe
Attached Process N/A Image: N/A
Wait Start TickCount 357352 Ticks: 1 (0:00:00:00.015)
Context Switch Count 4122 IdealProcessor: 0
UserTime 00:00:02.375
KernelTime 00:00:06.078
Win32 Start Address defragsvc!CDefragAsyncWorker::_ThreadFunction (0x00007ffc6f14f0c0)
Stack Init ffffd00091fa9c90 Current ffffd00091fa76f0
Base ffffd00091faa000 Limit ffffd00091fa4000 Call 0

kd> k

Child-SP RetAddr Call Site

00 ffffd00091fa8838 fffff8008b87b136 nt!DbgBreakPointWithStatus
01 ffffd00091fa8840 fffff8008b87aa66 nt!KiBugCheckDebugBreak+0x12
02 ffffd00091fa88a0 fffff8008b7d5344 nt!KeBugCheck2+0x93e
03 ffffd00091fa8fb0 fffff8008b824f58 nt!KeBugCheckEx+0x104
04 ffffd00091fa8ff0 fffff8008b6a6536 nt! ?? ::FNODOBFM::string'+0x41158 05 ffffd00091fa90e0 fffff8008b7de2bd nt!MmAccessFault+0x696 06 ffffd00091fa9230 fffff801b2bed51e nt!KiPageFault+0x13d 07 ffffd00091fa93c0 fffff801b2c289c8 NTFS!NtfsDefragFile+0x102 08 ffffd00091fa9460 fffff801b2c2854c NTFS!NtfsUserFsRequest+0x208 09 ffffd00091fa94d0 fffff8008bdb5044 NTFS!NtfsFsdFileSystemControl+0x11c 0a ffffd00091fa95e0 fffff8008b7196c2 nt!IovCallDriver+0x3d8 0b ffffd00091fa9640 fffff801b21551c4 nt!IofCallDriver+0x72 0c ffffd00091fa9680 fffff801b2182d55 FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2a4 0d ffffd00091fa9700 fffff8008bdb5044 FLTMGR!FltpFsControl+0x115 0e ffffd00091fa9760 fffff8008b7196c2 nt!IovCallDriver+0x3d8 0f ffffd00091fa97c0 fffff8008bab517d nt!IofCallDriver+0x72 10 ffffd00091fa9800 fffff8008bb066da nt!IopXxxControlFile+0x71d 11 ffffd00091fa9a20 fffff8008b7df863 nt!NtFsControlFile+0x56 12 ffffd00091fa9a90 00007ffc7c91388a nt!KiSystemServiceCopyEnd+0x13 13 000000328a35e008 00007ffc6f18b40a ntdll!NtFsControlFile+0xa 14 000000328a35e010 00007ffc6f1899df defragsvc!CVolume::_MovePieceOfFileByHandle+0x13a 15 000000328a35e180 00007ffc6f18ee77 defragsvc!CVolume::MovePieceOfFile+0x10f 16 000000328a35e220 00007ffc6f1625b2 defragsvc!CFileOperation::MoveFileExtents+0x547 17 000000328a35e370 00007ffc6f162c86 defragsvc!CDefragOperation::_Defragment+0x862 18 000000328a35e530 00007ffc6f1616ee defragsvc!CRunBootOptimize::_DefragmentBootOpt+0x546 19 000000328a35e690 00007ffc6f15e4fe defragsvc!CRunBootOptimize::RunOperation+0x93e 1a 000000328a35ecf0 00007ffc6f14c9a4 defragsvc!CDefragOperation::Run+0x22e 1b 000000328a35ed80 00007ffc6f14f1a8 defragsvc!CDefragAsyncWorker::InvokeRunnable+0x124 1c 000000328a35f290 00007ffc7c614d70 defragsvc!CDefragAsyncWorker::_ThreadFunctionContextCallback+0x28 1d 000000328a35f2c0 00007ffc7c615833 combase!EnterForCallback+0x184 [d:\th\com\combase\dcomrem\crossctx.cxx @ 2089] 1e 000000328a35f3d0 00007ffc7c5e7bd0 combase!SwitchForCallback+0x1f7 [d:\th\com\combase\dcomrem\crossctx.cxx @ 1711] 1f 000000328a35f750 00007ffc7c5e641c combase!PerformCallback+0x114 [d:\th\com\combase\dcomrem\crossctx.cxx @ 1590] 20 000000328a35f7b0 00007ffc7c5e6728 combase!CObjectContext::InternalContextCallback+0xdc [d:\th\com\combase\dcomrem\context.cxx @ 4457] 21 000000328a35f8d0 00007ffc7c66a5c8 combase!CObjectContext::ContextCallback+0x108 [d:\th\com\combase\dcomrem\context.cxx @ 4340] 22 000000328a35f970 00007ffc6f14f148 combase!CContextSwitcher::ContextCallback+0x78 [d:\th\com\combase\dcomrem\ctxconnmgr.cxx @ 435] 23 000000328a35f9c0 00007ffc7bf62d92 defragsvc!CDefragAsyncWorker::_ThreadFunction+0x88 24 000000328a35fa20 00007ffc7c889f64 KERNEL32!BaseThreadInitThunk+0x22 25 000000328a35fa50 00000000`00000000 ntdll!RtlUserThreadStart+0x34

kd> !irp ffffcf8151ea6b40 1
Irp is active with 13 stacks 12 is current (= 0xffffcf8151ea6f28)
No Mdl: System buffer=ffffcf8151126fe0: Thread ffffe001da12a840: Irp stack trace.
Flags = 40020830
ThreadListEntry.Flink = ffffe001da12aea0
ThreadListEntry.Blink = ffffe001da12aea0
IoStatus.Status = 00000000
IoStatus.Information = 00000000
RequestorMode = 00000001
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = 328a35e0a0
UserEvent = 00000000
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 00000000
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = 00000000
UserBuffer = 00000000
&Tail.Overlay.DeviceQueueEntry = ffffcf8151ea6bb8
Tail.Overlay.Thread = ffffe001da12a840
Tail.Overlay.AuxiliaryBuffer = 00000000
Tail.Overlay.ListEntry.Flink = 00000000
Tail.Overlay.ListEntry.Blink = 00000000
Tail.Overlay.CurrentStackLocation = ffffcf8151ea6f28
Tail.Overlay.OriginalFileObject = ffffe001d9fcaf20

kd> !FileObj ffffe001d9fcaf20

Device Object: 0xffffe001da323060 \Driver\volmgr
Vpb: 0xffffe001da3223f0
Access: Read Write SharedRead SharedWrite

Flags: 0x44000a
Synchronous IO
No Intermediate Buffering
Handle Created
Volume Open

File Object is currently busy and has 0 waiters.

FsContext: 0xffffe001da351c20 FsContext2: 0xffffc00192a2c740
CurrentByteOffset: 0
Cache Data:
Section Object Pointers: ffffe001da350240
Shared Cache Map: 00000000

kd> dt nt!_FILE_OBJECT ffffe001d9fcaf20
+0x000 Type : 0n5
+0x002 Size : 0n216
+0x008 DeviceObject : 0xffffe001da323060 _DEVICE_OBJECT +0x010 Vpb : 0xffffe001da3223f0 _VPB
+0x018 FsContext : 0xffffe001da351c20 Void +0x020 FsContext2 : 0xffffc00192a2c740 Void
+0x028 SectionObjectPointer : 0xffffe001da350240 _SECTION_OBJECT_POINTERS +0x030 PrivateCacheMap : (null) +0x038 FinalStatus : 0 +0x040 RelatedFileObject : (null) +0x048 LockOperation : 0 '' +0x049 DeletePending : 0 '' +0x04a ReadAccess : 0x1 '' +0x04b WriteAccess : 0x1 '' +0x04c DeleteAccess : 0 '' +0x04d SharedRead : 0x1 '' +0x04e SharedWrite : 0x1 '' +0x04f SharedDelete : 0 '' +0x050 Flags : 0x44000a +0x058 FileName : _UNICODE_STRING "" +0x068 CurrentByteOffset : _LARGE_INTEGER 0x0 +0x070 Waiters : 0 +0x074 Busy : 1 +0x078 LastLock : (null) +0x080 Lock : _KEVENT +0x098 Event : _KEVENT +0x0b0 CompletionContext : (null) +0x0b8 IrpListLock : 0 +0x0c0 IrpList : _LIST_ENTRY [0xffffe001d9fcafe0 - 0xffffe001`d9fcafe0]
+0x0d0 FileObjectExtension : (null)

Gabriel_Bercea · September 17, 2015, 2:41pm

There must be a FS path/scenario that you leak your FO somehow, there is
no other way.

Use filespy and put some path filters, then check all the requests filters
available and see what you are missing. Try to reproduce this in the path
you are filtering with filespy and see what you might miss.

Gabriel

On Wed, Sep 16, 2015 at 5:36 PM, wrote:

> Hi,
>
> Now I complete all create I/O with related file object which was created
> by myself, so it didn’t get the issue in create I/O.
>
> But it happens in FILE_SYSTEM_CONTROL I/O, in this request, I will check
> the FileObject first, if the fileObject is my file object, then I will
> complete the I/O.
>
> Now the file object ffffe001d9fcaf20 I found is not my file object, but
> the place which caused the issue is my FCB header, so where can I find out
> my file object?
>
> NTFS!NtfsDefragFile+0x102:
> fffff801b2bed51e 4d8b8ab0000000 mov r9,qword ptr [r10+0B0h] > ds:ffffcf8151841050=???
>
> r10=ffffcf8151840fa0 (this is my FCB header)
>
>
> DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6)
> N bytes of memory was allocated and more than N bytes are being referenced.
> This cannot be protected by try-except.
> When possible, the guilty driver’s name (Unicode string) is printed on
> the bugcheck screen and saved in KiBugCheckDriver.
> Arguments:
> Arg1: ffffcf8151841050, memory referenced
> Arg2: 0000000000000000, value 0 = read operation, 1 = write operation
> Arg3: fffff801b2bed51e, if non-zero, the address which referenced memory.
> Arg4: 0000000000000000, (reserved)
>
> Debugging Details:
> ------------------
>
>
> BUGCHECK_P1: ffffcf8151841050
>
> BUGCHECK_P2: 0
>
> BUGCHECK_P3: fffff801b2bed51e
>
> BUGCHECK_P4: 0
>
> READ_ADDRESS: ffffcf8151841050 Special pool
>
> FAULTING_IP:
> NTFS!NtfsDefragFile+102
> fffff801b2bed51e 4d8b8ab0000000 mov r9,qword ptr [r10+0B0h] > > MM_INTERNAL_CODE: 0 > > IMAGE_NAME: NTFS.sys > > DEBUG_FLR_IMAGE_TIMESTAMP: 55b99edf > > MODULE_NAME: NTFS > > FAULTING_MODULE: fffff801b2b60000 NTFS > > CPU_COUNT: 1 > > CPU_MHZ: 703 > > CPU_VENDOR: GenuineIntel > > CPU_FAMILY: 6 > > CPU_MODEL: 2d > > CPU_STEPPING: 7 > > DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT > > BUGCHECK_STR: 0xD6 > > PROCESS_NAME: svchost.exe > > CURRENT_IRQL: 2 > > ANALYSIS_VERSION: 10.0.10240.9 amd64fre > > TRAP_FRAME: ffffd00091fa9230 -- (.trap 0xffffd00091fa9230) > NOTE: The trap frame does not contain all registers. > Some register values may be zeroed or incorrect. > rax=ffffe001da3223f0 rbx=0000000000000000 rcx=ffffd00091fa9468 > rdx=ffffe001dae8fe80 rsi=0000000000000000 rdi=0000000000000000 > rip=fffff801b2bed51e rsp=ffffd00091fa93c0 rbp=ffffe001da356030 > r8=ffffe001dae8ff20 r9=ffffe001da356180 r10=ffffcf8151840fa0 > r11=ffffe001d9e28018 r12=0000000000000000 r13=0000000000000000 > r14=0000000000000000 r15=0000000000000000 > iopl=0 nv up ei ng nz na po nc > NTFS!NtfsDefragFile+0x102: > fffff801b2bed51e 4d8b8ab0000000 mov r9,qword ptr [r10+0B0h]
> ds:ffffcf8151841050=???????????????? > Resetting default scope > > > > kd> !thread > THREAD ffffe001da12a840 Cid 11dc.1274 Teb: 00007ff73fba8000 Win32Thread: > 0000000000000000 RUNNING on processor 0 > IRP List: > ffffcf8151ea6b40: (0006,04c0) Flags: 40020830 Mdl: 00000000 > Not impersonating > DeviceMap ffffc00187e1ba20 > Owning Process ffffe001d9b05840 Image: svchost.exe > Attached Process N/A Image: N/A > Wait Start TickCount 357352 Ticks: 1 (0:00:00:00.015) > Context Switch Count 4122 IdealProcessor: 0 > UserTime 00:00:02.375 > KernelTime 00:00:06.078 > Win32 Start Address defragsvc!CDefragAsyncWorker::_ThreadFunction > (0x00007ffc6f14f0c0) > Stack Init ffffd00091fa9c90 Current ffffd00091fa76f0 > Base ffffd00091faa000 Limit ffffd00091fa4000 Call 0 > > kd> k > # Child-SP RetAddr Call Site > 00 ffffd00091fa8838 fffff8008b87b136 nt!DbgBreakPointWithStatus > 01 ffffd00091fa8840 fffff8008b87aa66 nt!KiBugCheckDebugBreak+0x12 > 02 ffffd00091fa88a0 fffff8008b7d5344 nt!KeBugCheck2+0x93e > 03 ffffd00091fa8fb0 fffff8008b824f58 nt!KeBugCheckEx+0x104 > 04 ffffd00091fa8ff0 fffff8008b6a6536 nt! ?? ::FNODOBFM::string’+0x41158
> 05 ffffd00091fa90e0 fffff8008b7de2bd nt!MmAccessFault+0x696
> 06 ffffd00091fa9230 fffff801b2bed51e nt!KiPageFault+0x13d
> 07 ffffd00091fa93c0 fffff801b2c289c8 NTFS!NtfsDefragFile+0x102
> 08 ffffd00091fa9460 fffff801b2c2854c NTFS!NtfsUserFsRequest+0x208
> 09 ffffd00091fa94d0 fffff8008bdb5044 NTFS!NtfsFsdFileSystemControl+0x11c
> 0a ffffd00091fa95e0 fffff8008b7196c2 nt!IovCallDriver+0x3d8
> 0b ffffd00091fa9640 fffff801b21551c4 nt!IofCallDriver+0x72
> 0c ffffd00091fa9680 fffff801b2182d55
> FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2a4
> 0d ffffd00091fa9700 fffff8008bdb5044 FLTMGR!FltpFsControl+0x115
> 0e ffffd00091fa9760 fffff8008b7196c2 nt!IovCallDriver+0x3d8
> 0f ffffd00091fa97c0 fffff8008bab517d nt!IofCallDriver+0x72
> 10 ffffd00091fa9800 fffff8008bb066da nt!IopXxxControlFile+0x71d
> 11 ffffd00091fa9a20 fffff8008b7df863 nt!NtFsControlFile+0x56
> 12 ffffd00091fa9a90 00007ffc7c91388a nt!KiSystemServiceCopyEnd+0x13
> 13 000000328a35e008 00007ffc6f18b40a ntdll!NtFsControlFile+0xa
> 14 000000328a35e010 00007ffc6f1899df
> defragsvc!CVolume::_MovePieceOfFileByHandle+0x13a
> 15 000000328a35e180 00007ffc6f18ee77
> defragsvc!CVolume::MovePieceOfFile+0x10f
> 16 000000328a35e220 00007ffc6f1625b2
> defragsvc!CFileOperation::MoveFileExtents+0x547
> 17 000000328a35e370 00007ffc6f162c86
> defragsvc!CDefragOperation::_Defragment+0x862
> 18 000000328a35e530 00007ffc6f1616ee
> defragsvc!CRunBootOptimize::_DefragmentBootOpt+0x546
> 19 000000328a35e690 00007ffc6f15e4fe
> defragsvc!CRunBootOptimize::RunOperation+0x93e
> 1a 000000328a35ecf0 00007ffc6f14c9a4
> defragsvc!CDefragOperation::Run+0x22e
> 1b 000000328a35ed80 00007ffc6f14f1a8
> defragsvc!CDefragAsyncWorker::InvokeRunnable+0x124
> 1c 000000328a35f290 00007ffc7c614d70
> defragsvc!CDefragAsyncWorker::_ThreadFunctionContextCallback+0x28
> 1d 000000328a35f2c0 00007ffc7c615833 combase!EnterForCallback+0x184
> [d:\th\com\combase\dcomrem\crossctx.cxx @ 2089]
> 1e 000000328a35f3d0 00007ffc7c5e7bd0 combase!SwitchForCallback+0x1f7
> [d:\th\com\combase\dcomrem\crossctx.cxx @ 1711]
> 1f 000000328a35f750 00007ffc7c5e641c combase!PerformCallback+0x114
> [d:\th\com\combase\dcomrem\crossctx.cxx @ 1590]
> 20 000000328a35f7b0 00007ffc7c5e6728
> combase!CObjectContext::InternalContextCallback+0xdc
> [d:\th\com\combase\dcomrem\context.cxx @ 4457]
> 21 000000328a35f8d0 00007ffc7c66a5c8
> combase!CObjectContext::ContextCallback+0x108
> [d:\th\com\combase\dcomrem\context.cxx @ 4340]
> 22 000000328a35f970 00007ffc6f14f148
> combase!CContextSwitcher::ContextCallback+0x78
> [d:\th\com\combase\dcomrem\ctxconnmgr.cxx @ 435]
> 23 000000328a35f9c0 00007ffc7bf62d92
> defragsvc!CDefragAsyncWorker::_ThreadFunction+0x88
> 24 000000328a35fa20 00007ffc7c889f64 KERNEL32!BaseThreadInitThunk+0x22
> 25 000000328a35fa50 0000000000000000 ntdll!RtlUserThreadStart+0x34
>
> kd> !irp ffffcf8151ea6b40 1
> Irp is active with 13 stacks 12 is current (= 0xffffcf8151ea6f28)
> No Mdl: System buffer=ffffcf8151126fe0: Thread ffffe001da12a840: Irp
> stack trace.
> Flags = 40020830
> ThreadListEntry.Flink = ffffe001da12aea0
> ThreadListEntry.Blink = ffffe001da12aea0
> IoStatus.Status = 00000000
> IoStatus.Information = 00000000
> RequestorMode = 00000001
> Cancel = 00
> CancelIrql = 0
> ApcEnvironment = 00
> UserIosb = 328a35e0a0
> UserEvent = 00000000
> Overlay.AsynchronousParameters.UserApcRoutine = 00000000
> Overlay.AsynchronousParameters.UserApcContext = 00000000
> Overlay.AllocationSize = 00000000 - 00000000
> CancelRoutine = 00000000
> UserBuffer = 00000000
> &Tail.Overlay.DeviceQueueEntry = ffffcf8151ea6bb8
> Tail.Overlay.Thread = ffffe001da12a840
> Tail.Overlay.AuxiliaryBuffer = 00000000
> Tail.Overlay.ListEntry.Flink = 00000000
> Tail.Overlay.ListEntry.Blink = 00000000
> Tail.Overlay.CurrentStackLocation = ffffcf8151ea6f28
> Tail.Overlay.OriginalFileObject = ffffe001d9fcaf20
>
> kd> !FileObj ffffe001d9fcaf20
>
>
>
> Device Object: 0xffffe001da323060 \Driver\volmgr
> Vpb: 0xffffe001da3223f0
> Access: Read Write SharedRead SharedWrite
>
> Flags: 0x44000a
> Synchronous IO
> No Intermediate Buffering
> Handle Created
> Volume Open
>
> File Object is currently busy and has 0 waiters.
>
> FsContext: 0xffffe001da351c20 FsContext2: 0xffffc00192a2c740
> CurrentByteOffset: 0
> Cache Data:
> Section Object Pointers: ffffe001da350240
> Shared Cache Map: 00000000
>
> kd> dt nt!_FILE_OBJECT ffffe001d9fcaf20
> +0x000 Type : 0n5
> +0x002 Size : 0n216
> +0x008 DeviceObject : 0xffffe001da323060 _DEVICE_OBJECT > +0x010 Vpb : 0xffffe001da3223f0 _VPB
> +0x018 FsContext : 0xffffe001da351c20 Void > +0x020 FsContext2 : 0xffffc00192a2c740 Void
> +0x028 SectionObjectPointer : 0xffffe001da350240 > _SECTION_OBJECT_POINTERS > +0x030 PrivateCacheMap : (null) > +0x038 FinalStatus : 0 > +0x040 RelatedFileObject : (null) > +0x048 LockOperation : 0 '' > +0x049 DeletePending : 0 '' > +0x04a ReadAccess : 0x1 '' > +0x04b WriteAccess : 0x1 '' > +0x04c DeleteAccess : 0 '' > +0x04d SharedRead : 0x1 '' > +0x04e SharedWrite : 0x1 '' > +0x04f SharedDelete : 0 '' > +0x050 Flags : 0x44000a > +0x058 FileName : _UNICODE_STRING "" > +0x068 CurrentByteOffset : _LARGE_INTEGER 0x0 > +0x070 Waiters : 0 > +0x074 Busy : 1 > +0x078 LastLock : (null) > +0x080 Lock : _KEVENT > +0x098 Event : _KEVENT > +0x0b0 CompletionContext : (null) > +0x0b8 IrpListLock : 0 > +0x0c0 IrpList : _LIST_ENTRY [0xffffe001d9fcafe0 -
> 0xffffe001`d9fcafe0]
> +0x0d0 FileObjectExtension : (null)
>
>
>
>
>
>
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

–
Bercea. G.

mike_rich · September 17, 2015, 3:39pm

Thanks Gabriel,

Yes, I am sure it is a leak of my FO somehow.

Since all file objects with my FCB I should know, now the file object in this FS control I/O is not my file object, but my file object was used in somewhere, since the place got reference was my FCB.

so even I run the file spy, I can’t filter this path, the file name in this file object is empty.

any idea?

Mike

OSR_Community_User · September 17, 2015, 4:33pm

Your call stack indicates that it’s a defragmentation activity (and a defragmentation FSCTL). My personal guess is that your file object gets down via FSCTL_MOVE_FILE. This IOCTL is targeted to the volume, and contains file handle in the MOVE_FILE_DATA structure.

I got this very problem years ago, when I used to work on a layered filter driver. If I am right, that BSOD will also occur in older OSes (not just Windows 10). Just try to run defragmentation.

mike_rich · September 18, 2015, 12:20pm

Thanks Ladislav,

Your input is very helpful to me, It meant I need to check the I/O which used the structure including the file handle or file object.

Any suggestion to make sure I don’t have leaked file object any more?

Mike

Gabriel_Bercea · September 18, 2015, 1:37pm

Your best bet is to use the File System filter test suite from Microsoft.
Usually is provided for free during the MS Plugfest events to all the
participants. I don’t really know any other way to get it. I believe that
stuff should be free and easy to get for anyone who wants to test their
filters. Maybe someone from MS can give more on this.
This would definitely take your filter through all the possible scenarios
MS could think of and test the outcome. This will indirectly of course mean
that if you have any leaked FCB down to NTFS you will notice.

Gabriel

On Fri, Sep 18, 2015 at 6:19 PM, wrote:

> Thanks Ladislav,
>
> Your input is very helpful to me, It meant I need to check the I/O which
> used the structure including the file handle or file object.
>
> Any suggestion to make sure I don’t have leaked file object any more?
>
> Mike
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

–
Bercea. G.