Minifilter bsod(KERNEL_AUTO_BOOST_LOCK_ACQUISITION_WITH_RAISED_IRQL)

Hello everyone. Fisrlt Happy new year all of users :smile:
I have minifilter which has 4 callback routine. (IRP_MJ_CREATE[Pre,Post], IRP_MJ_WRITE[Post], IRP_MJ_CLEANUP[Post] )
1.In PreCreate operation i check is callback routine called by usermode app(which communicated with filter) if yes I return FLT_PREOP_SUCCESS_NO_CALLBACK
else return FLT_PREOP_SUCCESS_WITH_CALLBACK.
2.In PostCreate operation I check is file created with write access if yes then I check file extensions(i need catch only *.exe) if yes i create stream handle context(FlltAllocateContext) and copy filepath to stream context(FileSetSetramHandleContext) and return FLT_POSTOP_FINISHED_PROCESSING;
3.in PostWrite operation if operation has stream handle context i get it and change Context->ReScan value to True like scanner sample(for scan filename in IRP_MJ_CLOSE[Post]) and release context and return FLT_POSTOP_FINISHED_PROCESSING.
4.in PostCleanup i get context if it yes and copy filename to notification structure and call FltSendMessage (to send filename usermode to scan file).

It works well but today i get bsdo with code(192) KERNEL_AUTO_BOOST_LOCK_ACQUISITION_WITH_RAISED_IRQL.
Then i try some of tips like in my post callback functions i add simple code

KIRQL irql = { 0 };
irql = KeGetCurrentIrql();
if (irql >= DISPATCH_LEVEL)
{
DbgPrint(“Called Write Dispatch Levelde <=\n”);
}

sometimes i see this message in debug windows but there is not bsod.
My PostWriteCode:

FLT_POSTOP_CALLBACK_STATUS ScannerPostWrite(PFLT_CALLBACK_DATA Data,
	PCFLT_RELATED_OBJECTS FltObjects,
	PVOID CompletionContext,
	FLT_POST_OPERATION_FLAGS Flags)
{

	NTSTATUS status;
	PSCANNER_CONTEXT scannerContext = NULL;
	POBJECT_NAME_INFORMATION name = NULL;

	KIRQL irql = { 0 };
	irql = KeGetCurrentIrql();
	if (irql >= DISPATCH_LEVEL)
	{
		DbgPrint("Write Dispatch Levelde cagrildi\n");
	}

	status = FltGetStreamHandleContext(FltObjects->Instance, FltObjects->FileObject, &scannerContext);
	if (NT_SUCCESS(status))
	{
		if (scannerContext->Rescan == FALSE)
		{
			scannerContext->Rescan = TRUE;
			FltSetStreamHandleContext(FltObjects->Instance, FltObjects->FileObject, FLT_SET_CONTEXT_REPLACE_IF_EXISTS, scannerContext, NULL);
			FltReleaseContext(scannerContext);
			/*ExFreePoolWithTag(notification, 'X66');*/
			return FLT_POSTOP_FINISHED_PROCESSING;
		}
		FltReleaseContext(scannerContext);
	}
	return FLT_POSTOP_FINISHED_PROCESSING;
}

and analyze -v result:

KERNEL_AUTO_BOOST_LOCK_ACQUISITION_WITH_RAISED_IRQL (192)
A lock tracked by AutoBoost was acquired while executing at DISPATCH_LEVEL or
above.
Arguments:
Arg1: ffffc48b269b5080, The address of the thread.
Arg2: ffffb40979dce1b8, The lock address.
Arg3: 0000000000000002, The IRQL at which the lock was acquired.
Arg4: 0000000000000000, Reserved.

PROCESS_NAME: svchost.exe

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from fffff807508c72a2 to fffff807507e6f30

