How to solve DRIVER LEFT LOCKED PAGES IN PROCESS issue

NTFSD
1

When I was writing a Minifilter driver, it was normal to process local files. However, if I needed to process remote shared files, an exception occurred and the system reported when the process ended.

DRIVER_LEFT_LOCKED_PAGES_IN_PROCESS (cb)
Caused by a driver not cleaning up completely after an I/O.
When possible, the guilty driver's name (Unicode string) is printed on
the BugCheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: ffffac05f6fc1f00, The calling address in the driver that locked the pages or if the
IO manager locked the pages this points to the dispatch routine of
the top driver on the stack to which the IRP was sent.
Arg2: 0000000000000000, The caller of the calling address in the driver that locked the
pages. If the IO manager locked the pages this points to the device
object of the top driver on the stack to which the IRP was sent.
Arg3: ffffac05f612a4b0, A pointer to the MDL containing the locked pages.
Arg4: 0000000000000002, The number of locked pages.

PROCESS_NAME: wps.exe

STACK_TEXT:
ffffbc0ad6e91a58 fffff80369334e12 : ffffbc0ad6e91bc0 fffff8036919b470 0000000000000000 0000000000000000 : nt!DbgBreakPointWithStatus
ffffbc0ad6e91a60 fffff803693343f6 : 0000000000000003 ffffbc0ad6e91bc0 fffff80369231ae0 00000000000000cb : nt!KiBugCheckDebugBreak+0x12
ffffbc0ad6e91ac0 fffff80369219bf7 : 0000000000060107 ffffbc0ad6e921d8 ffffac05f39a0f10 0000000000000000 : nt!KeBugCheck2+0x946
ffffbc0ad6e921d0 fffff8036966ab84 : 00000000000000cb ffffac05f6fc1f00 0000000000000000 ffffac05f612a4b0 : nt!KeBugCheckEx+0x107
ffffbc0ad6e92210 fffff8036953c2ef : ffffac05f309f300 ffffbc0ad6e922d0 ffffac05f599f080 ffffac05f309f748 : nt!MmDeleteProcessAddressSpace+0x12bd88
ffffbc0ad6e92260 fffff8036944ad10 : ffffac05f309f2d0 ffffac05f309f2d0 0000000000000000 ffffac05ed6db0c0 : nt!PspProcessDelete+0x13f
ffffbc0ad6e922f0 fffff80369059747 : 0000000000000000 0000000000000000 ffffac05f309f738 ffffac05f309f300 : nt!ObpRemoveObjectRoutine+0x80
ffffbc0ad6e92350 fffff8036940cb7c : 0000000000000000 ffffac05f3632568 ffffac05f3632568 ffffac05f3632568 : nt!ObfDereferenceObjectWithTag+0xc7
ffffbc0ad6e92390 fffff8036944ad10 : ffffac05f3632050 ffffac05f3632050 ffffbc0ad6e92589 0000000000000000 : nt!PspThreadDelete+0x33c
ffffbc0ad6e92400 fffff80369059747 : 0000000000000000 0000000000000000 ffffbc0ad6e92589 ffffac05f3632080 : nt!ObpRemoveObjectRoutine+0x80
ffffbc0ad6e92460 fffff80369450579 : ffffac05f3632050 ffff9c04a5ae47e0 0000000000000000 ffff9c04a5ae47d0 : nt!ObfDereferenceObjectWithTag+0xc7
ffffbc0ad6e924a0 fffff803694f5795 : ffffac05f5fa8098 fffff80369059a39 ffffac05f5fa8060 0000000000000000 : nt!ObCloseHandleTableEntry+0x6c9
ffffbc0ad6e925e0 fffff8036947bb6d : ffffac05f5fa8060 ffffac05f599f080 ffffffffffffff01 ffffac05f455c798 : nt!ExSweepHandleTable+0xd5
ffffbc0ad6e92690 fffff803695313b0 : ffffffffffffffff ffffac05f455c340 ffffbc0ad6e926e0 fffff8036953bb64 : nt!ObKillProcess+0x35
ffffbc0ad6e926c0 fffff8036949c5ae : ffffac05f455c340 ffff9c04a2f256b0 ffffbc0ad6e928e9 0000000000000000 : nt!PspRundownSingleProcess+0x204
ffffbc0ad6e92750 fffff8036950fb38 : 0000000000000000 0000000000000001 0000000000000000 00000000004b4000 : nt!PspExitThread+0x5f6
ffffbc0ad6e92850 fffff803690e3e7d : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSchedulerApcTerminate+0x38
ffffbc0ad6e92890 fffff8036921f190 : 0000000000000000 ffffbc0ad6e92950 ffffbc0ad6e92b00 0000000000000000 : nt!KiDeliverApc+0x60d
ffffbc0ad6e92950 fffff8036922dbaf : 0000000000000000 0000000000000000 0000000000000000 00000000004b4000 : nt!KiInitiateUserApc+0x70
ffffbc0ad6e92a90 00007ffe22a09044 : 00007ffe229f4cb0 0000000003dddbd4 00007ffe229f35b1 0000000000000001 : nt!KiSystemServiceExit+0x9f
0000000003a7e1f8 00007ffe229f4cb0 : 0000000003dddbd4 00007ffe229f35b1 0000000000000001 0000000000000000 : wow64win!NtUserMsgWaitForMultipleObjectsEx+0x14
0000000003a7e200 00007ffe220e90da : 00000000004b4000 00007ffe229f4c20 00000000004b6000 0000000000000000 : wow64win!whNtUserMsgWaitForMultipleObjectsEx+0x90
0000000003a7e260 00000000775817c3 : 0000002375aa586c 0000000000000023 0000000000000006 0000000003dddb60 : wow64!Wow64SystemServiceEx+0x15a
0000000003a7eb20 00000000775811b9 : 0000000003ddf704 00007ffe220e3a74 0000000000000000 00007ffe220e3b6f : wow64cpu!ServiceNoTurbo+0xb
0000000003a7ebd0 00007ffe220e3989 : 00000000032cee78 0000000000000000 0000000000000000 0000000003a7f010 : wow64cpu!BTCpuSimulate+0x9
0000000003a7ec10 00007ffe220e337d : 0000000000000000 0000000000000001 0000000000000000 0000000000000000 : wow64!RunCpuSimulation+0xd
0000000003a7ec40 00007ffe24125059 : 0000000000000000 0000000000000000 0000000000000001 0000000000000000 : wow64!Wow64LdrpInitialize+0x12d
0000000003a7eef0 00007ffe24124c43 : 0000000000000000 00007ffe240b0000 0000000000000000 00000000004b4000 : ntdll!LdrpInitialize+0x3fd
0000000003a7ef90 00007ffe24124bee : 0000000003a7f010 00000000003f0b8d 0000000000000000 0000000000000000 : ntdll!LdrpInitialize+0x3b
0000000003a7efc0 00007ffe240b0000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!LdrInitializeThunk+0xe
0000000003a7eff0 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!RtlLargeIntegerToChar (ntdll+0x0)

