0x8e error when using FltAllocateContext in PostCreate

NTFSD
1

I’m trying to pass the file length from postcreate to preread.
Here is my source codes:

This is a part of PostCreate in SwapBuffer minifilter that i added to

/******************************************************/
FltQueryInformationFile(
FltObjects->Instance,
Data->Iopb->TargetFileObject,
&fileStandardInformation,
sizeof(FILE_STANDARD_INFORMATION),
FileStandardInformation,
&returnedLength
);

status = FltAllocateContext( gFilterHandle,
FLT_STREAMHANDLE_CONTEXT,
sizeof(FILE_STREAM_HANDLE_CONTEXT),
PagedPool,
&fileContext );

fileContext->FileLength = fileStandardInformation.AllocationSize;

(VOID) FltSetStreamHandleContext( FltObjects->Instance,
FltObjects->FileObject,
FLT_SET_CONTEXT_REPLACE_IF_EXISTS,
fileContext,
NULL );

FltReleaseContext( fileContext );

/******************************************************/

When I start the minifilter, the BSOD appears with the 0x8e bugcheck. And i regconized that it had error at the FltAllocateContext.
Can anyone help me?
Thanks a lot.

2

Could you please post the !analyze -v output ?

I’d also like to make a couple of suggestions. Since you got the status that FltAllocateContext() returns it would be a good idea to check that status before proceeding to touch the fileContext because if it failed you mustn’t do that. Also in general the preferred approach when allocating contexts is that allocation is done in the preOp and the allocated context is passed through the CompletionContext parameter to the postOp callback. This is useful because FltAllocateContext() can fail and if it does fail the filter might want to fail the whole operation, which it can do during the preOp but not during the postOp (the file system has seen the operation and the file might not be able to undo the whatever the operation did in the file system). For example for IRP_MJ_CREATEs you might have delete-on-close or overwrites and supersedes which your filter can’t undo in postCreate.

Thanks,
Alex.

3

Hi all!
I just wonder if the whole create operation failed, would FltSetStreamHandleContext succeed? (it doesn?t make sense)
Also, could the FO at PostCreate be problematic? (Stacked FO)
Finally, AFAIK allocating the context from PagedPool is OK because this is PostCreate, but doing so from any other PostOperation would be wrong, wouldn?t it?

Thank you!, Santi

4

If the create failed then any attempt to set a StreamHandle, Stream or File context would fail because, well, there is no stream. Please note that even in some cases where NT_SUCCESS(status) is true the create still isn’t successful (STATUS_REPARSE)…

Stack FO shouldn’t matter because the mechanism used by FltMgr to attach contexts isn’t actually using the FILE_OBJECT itself but rather the FSRTL_ADVANCED_FCB_HEADER so as long as the FO is linked to a stream in the FS (FO->FsContext != NULL) then contexts will work.

In terms of paged vs. non-paged pool, there are other factors to consider, for example it’s possible that the preOp returned FLT_PREOP_SYNCHRONIZE and so the postOp callback is called in the same context as the preOp.

Thanks,
Alex.

5

Thanks a lot, Alex, Santi.
Here is my analyze -v

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

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but …
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 9659c196, The address that the exception occurred at
Arg3: 990238cc, Trap Frame
Arg4: 00000000

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP:
SwapBuffers+1196
9659c196 8908 mov dword ptr [eax],ecx

TRAP_FRAME: 990238cc – (.trap 0xffffffff990238cc)
ErrCode = 00000002
eax=00000000 ebx=81e0be40 ecx=00010000 edx=823a1008 esi=81e0be98 edi=81e0bde0
eip=9659c196 esp=99023940 ebp=99023968 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
SwapBuffers+0x1196:
9659c196 8908 mov dword ptr [eax],ecx ds:0023:00000000=???
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: sc.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 86e56324 to 9659c196

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
99023968 86e56324 81e0be40 9902398c 00000000 SwapBuffers+0x1196
990239d0 86e59512 00e0bde0 81e0bde0 1000000c fltmgr!FltpPerformPostCallbacks+0x24a
990239e4 86e59b46 81e0bde0 822377a8 99023a24 fltmgr!FltpProcessIoCompletion+0x10
990239f4 86e5a29c 85057688 822377a8 81e0bde0 fltmgr!FltpPassThroughCompletion+0x98
99023a24 86e6d8c9 99023a44 00000000 00000000 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x33a
99023a70 828794bc 85057688 85071008 8210942c fltmgr!FltpCreate+0x2db
99023a88 82a7d62d a3c6fda6 99023c30 00000000 nt!IofCallDriver+0x63
99023b60 82a5e1d7 8501eb98 85401d20 820ed2f0 nt!IopParseDevice+0xed7
99023bdc 82a8424d 00000000 99023c30 00000040 nt!ObpLookupObjectName+0x4fa
99023c38 82a7c5ab 000bf264 84401d20 00000001 nt!ObOpenObjectByName+0x159
99023cb4 82a87eb6 000bf2a8 80100080 000bf264 nt!IopCreateFile+0x673
99023d00 8288042a 000bf2a8 80100080 000bf264 nt!NtCreateFile+0x34
99023d00 77c764f4 000bf2a8 80100080 000bf264 nt!KiFastCallEntry+0x12a
000bf244 00000000 00000000 00000000 00000000 0x77c764f4

STACK_COMMAND: kb

FOLLOWUP_IP:
SwapBuffers+1196
9659c196 8908 mov dword ptr [eax],ecx

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: SwapBuffers+1196

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: SwapBuffers

IMAGE_NAME: SwapBuffers.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4f32b57e

FAILURE_BUCKET_ID: 0x8E_SwapBuffers+1196

BUCKET_ID: 0x8E_SwapBuffers+1196

Followup: MachineOwner

I’m thinking about your approach, Alex.
Thanks.

6

Still having trouble…
Anyone help me please…

7

Hi! (please note I am newbie, but had a similar problem)
Did you check FltAllocateContext returns STATUS_SUCCESS as Alex told you? If it fails, fileContext would be wrong and so would be fileContext->FileLength = fileStandardInformation.AllocationSize;
Also I think you should especially check FltQueryInformationFile() doesn?t fail either.
(Finally I would try to load the symbols of your driver because that would give more info in the stack trace)

I hope I am not too wrong.

8

I’m glad you’re considering my approach, but I would like to point out that checking the status was not a suggestion, it simply must be done.

Thanks,
Alex.