STACK_TEXT:
fffff8075326d698 fffff807508c72a2 : ffffc48b269b5080 0000000000000003 fffff8075326d800 fffff8075073bb10 : nt!DbgBreakPointWithStatus
fffff8075326d6a0 fffff807508c6992 : 0000000000000003 fffff8075326d800 fffff807507f3760 0000000000000192 : nt!KiBugCheckDebugBreak+0x12
fffff8075326d700 fffff807507df1a7 : ffffc48b286be49c fffff8075326def0 ffffc48b269b5080 fffff807507e6f55 : nt!KeBugCheck2+0x952
fffff8075326de00 fffff80750657df7 : 0000000000000192 ffffc48b269b5080 ffffb40979dce1b8 0000000000000002 : nt!KeBugCheckEx+0x107
fffff8075326de40 fffff80750657146 : ffffb40979dce170 0a69646c00000000 0000000000000000 ffffc48b214e5460 : nt!ExAcquirePushLockSharedEx+0x147
fffff8075326de80 fffff80751717c97 : ffffc48b2bbb8a50 ffffc48b234ce2b0 ffffc48b214e5460 fffff8075073bbef : nt!FsRtlLookupPerStreamContextInternal+0x46
fffff8075326deb0 fffff80751717b09 : ffffc48b214e5460 fffff8075176d809 ffffc48b26ca0201 ffffc48b273e0001 : FLTMGR!FltpGetStreamListCtrl+0x67
fffff8075326df20 fffff8075176f6b8 : 0000000000000000 ffffc48b26ca0010 fffff8075326dfd8 00007ffffffeff01 : FLTMGR!FltGetStreamHandleContext+0x29
fffff8075326df60 fffff8074feb1255 : ffffc48b270874e0 fffff8075326e0b0 ffffc48b26ca001a 0000000000000000 : FLTMGR!FltvGetStreamHandleContext+0x38
fffff8075326df90 fffff8075176fc95 : 0000000000000000 0000000000000000 ffffc48b273e00f8 fffff80752261239 : FsFilter4!ScannerPostWrite+0x35 [D:\repos\FsFilter4\FsFilter4\SCANNER.c @ 246]
fffff8075326dfd0 fffff80751713c03 : ffffc48b00000000 0000000000000002 0000000000000000 0000000000000000 : FLTMGR!FltvPostOperation+0xb5
fffff8075326e060 fffff80751713408 : 0000000000000000 fffff8075326e100 0000000000000000 ffffc48b2224ea70 : FLTMGR!FltpPerformPostCallbacks+0x3e3
fffff8075326e130 fffff807517130ac : 0000000000000000 ffffc48b21281d60 ffffc48b22144350 fffff807517130a0 : FLTMGR!FltpPassThroughCompletionWorker+0x128
fffff8075326e1b0 fffff80750f819d4 : fffff807517130a0 ffffc48b27db2b80 fffff8075326e3a8 ffffc48b27db2f20 : FLTMGR!FltpPassThroughCompletion+0xc

FOLLOWUP_IP:
FsFilter4!ScannerPostWrite+35 [D:\repos\FsFilter4\FsFilter4\SCANNER.c @ 246]
fffff807`4feb1255 85c0 test eax,eax

FAULTING_SOURCE_CODE:
242:
243:
244:
245: status = FltGetStreamHandleContext(FltObjects->Instance, FltObjects->FileObject, &scannerContext);

246: if (NT_SUCCESS(status))
247: {
248:
249: if (scannerContext->Rescan == FALSE)
250: {
251: scannerContext->Rescan = TRUE;

So what is problem?I readed document and it say its not secure call some kernel function inside post callback routine but sometimes it works well sometimes not why?Can I use FltDoCompletionProcessingWhenSafe ?if yes where? like in postWrite operation i call only FltDoCompletionProcessingWhenSafe to my original callbackroutine?

FltGetStreamHandleContext can’t be call at DISPATCH_LEVEL see https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/fltkernel/nf-fltkernel-fltgetstreamhandlecontext

1 Like

@Don_Burn said:
FltGetStreamHandleContext can’t be call at DISPATCH_LEVEL see https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/fltkernel/nf-fltkernel-fltgetstreamhandlecontext

Thank you Mr Burn. Can i call FltDoCompletionProcessingWhenSafe ?

The problem with that is the IRP_MJ_WRITE call which as the documentation for FltDoCompletionProcessingWhenSafe https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/fltkernel/nf-fltkernel-fltdocompletionprocessingwhensafe may have problems.

Why can’t you use the CompleteContext from the PreXXX calls to get the context data you need for the PostXXX calls?

Because of i want to prevent multiple callback with same filename)) Thank you very much I will try it ASAP.