I searched for the relevant irp based on the ffffac05f612a4b0 mdl information prompted by the system, but there was no result. I used !irpfind directly and found no relevant information.

I searched previous documents and got some information. When minifilter processes local files and remote files, there is a big difference in caching and oplock. Can you provide me with some information?

thanks!

2

No, this can't be related to SMB oplocks in any way.

Does your driver call MmProbeAndLockPages?

3

thanks for your attention。

I reused FileTest.exe to test my driver. During this process, I used the CopyFileEx function and the same bsod error occurred.

KDTARGET: Refreshing KD connection

*** Fatal System Error: 0x000000cb
(0xFFFFAA8CAAF36700,0x0000000000000000,0xFFFFAA8CA81A70D0,0x0000000000000002)

Break instruction exception - code 80000003 (first chance)

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

nt!DbgBreakPointWithStatus:
fffff800`2ee234b0 cc int 3
*** WARNING: Unable to verify timestamp for ntdll.dll

2: kd> dt _mdl 0xFFFFAA8CA81A70D0
nt!_MDL
+0x000 Next : (null)
+0x008 Size : 0n64
+0x00a MdlFlags : 0n395
+0x00c AllocationProcessorNumber : 0
+0x00e Reserved : 0
+0x010 Process : 0xffffaa8caab89300 _EPROCESS +0x018 MappedSystemVa : 0xffff828024267d80 Void
+0x020 StartVa : 0x00000000`070fd000 Void
+0x028 ByteCount : 0x400
+0x02c ByteOffset : 0xd80

