Sometimes function FltGetFileContext is crashed with bsod. FltGetFileContext is called also in pre-write and pre-cleanup callbacks. But I didn’t observe crashes here.
You haven’t supplied enough information (like what does analyze -v or given enough stack, but I’d SWAG that IRQL is an issue and your context is paged.
Ok. Crash analyze in attached file.
Context in allocated in nonpaged pool.
`PFLT_CONTEXT fctx = NULL;
status = FltAllocateContext(g_data.Filter, FLT_FILE_CONTEXT, sizeof(UINT64), NonPagedPool, &fctx);
if (NT_SUCCESS(status) && (fctx != NULL))
{ ((ULONG64)fctx) = uid++;
status = FltSetFileContext(FltObjects->Instance, FltObjects->FileObject, FLT_SET_CONTEXT_REPLACE_IF_EXISTS, fctx,
if (!NT_SUCCESS(
This looks like something very weird in DPC chaining (since when did FsRtlAcquireToCreateMappedSection provoke a IO completion?).
I’m much happier at low IRQL so perhaps some of the more device oriented readers can help because from where I’m sitting this makes your driver look like attritional damage.
FltGetFileContext requires IRQL < DISPATCH_LEVEL but your PostRead can run at IRQL <= DISPATCH_LEVEL. If you need your file context in Post you need to get it in Pre and pass it via your completion context.
@“Scott_Noone_(OSR)” said:
FltGetFileContext requires IRQL < DISPATCH_LEVEL but your PostRead can run at IRQL <= DISPATCH_LEVEL. If you need your file context in Post you need to get it in Pre and pass it via your completion context.
Thank you Scott,
This is the root of problem.
But there is a question about FltGetFileNameInformation. It can be call from same level. But it works well in post create callback. What the difference between IRP_IMJ_CREATE and
IRP_IMJ_READ regarding level?
The documentation does a poor job clarifying IRQL rules around Pre/Post operation callbacks. Documenting this is on my prioritized list of things to do (which is around here someplace…I think the last time I saw it was March :)).
FltMgr guarantees that PostCreate will be called at PASSIVE_LEVEL and in the same context as PreCreate. The documentation confirms that here:
Post-create callback routines are called at IRQL = PASSIVE_LEVEL, in the context of the thread that originated the IRP_MJ_CREATE operation.
No such guarantee is made for PostRead/PostWrite (which are the ones most likely to execute at IRQL DISPATCH_LEVEL).