This time, I tried to search the irp using mdl related information and obtained the relevant IRP information.

2: kd> !irpfind 0 0 mdlprocess 0xffffaa8c`aab89300
Looking for IRPs with mdl process == ffffaa8caab89300
Using a machine size of 7ff05 pages to configure the kd cache

Scanning large pool allocation table for tag 0x3f707249 (Irp?) (ffffaa8ca5c50000 : ffffaa8ca5d10000)

Searching nonpaged pool (ffffaa8000000000 : ffffba8000000000) for tag 0x3f707249 (Irp?)

Irp [ Thread ] irpStack: (Mj,Mn) DevObj [Driver] MDL Process
ffffaa8ca8083c70 [ffffaa8ca3c1a080] irpStack: (14, 0) ffffaa8ca2712460 [ \FileSystem\FltMgr] 0xffffaa8caab89300

2: kd> !irp ffffaa8ca8083c70
Irp is active with 4 stacks 4 is current (= 0xffffaa8ca8083e18)
Mdl=ffffaa8ca81a70d0: No System Buffer: Thread ffffaa8ca3c1a080: Irp stack trace.
cmd flg cl Device File Completion-Context
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000

		Args: 00000000 00000000 00000000 00000000

[IRP_MJ_QUERY_SECURITY(14), N/A(0)]
0 0 ffffaa8ca1daf040 00000000 fffff80031371090-ffffaa8ca99fce10
\FileSystem\mrxsmb mup!MupiUncProviderCompletion
Args: 00000000 00000000 00000000 00000000
[IRP_MJ_QUERY_SECURITY(14), N/A(0)]
0 0 ffffaa8ca24facc0 00000000 fffff8002fd2be80-ffffaa8ca7a7f010
\FileSystem\Mup FLTMGR!FltpSynchronizedOperationCompletion
Args: 00000000 00000000 00000000 00000000

[IRP_MJ_QUERY_SECURITY(14), N/A(0)]
0 0 ffffaa8ca2712460 ffffaa8ca7273680 00000000-00000000
\FileSystem\FltMgr
Args: 00000020 00000400 00000000 00000000

Obviously, IRP is related to mup, but I don't know how to deal with this problem? Is this related to cache or Oplock? Can you give me some relevant tips.

There is no part related to mdl in my code.
The specific code is as follows

	Status = FltGetVolumeContext(FltObjects->Filter,
		FltObjects->Volume,
		&volCtx);

	if (!NT_SUCCESS(Status))
	{
		Data->IoStatus.Status = Status;
		Data->IoStatus.Information = 0;
		try_return(FltStatus = FLT_PREOP_COMPLETE);
	}

	ExAcquireResourceExclusiveLite(volCtx->VolResource, TRUE);
	AcquireVolResource = TRUE;

	ExAcquireResourceExclusiveLite(Fcb->Header.Resource, TRUE);
	FcbAcquired = TRUE;


	Status = FltAllocateCallbackData(FltObjects->Instance, Ccb->StreamFileInfo.StreamObject, &RetNewCallbackData);
	if (!NT_SUCCESS(Status))
	{
                   log()
		leave;
	}

	if (NT_SUCCESS(Status))
	{
		RtlCopyMemory(RetNewCallbackData->Iopb, Data->Iopb, sizeof(FLT_IO_PARAMETER_BLOCK));

		ClearFlag(RetNewCallbackData->Iopb->IrpFlags, IRP_PAGING_IO);
		RetNewCallbackData->Iopb->Parameters.QuerySecurity.SecurityBuffer = Iopb->Parameters.QuerySecurity.SecurityBuffer;
		RetNewCallbackData->Iopb->Parameters.QuerySecurity.MdlAddress = Iopb->Parameters.QuerySecurity.MdlAddress;
		RetNewCallbackData->Iopb->Parameters.QuerySecurity.Length = Iopb->Parameters.QuerySecurity.Length;
		RetNewCallbackData->Iopb->TargetFileObject = Ccb->StreamFileInfo.StreamObject;
		RetNewCallbackData->Iopb->Parameters.QuerySecurity.SecurityInformation =
			Iopb->Parameters.QuerySecurity.SecurityInformation;

		FltPerformSynchronousIo(RetNewCallbackData);

		Status = RetNewCallbackData->IoStatus.Status;

	}
	if (!NT_SUCCESS(Status))
	{
                log()
	}

	FltReleaseContext(volCtx);

Thanks!

4

MUP is probably building the MDL and no one is freeing it. Are you missing a call to FltFreeCallbackData?

5

My problem has been solved. It is because of the lack of call of the FltFreeCallbackData function that the mdl cannot be released.
Thanks again for the guidance

1 Like
6

Glad that fixed it! Probably only showed up on the network because locally the request is (effectively) always handled synchronously.

Also a good reminder to test unloading your minifilter. You would have gotten a hang (even in the local case) that would be VERY easy to debug with Driver Verifier enabled..

7

I once tried Driver Verifier, but due to another problem, FltPerformAsynchronousIo was called under an inappropriate IRQL, resulting in frequent verification exceptions, but there was no problem with the program running, so I gave up on I/O Verification. It seems This is a very serious problem.
At the same time, I don't have any experience in dealing with minifilters working on mup file systems. All attention turns to Oplock and windows caching mechanism, which directly leads to the inability to solve this problem.

Thanks again for your guidance

8

You definitely need to go back and fix whatever problems Verifier was reporting. These are real bugs that you need to fix.

9

I have now started trying to do this, although some issues currently appear to be normal when running

After I enable Driver Verifier, a problem occurred in a place that used to work normally.

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault).  The first number in the
BugCheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
        use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
        use .trap on that value
Else
        .trap on the appropriate frame will show where the trap was taken
        (on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: ffff91013d7f8e70
Arg3: fffffb8902366000
Arg4: fffff80518c43742

BUGCHECK_CODE:  7f

BUGCHECK_P1: 8

BUGCHECK_P2: ffff91013d7f8e70

BUGCHECK_P3: fffffb8902366000

BUGCHECK_P4: fffff80518c43742

PROCESS_NAME:  wpp.exe

SYMBOL_NAME:  rdbss!RxCeAllocateIrpWithMDL+2e

MODULE_NAME: rdbss

IMAGE_NAME:  rdbss.sys

STACK_COMMAND:  .cxr; .ecxr ; kb

BUCKET_ID_FUNC_OFFSET:  2e

FAILURE_BUCKET_ID:  0x7f_8_VRF_rdbss!RxCeAllocateIrpWithMDL

OS_VERSION:  10.0.19041.1

BUILDLAB_STR:  vb_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {a423536c-42c7-78a9-8cd3-3c9284979ad4}


It is obvious that there is a problem with rdbss. This problem does not exist on the local file system, and it does not appear even if Driver verifier is not enabled.


1: kd> k
 # Child-SP          RetAddr               Call Site
00 ffff9101`3d7f8578 fffff805`18f29e12     nt!DbgBreakPointWithStatus
01 ffff9101`3d7f8580 fffff805`18f293f6     nt!KiBugCheckDebugBreak+0x12
02 ffff9101`3d7f85e0 fffff805`18e0ebf7     nt!KeBugCheck2+0x946
03 ffff9101`3d7f8cf0 fffff805`18e233a9     nt!KeBugCheckEx+0x107
04 ffff9101`3d7f8d30 fffff805`18e1d852     nt!KiBugCheckDispatch+0x69
05 ffff9101`3d7f8e70 fffff805`18c43742     nt!KiDoubleFaultAbort+0x2d2
06 fffffb89`02366000 fffff805`18c420a5     nt!RtlRbRemoveNode+0x2
07 fffffb89`02366010 fffff805`18c41e8a     nt!RtlpHpVsChunkSplit+0x45
08 fffffb89`023660d0 fffff805`18c3fdb8     nt!RtlpHpVsContextAllocateInternal+0x1fa
09 fffffb89`02366130 fffff805`18c3f4ff     nt!ExAllocateHeapPool+0x888
0a fffffb89`02366270 fffff805`18c3f470     nt!ExpAllocatePoolWithTagFromNode+0x5f
0b fffffb89`023662c0 fffff805`193e879d     nt!ExAllocatePoolWithTagPriority+0x70
0c fffffb89`02366300 fffff805`193e57af     nt!VeAllocatePoolWithTagPriority+0x1cd
0d fffffb89`02366370 fffff805`193d87ff     nt!ViIrpAllocateLockedPacket+0x5f
0e fffffb89`023663c0 fffff805`18e622a5     nt!IovAllocateIrp+0x5f
0f fffffb89`02366410 fffff80d`25024c6e     nt!IoAllocateIrp+0x19d8e5
10 fffffb89`02366440 fffff80d`26bfc0d6     rdbss!RxCeAllocateIrpWithMDL+0x2e
11 fffffb89`02366470 fffff80d`26c50222     mrxsmb!SmbWskSend+0x46
12 fffffb89`023664f0 fffff80d`26c50115     mrxsmb!RxCeSend+0xd2
13 fffffb89`02366620 fffff80d`26bfad49     mrxsmb!VctSend+0x65
14 fffffb89`02366680 fffff80d`26c97bd6     mrxsmb!SmbCseSubmitBufferContext+0xab9
15 fffffb89`023667c0 fffff80d`26bfba0a     mrxsmb20!Smb2Read_Start+0x1c6
16 fffffb89`02366890 fffff80d`26ccd44a     mrxsmb!SmbCeInitiateExchange+0xaaa
17 fffffb89`02366970 fffff80d`26c06785     mrxsmb20!MRxSmb2Read+0x13a
18 fffffb89`023669d0 fffff80d`250b32a4     mrxsmb!SmbShellRead+0x25
19 fffffb89`02366a00 fffff80d`25068de9     csc!CscRead+0x9b4
1a fffffb89`02366b50 fffff80d`2506400e     rdbss!RxLowIoSubmit+0x189
1b fffffb89`02366bc0 fffff80d`25023356     rdbss!RxCommonRead+0x5ce
1c fffffb89`02366d40 fffff80d`250619b6     rdbss!RxFsdCommonDispatch+0x626
1d fffffb89`02366ed0 fffff80d`26c4fabb     rdbss!RxFsdDispatch+0x86
1e fffffb89`02366f20 fffff805`18d81837     mrxsmb!MRxSmbFsdDispatch+0xfb
1f fffffb89`02366f60 fffff805`193d8f1a     nt!IopfCallDriver+0x53
20 fffffb89`02366fa0 fffff805`18e3b827     nt!IovCallDriver+0x266
21 fffffb89`02366fe0 fffff805`1b37f243     nt!IofCallDriver+0x1fd047
22 fffffb89`02367020 fffff805`1b37ed99     mup!MupiCallUncProvider+0xb3
23 fffffb89`02367090 fffff805`1b37ecce     mup!MupStateMachine+0x59
24 fffffb89`023670c0 fffff805`18d81837     mup!MupFsdIrpPassThrough+0x17e
25 fffffb89`02367130 fffff805`193d8f1a     nt!IopfCallDriver+0x53
26 fffffb89`02367170 fffff805`18e3b827     nt!IovCallDriver+0x266
27 fffffb89`023671b0 fffff805`19d2710a     nt!IofCallDriver+0x1fd047
28 fffffb89`023671f0 fffff805`19d24a43     FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x28a
29 fffffb89`02367260 fffff805`18d81837     FLTMGR!FltpDispatch+0xa3
2a fffffb89`023672c0 fffff805`193d8f1a     nt!IopfCallDriver+0x53
2b fffffb89`02367300 fffff805`18e3b827     nt!IovCallDriver+0x266
2c fffffb89`02367340 fffff805`18caac17     nt!IofCallDriver+0x1fd047
2d fffffb89`02367380 fffff805`18caaa34     nt!IoPageReadEx+0x1d7
2e fffffb89`023673f0 fffff805`19059edd     nt!MiPageRead+0x28
2f fffffb89`02367440 fffff805`19059751     nt!MiPfExecuteReadList+0xf9
30 fffffb89`023674b0 fffff805`18c7bd83     nt!MmPrefetchForCacheManager+0xe5
31 fffffb89`02367510 fffff805`19057ef0     nt!CcFetchDataForRead+0xf3
32 fffffb89`02367570 fffff805`18c7bab9     nt!CcMapAndCopyFromCache+0xe0
33 fffffb89`02367610 fffff805`1911dfd3     nt!CcCopyReadEx+0x139
34 fffffb89`023676c0 fffff80d`25064bcb     nt!CcCopyRead+0x23
35 fffffb89`02367710 fffff80d`25023356     rdbss!RxCommonRead+0x118b
36 fffffb89`02367890 fffff80d`250619b6     rdbss!RxFsdCommonDispatch+0x626
37 fffffb89`02367a20 fffff80d`26c4fabb     rdbss!RxFsdDispatch+0x86
38 fffffb89`02367a70 fffff805`18d81837     mrxsmb!MRxSmbFsdDispatch+0xfb
39 fffffb89`02367ab0 fffff805`193d8f1a     nt!IopfCallDriver+0x53
3a fffffb89`02367af0 fffff805`18e3b827     nt!IovCallDriver+0x266
3b fffffb89`02367b30 fffff805`1b37f243     nt!IofCallDriver+0x1fd047
3c fffffb89`02367b70 fffff805`1b37ed99     mup!MupiCallUncProvider+0xb3
3d fffffb89`02367be0 fffff805`1b37ecce     mup!MupStateMachine+0x59
3e fffffb89`02367c10 fffff805`18d81837     mup!MupFsdIrpPassThrough+0x17e
3f fffffb89`02367c80 fffff805`193d8f1a     nt!IopfCallDriver+0x53
40 fffffb89`02367cc0 fffff805`18e3b827     nt!IovCallDriver+0x266
41 fffffb89`02367d00 fffff805`19d2710a     nt!IofCallDriver+0x1fd047
42 fffffb89`02367d40 fffff805`19d2879d     FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x28a
43 fffffb89`02367db0 fffff805`19d2f3ce     FLTMGR!FltPerformSynchronousIo+0x3dd
44 fffffb89`02367e60 fffff805`19d21111     FLTMGR!FltReadFileEx+0xe2ae
45 fffffb89`02367f60 fffff805`19d7e35b     FLTMGR!FltReadFile+0x51
46 fffffb89`02367fd0 fffff80d`24689bd8     FLTMGR!FltvReadFile+0xab
47 fffffb89`02368040 fffff80d`24685b69     fltDrv!CreatedFileHeaderInfo+0x408 [D:\sandboxTmp\core\drv\FileOperater\Data.c @ 1343] 

1: kd> dv
     IrpContext = 0xffffda83`18cb6a30
      nProcType = 0
         nMajor = 0xffffda83
           fkey = unsigned char [16] "`???"
       pHeadBuf = 0xffffc70f`c6c80000 "H"
     image_name = wchar_t [260] "wpp.exe"
           dkey = unsigned char [16] "???"
     EncryptKey = struct SM4_KEY
           vSec = char [128] ""
      file_uuid = {023691C0-FB89-FFFF-B0F8-B01805F8FFFF}
        nDistro = 0x27f
           vkey = unsigned char [16] ""
        vSecLen = 0xe1f6d90
         nMinor = 0x13930a20
     FileObject = 0xffffda83`16a70430 "\192.168.10.141\test\~tmp171655774460466774.TMP" - Device for "\FileSystem\Mup"
       pTempBox = 0xffffda83`127fdaa0
            hdr = struct _tagCryptHdr
        dSecLen = 0xffffda83
           pbuf = 0xfffffb89`02368c40 ""
         status = 0n0
         Status = 0n0
     ByteOffset = {0}
           dSec = char [128] ""

When the problem occurred, a remote temporary file was being read. Since there was no problem with the local file, I think the reading logic should be correct. However, I don't know what special processing is required in the remote file system.

if (IrpContext->CreateInfo.FileSize.QuadPart >= FILE_HEADER_LENGTH) //if file is encrypted ,length must greate than file head length
{

	if (FileObject->ReadAccess)
	{
		//read encrypt file data
		Status = FltReadFile(                   <--------crash at here
			IrpContext->FltObjects.Instance,
			FileObject,
			&ByteOffset,
			FILE_HEADER_LENGTH,
			pHeadBuf,
			FLTFL_IO_OPERATION_DO_NOT_UPDATE_BYTE_OFFSET, //
			NULL,
			NULL,
			NULL
		);

	}

Is this problem related to the way the smb file is opened or to the cache?

10

That's a stack overflow from a busy stack. Verifier is definitely contributing, but you cut off the start of the stack so not sure what's using up the start of it. Two things:

  1. Make sure you don't have any large buffers on the stack
  2. You might need to end up using KeExpandKernelStackAndCalloutEx for your FltReadFile call. This will guarantee a minimum amount of stack space is available.
11

Thank you very much for your guidance. I have found my problem, which is what you said. This problem is beyond the scope of my knowledge. With your information, I have solved the problem.

1 Like
12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.