FLTMGR_FILE_SYSTEM BSoD

Mikae · January 14, 2014, 10:41am

Hello all.

Crossposting from NTDEV (http://www.osronline.com/showthread.cfm?link=252446)

I have a simple file minifilter that tracks access to files. I need to associate a context with every opened file. It looks that stream context is what I look for.

In PostCreate I either get the context or allocate it. I don't call FltReleaseContext since the context may be used later on while the file is opened.

In PostWrite operation I call FltGetStreamContext paired with FltReleaseContext.

In PreClose I call FltGetStreamContext. Common sense says that there should be two calls to FltReleaseContext: one for PostCreate reference and one for PreClose.

PreClose routine causes BSoD:

1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

FLTMGR_FILE_SYSTEM (f5)
An unrecoverable failure occured inside the filter manager.
Arguments:
Arg1: 000000000000006d, The reason for the failure
Arg2: fffffa80035e8330
Arg3: fffffa80035e82d0
Arg4: 0000000000000000

Debugging Details:

OVERLAPPED_MODULE: Address regions for 'dump_LSI_SAS' and 'crashdmp.sys' overlap

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0xF5

PROCESS_NAME: System

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from fffff800029b7d92 to fffff800028c8490

STACK_TEXT:
fffff880031e0828 fffff800029b7d92 : 000000000000006d fffffa8000cb0680
0000000000000065 fffff8000290c178 : nt!RtlpBreakWithStatusInstruction
fffff880031e0830 fffff800029b8b7e : fffffa8000000003 0000000000000000
fffff8000290c9d0 00000000000000f5 : nt!KiBugCheckDebugBreak+0x12
fffff880031e0890 fffff800028d0744 : fffffa8000000000 fffffa80035e82e8
fffffa80035e82d0 fffffa80035e82e8 : nt!KeBugCheck2+0x71e
fffff880031e0f60 fffff8800110633d : 00000000000000f5 000000000000006d
fffffa80035e8330 fffffa80035e82d0 : nt!KeBugCheckEx+0x104
fffff880031e0fa0 fffff88001001960 : fffffa80035e8350 0000000000000000
fffffa8001d5a2b0 0000000000000052 : fltmgr! ?? ::FNODOBFM::string'+0x1309 fffff880031e0fe0 fffff88001100067 : fffffa8002d2b240 fffff880031e1098 fffff880031e1070 fffffa8000680727 : Monitor!PreOpClose+0x70 [filemon.c @ 865] fffff880031e1020 fffff88001101329 : fffff880031e1100 00001f8000000002 fffffa80035e8d00 fffff8a000001800 : fltmgr!FltpPerformPreCallbacks+0x2f7 fffff880031e1120 fffff880010ff6c7 : fffffa8002d13010 fffffa8001d5a2b0 fffffa8001c1b8c0 0000000000000000 : fltmgr!FltpPassThrough+0x2d9 fffff880031e11a0 fffff80002bcc88e : fffffa80035e8de0 fffffa8001d20270 fffffa8000c9e9e0 fffffa8001d5a2b0 : fltmgr!FltpDispatch+0xb7 fffff880031e1200 fffff800028da514 : 00000000000000b0 fffffa8000c9e9e0 fffffa8000cbdde0 fffff800028cbe70 : nt!IopDeleteFile+0x11e fffff880031e1290 fffff80002bc7484 : fffffa8000c9e9e0 0000000000000000 fffffa8000cb0680 0000000000000000 : nt!ObfDereferenceObject+0xd4 fffff880031e12f0 fffff80002bc7a34 : 000000000000041c fffffa8000c9e9e0 fffff8a000001850 000000000000041c : nt!ObpCloseHandleTableEntry+0xc4 fffff880031e1380 fffff800028cf8d3 : fffffa8000cb0680 fffff880031e1450 0000000000000000 0000000000000001 : nt!ObpCloseHandle+0x94 fffff880031e13d0 fffff800028cbe70 : fffff880022b2f93 fffff8a001d9b318 0000000000000000 fffff8a001d9b318 : nt!KiSystemServiceCopyEnd+0x13 fffff880031e1568 fffff880022b2f93 : fffff8a001d9b318 0000000000000000 fffff8a001d9b318 fffff8a001d9dab8 : nt!KiServiceLinkage fffff880031e1570 fffff880022be161 : fffff880022aec01 0000000000000001 fffff88000000002 fffff880031e16a0 : luafv!LuafvFindTableNode+0x5c7 fffff880031e1680 fffff880022bfbbf : fffff880022ab340 0000000000000001 0000000000000001 0000000000000000 : luafv!LuafvReadFileTable+0x159 fffff880031e1750 fffff880022bf631 : fffff880022ab750 fffff880022ab9b0 fffffa80035e9000 000000000000000d : luafv!LuafvReadSettings+0x3d7 fffff880031e17f0 fffff80002cb5467 : fffffa80035e3be0 0000000000000000 0000000000000000 fffffa80035e9000 : luafv!DriverEntry+0x219 fffff880031e1860 fffff80002cb5865 : fffffa80035e0510 0000000000000000 0000000000000001 0000000000000001 : nt!IopLoadDriver+0xa07 fffff880031e1b30 fffff800028daa21 : fffff80000000000 ffffffff80000420 fffff80002cb5810 0000000000000000 : nt!IopLoadUnloadDriver+0x55 fffff880031e1b70 fffff80002b6dcce : eaa0eaea9ceaea9e fffffa8000cb0680 0000000000000080 fffffa8000c9e9e0 : nt!ExpWorkerThread+0x111 fffff880031e1c00 fffff800028c1fe6 : fffff880009ea180 fffffa8000cb0680 fffffa8000cb0b60 524b1659541a625f : nt!PspSystemThreadStartup+0x5a fffff880031e1c40 0000000000000000 : fffff880031e2000 fffff880031dc000 fffff880031dfa10 00000000`00000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
Monitor!PreOpClose+70 [filemon.c @ 865]
fffff880`01001960 b801000000 mov eax,1

FAULTING_SOURCE_LINE: filemon.c

FAULTING_SOURCE_FILE: filemon.c

FAULTING_SOURCE_LINE_NUMBER: 865

FAULTING_SOURCE_CODE:
861: FltReleaseContext(pStreamContext);
862: //FltReleaseContext(pStreamContext);
863: }
864:

865: return FLT_PREOP_SUCCESS_NO_CALLBACK;
866: }
867:
868: NTSTATUS FilterUnload(IN FLT_FILTER_UNLOAD_FLAGS Flags)
869: {
870: UNREFERENCED_PARAMETER(Flags);

SYMBOL_STACK_INDEX: 5

SYMBOL_NAME: Monitor!PreOpClose+70

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Monitor

IMAGE_NAME: Monitor.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 52d4266d

FAILURE_BUCKET_ID: X64_0xF5_Monitor!PreOpClose+70

BUCKET_ID: X64_0xF5_Monitor!PreOpClose+70

Followup: MachineOwner

In the dump above I tried to dereference context only once.

What may be the problem here?

Thanks.

Dejan_Maksimovic · January 14, 2014, 10:50am

There is your problem - you are calling FltReleaseContext twice, with no
reason during Close processing!
In PostCreate you call FltSetStreamContext and call FltReleaseContext to
release a reference (you do this even if FltSetStreamContext failed,
because that would release the reference from the original
FltAllocateContext call). Do NOT call FltReleaseContext twice if
FltSetStreamContext succeeds, as in that case you are not supposed to free
the original reference.
In other operations, you call FltGetStreamContext and FltReleaseContext if
the call is successful - ONCE.

FltMgr releases the context reference from FltAllocateContext once all your
references are released, and it receives the last IRP_MJ_CLOSE for that
context. (in case of STREAMHANDLE contexts, it means IRP_MJ_CLOSE, in case
of STREAM contexts, it means the last IRP_MJ_CLOSE, since multiple
IRP_MJ_CLOSES can come for the same FILE)

This is not really explained in the documentation, it is a trial/error or
“ask experienced fellas” type of thing.

Kind regards, Dejan.

On Tue, Jan 14, 2014 at 4:41 PM, wrote:

> Hello all.
>
> Crossposting from NTDEV (
> http://www.osronline.com/showthread.cfm?link=252446)
>
> I have a simple file minifilter that tracks access to files. I need to
> associate a context with every opened file. It looks that stream context is
> what I look for.
>
> In PostCreate I either get the context or allocate it. I don’t call
> FltReleaseContext since the context may be used later on while the file is
> opened.
>
> In PostWrite operation I call FltGetStreamContext paired with
> FltReleaseContext.
>
> In PreClose I call FltGetStreamContext. Common sense says that there
> should be two calls to FltReleaseContext: one for PostCreate reference and
> one for PreClose.
>
> PreClose routine causes BSoD:
>
> 1: kd> !analyze -v
>
> *****
>
>
> * Bugcheck Analysis
>
>
>
>
>
>
> FLTMGR_FILE_SYSTEM (f5)
> An unrecoverable failure occured inside the filter manager.
> Arguments:
> Arg1: 000000000000006d, The reason for the failure
> Arg2: fffffa80035e8330
> Arg3: fffffa80035e82d0
> Arg4: 0000000000000000
>
> Debugging Details:
> ------------------
>
>
> OVERLAPPED_MODULE: Address regions for ‘dump_LSI_SAS’ and ‘crashdmp.sys’
> overlap
>
> DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
>
> BUGCHECK_STR: 0xF5
>
> PROCESS_NAME: System
>
> CURRENT_IRQL: 2
>
> LAST_CONTROL_TRANSFER: from fffff800029b7d92 to fffff800028c8490
>
> STACK_TEXT:
> fffff880031e0828 fffff800029b7d92 : 000000000000006d fffffa8000cb0680
> 0000000000000065 fffff8000290c178 : nt!RtlpBreakWithStatusInstruction
> fffff880031e0830 fffff800029b8b7e : fffffa8000000003 0000000000000000
> fffff8000290c9d0 00000000000000f5 : nt!KiBugCheckDebugBreak+0x12
> fffff880031e0890 fffff800028d0744 : fffffa8000000000 fffffa80035e82e8
> fffffa80035e82d0 fffffa80035e82e8 : nt!KeBugCheck2+0x71e
> fffff880031e0f60 fffff8800110633d : 00000000000000f5 000000000000006d
> fffffa80035e8330 fffffa80035e82d0 : nt!KeBugCheckEx+0x104
> fffff880031e0fa0 fffff88001001960 : fffffa80035e8350 0000000000000000
> fffffa8001d5a2b0 0000000000000052 : fltmgr! ??
> ::FNODOBFM::string'+0x1309 > fffff880031e0fe0 fffff88001100067 : fffffa8002d2b240 fffff880031e1098 > fffff880031e1070 fffffa8000680727 : Monitor!PreOpClose+0x70 [filemon.c @ > 865] > fffff880031e1020 fffff88001101329 : fffff880031e1100 00001f8000000002 > fffffa80035e8d00 fffff8a000001800 : fltmgr!FltpPerformPreCallbacks+0x2f7 > fffff880031e1120 fffff880010ff6c7 : fffffa8002d13010 fffffa8001d5a2b0 > fffffa8001c1b8c0 0000000000000000 : fltmgr!FltpPassThrough+0x2d9 > fffff880031e11a0 fffff80002bcc88e : fffffa80035e8de0 fffffa8001d20270 > fffffa8000c9e9e0 fffffa8001d5a2b0 : fltmgr!FltpDispatch+0xb7 > fffff880031e1200 fffff800028da514 : 00000000000000b0 fffffa8000c9e9e0 > fffffa8000cbdde0 fffff800028cbe70 : nt!IopDeleteFile+0x11e > fffff880031e1290 fffff80002bc7484 : fffffa8000c9e9e0 0000000000000000 > fffffa8000cb0680 0000000000000000 : nt!ObfDereferenceObject+0xd4 > fffff880031e12f0 fffff80002bc7a34 : 000000000000041c fffffa8000c9e9e0 > fffff8a000001850 000000000000041c : nt!ObpCloseHandleTableEntry+0xc4 > fffff880031e1380 fffff800028cf8d3 : fffffa8000cb0680 fffff880031e1450 > 0000000000000000 0000000000000001 : nt!ObpCloseHandle+0x94 > fffff880031e13d0 fffff800028cbe70 : fffff880022b2f93 fffff8a001d9b318 > 0000000000000000 fffff8a001d9b318 : nt!KiSystemServiceCopyEnd+0x13 > fffff880031e1568 fffff880022b2f93 : fffff8a001d9b318 0000000000000000 > fffff8a001d9b318 fffff8a001d9dab8 : nt!KiServiceLinkage > fffff880031e1570 fffff880022be161 : fffff880022aec01 0000000000000001 > fffff88000000002 fffff880031e16a0 : luafv!LuafvFindTableNode+0x5c7 > fffff880031e1680 fffff880022bfbbf : fffff880022ab340 0000000000000001 > 0000000000000001 0000000000000000 : luafv!LuafvReadFileTable+0x159 > fffff880031e1750 fffff880022bf631 : fffff880022ab750 fffff880022ab9b0 > fffffa80035e9000 000000000000000d : luafv!LuafvReadSettings+0x3d7 > fffff880031e17f0 fffff80002cb5467 : fffffa80035e3be0 0000000000000000 > 0000000000000000 fffffa80035e9000 : luafv!DriverEntry+0x219 > fffff880031e1860 fffff80002cb5865 : fffffa80035e0510 0000000000000000 > 0000000000000001 0000000000000001 : nt!IopLoadDriver+0xa07 > fffff880031e1b30 fffff800028daa21 : fffff80000000000 ffffffff80000420 > fffff80002cb5810 0000000000000000 : nt!IopLoadUnloadDriver+0x55 > fffff880031e1b70 fffff80002b6dcce : eaa0eaea9ceaea9e fffffa8000cb0680 > 0000000000000080 fffffa8000c9e9e0 : nt!ExpWorkerThread+0x111 > fffff880031e1c00 fffff800028c1fe6 : fffff880009ea180 fffffa8000cb0680 > fffffa8000cb0b60 524b1659541a625f : nt!PspSystemThreadStartup+0x5a > fffff880031e1c40 0000000000000000 : fffff880031e2000 fffff880031dc000 > fffff880031dfa10 0000000000000000 : nt!KiStartSystemThread+0x16 > > > STACK_COMMAND: kb > > FOLLOWUP_IP: > Monitor!PreOpClose+70 [filemon.c @ 865] > fffff88001001960 b801000000 mov eax,1
>
> FAULTING_SOURCE_LINE: filemon.c
>
> FAULTING_SOURCE_FILE: filemon.c
>
> FAULTING_SOURCE_LINE_NUMBER: 865
>
> FAULTING_SOURCE_CODE:
> 861: FltReleaseContext(pStreamContext);
> 862: //FltReleaseContext(pStreamContext);
> 863: }
> 864:
> > 865: return FLT_PREOP_SUCCESS_NO_CALLBACK;
> 866: }
> 867:
> 868: NTSTATUS FilterUnload(IN FLT_FILTER_UNLOAD_FLAGS Flags)
> 869: {
> 870: UNREFERENCED_PARAMETER(Flags);
>
>
> SYMBOL_STACK_INDEX: 5
>
> SYMBOL_NAME: Monitor!PreOpClose+70
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: Monitor
>
> IMAGE_NAME: Monitor.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 52d4266d
>
> FAILURE_BUCKET_ID: X64_0xF5_Monitor!PreOpClose+70
>
> BUCKET_ID: X64_0xF5_Monitor!PreOpClose+70
>
> Followup: MachineOwner
> ---------
>
>
> In the dump above I tried to dereference context only once.
>
> What may be the problem here?
>
> Thanks.
>
> —
> 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
>

Alex_Carp · January 14, 2014, 12:34pm

I actually have a post on how contexts work, here: http://fsfilters.blogspot.com/2010/02/context-usage-in-minifilters.html. Hope it will clarify things.

Thanks,
Alex.
On Jan 14, 2014, at 7:49 AM, Dejan Maksimovic wrote:

> There is your problem - you are calling FltReleaseContext twice, with no reason during Close processing!
> In PostCreate you call FltSetStreamContext and call FltReleaseContext to release a reference (you do this even if FltSetStreamContext failed, because that would release the reference from the original FltAllocateContext call). Do NOT call FltReleaseContext twice if FltSetStreamContext succeeds, as in that case you are not supposed to free the original reference.
> In other operations, you call FltGetStreamContext and FltReleaseContext if the call is successful - ONCE.
>
> FltMgr releases the context reference from FltAllocateContext once all your references are released, and it receives the last IRP_MJ_CLOSE for that context. (in case of STREAMHANDLE contexts, it means IRP_MJ_CLOSE, in case of STREAM contexts, it means the last IRP_MJ_CLOSE, since multiple IRP_MJ_CLOSES can come for the same FILE)
>
> This is not really explained in the documentation, it is a trial/error or “ask experienced fellas” type of thing.
>
> Kind regards, Dejan.
>
>
>
> On Tue, Jan 14, 2014 at 4:41 PM, wrote:
> Hello all.
>
> Crossposting from NTDEV (http://www.osronline.com/showthread.cfm?link=252446)
>
> I have a simple file minifilter that tracks access to files. I need to associate a context with every opened file. It looks that stream context is what I look for.
>
> In PostCreate I either get the context or allocate it. I don’t call FltReleaseContext since the context may be used later on while the file is opened.
>
> In PostWrite operation I call FltGetStreamContext paired with FltReleaseContext.
>
> In PreClose I call FltGetStreamContext. Common sense says that there should be two calls to FltReleaseContext: one for PostCreate reference and one for PreClose.
>
> PreClose routine causes BSoD:
>
> 1: kd> !analyze -v
> ***
> *
> * Bugcheck Analysis
> *
>
>
> FLTMGR_FILE_SYSTEM (f5)
> An unrecoverable failure occured inside the filter manager.
> Arguments:
> Arg1: 000000000000006d, The reason for the failure
> Arg2: fffffa80035e8330
> Arg3: fffffa80035e82d0
> Arg4: 0000000000000000
>
> Debugging Details:
> ------------------
>
>
> OVERLAPPED_MODULE: Address regions for ‘dump_LSI_SAS’ and ‘crashdmp.sys’ overlap
>
> DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
>
> BUGCHECK_STR: 0xF5
>
> PROCESS_NAME: System
>
> CURRENT_IRQL: 2
>
> LAST_CONTROL_TRANSFER: from fffff800029b7d92 to fffff800028c8490
>
> STACK_TEXT:
> fffff880031e0828 fffff800029b7d92 : 000000000000006d fffffa8000cb0680
> 0000000000000065 fffff8000290c178 : nt!RtlpBreakWithStatusInstruction
> fffff880031e0830 fffff800029b8b7e : fffffa8000000003 0000000000000000
> fffff8000290c9d0 00000000000000f5 : nt!KiBugCheckDebugBreak+0x12
> fffff880031e0890 fffff800028d0744 : fffffa8000000000 fffffa80035e82e8
> fffffa80035e82d0 fffffa80035e82e8 : nt!KeBugCheck2+0x71e
> fffff880031e0f60 fffff8800110633d : 00000000000000f5 000000000000006d
> fffffa80035e8330 fffffa80035e82d0 : nt!KeBugCheckEx+0x104
> fffff880031e0fa0 fffff88001001960 : fffffa80035e8350 0000000000000000
> fffffa8001d5a2b0 0000000000000052 : fltmgr! ?? ::FNODOBFM::string'+0x1309 > fffff880031e0fe0 fffff88001100067 : fffffa8002d2b240 fffff880031e1098 > fffff880031e1070 fffffa8000680727 : Monitor!PreOpClose+0x70 [filemon.c @ 865] > fffff880031e1020 fffff88001101329 : fffff880031e1100 00001f8000000002 > fffffa80035e8d00 fffff8a000001800 : fltmgr!FltpPerformPreCallbacks+0x2f7 > fffff880031e1120 fffff880010ff6c7 : fffffa8002d13010 fffffa8001d5a2b0 > fffffa8001c1b8c0 0000000000000000 : fltmgr!FltpPassThrough+0x2d9 > fffff880031e11a0 fffff80002bcc88e : fffffa80035e8de0 fffffa8001d20270 > fffffa8000c9e9e0 fffffa8001d5a2b0 : fltmgr!FltpDispatch+0xb7 > fffff880031e1200 fffff800028da514 : 00000000000000b0 fffffa8000c9e9e0 > fffffa8000cbdde0 fffff800028cbe70 : nt!IopDeleteFile+0x11e > fffff880031e1290 fffff80002bc7484 : fffffa8000c9e9e0 0000000000000000 > fffffa8000cb0680 0000000000000000 : nt!ObfDereferenceObject+0xd4 > fffff880031e12f0 fffff80002bc7a34 : 000000000000041c fffffa8000c9e9e0 > fffff8a000001850 000000000000041c : nt!ObpCloseHandleTableEntry+0xc4 > fffff880031e1380 fffff800028cf8d3 : fffffa8000cb0680 fffff880031e1450 > 0000000000000000 0000000000000001 : nt!ObpCloseHandle+0x94 > fffff880031e13d0 fffff800028cbe70 : fffff880022b2f93 fffff8a001d9b318 > 0000000000000000 fffff8a001d9b318 : nt!KiSystemServiceCopyEnd+0x13 > fffff880031e1568 fffff880022b2f93 : fffff8a001d9b318 0000000000000000 > fffff8a001d9b318 fffff8a001d9dab8 : nt!KiServiceLinkage > fffff880031e1570 fffff880022be161 : fffff880022aec01 0000000000000001 > fffff88000000002 fffff880031e16a0 : luafv!LuafvFindTableNode+0x5c7 > fffff880031e1680 fffff880022bfbbf : fffff880022ab340 0000000000000001 > 0000000000000001 0000000000000000 : luafv!LuafvReadFileTable+0x159 > fffff880031e1750 fffff880022bf631 : fffff880022ab750 fffff880022ab9b0 > fffffa80035e9000 000000000000000d : luafv!LuafvReadSettings+0x3d7 > fffff880031e17f0 fffff80002cb5467 : fffffa80035e3be0 0000000000000000 > 0000000000000000 fffffa80035e9000 : luafv!DriverEntry+0x219 > fffff880031e1860 fffff80002cb5865 : fffffa80035e0510 0000000000000000 > 0000000000000001 0000000000000001 : nt!IopLoadDriver+0xa07 > fffff880031e1b30 fffff800028daa21 : fffff80000000000 ffffffff80000420 > fffff80002cb5810 0000000000000000 : nt!IopLoadUnloadDriver+0x55 > fffff880031e1b70 fffff80002b6dcce : eaa0eaea9ceaea9e fffffa8000cb0680 > 0000000000000080 fffffa8000c9e9e0 : nt!ExpWorkerThread+0x111 > fffff880031e1c00 fffff800028c1fe6 : fffff880009ea180 fffffa8000cb0680 > fffffa8000cb0b60 524b1659541a625f : nt!PspSystemThreadStartup+0x5a > fffff880031e1c40 0000000000000000 : fffff880031e2000 fffff880031dc000 > fffff880031dfa10 0000000000000000 : nt!KiStartSystemThread+0x16 > > > STACK_COMMAND: kb > > FOLLOWUP_IP: > Monitor!PreOpClose+70 [filemon.c @ 865] > fffff88001001960 b801000000 mov eax,1
>
> FAULTING_SOURCE_LINE: filemon.c
>
> FAULTING_SOURCE_FILE: filemon.c
>
> FAULTING_SOURCE_LINE_NUMBER: 865
>
> FAULTING_SOURCE_CODE:
> 861: FltReleaseContext(pStreamContext);
> 862: //FltReleaseContext(pStreamContext);
> 863: }
> 864:
> > 865: return FLT_PREOP_SUCCESS_NO_CALLBACK;
> 866: }
> 867:
> 868: NTSTATUS FilterUnload(IN FLT_FILTER_UNLOAD_FLAGS Flags)
> 869: {
> 870: UNREFERENCED_PARAMETER(Flags);
>
>
> SYMBOL_STACK_INDEX: 5
>
> SYMBOL_NAME: Monitor!PreOpClose+70
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: Monitor
>
> IMAGE_NAME: Monitor.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 52d4266d
>
> FAILURE_BUCKET_ID: X64_0xF5_Monitor!PreOpClose+70
>
> BUCKET_ID: X64_0xF5_Monitor!PreOpClose+70
>
> Followup: MachineOwner
> ---------
>
>
> In the dump above I tried to dereference context only once.
>
> What may be the problem here?
>
> Thanks.
>
> —
> 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
>
> — 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

Mikae · January 19, 2014, 10:54am

Alex, thanks for the blog. It looks that I’ve figured out the bug.

http://fsfilters.blogspot.com/2012/06/flags-of-fileobjects-part-iii.html – here you mention FO_FILE_MODIFIED flag. I wanted to use the context to mark file as dirty (set to TRUE on successful MJ_WRITE operation). Now I consider to use the flag instead of context. Not sure thought how reliable is that. Some posts on OSR recommend to avoid it.

Did something change about the flag? Could I use it?

Thanks.

Mikae · January 22, 2014, 10:01am

One more bugcheck...

Call to ZwCreateSection inside PreClose leads to BlueScreen (not the call itself, it occures a bit later). Commenting out the call removes BSoD. !analyze -v:

1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

NTFS_FILE_SYSTEM (24)
If you see NtfsExceptionFilter on the stack then the 2nd and 3rd
parameters are the exception record and context record. Do a .cxr
on the 3rd parameter and then kb to obtain a more informative stack
trace.
Arguments:
Arg1: 00000000001904fb
Arg2: fffff880022c9298
Arg3: fffff880022c8af0
Arg4: fffff880012149a9

Debugging Details:

EXCEPTION_RECORD: fffff880022c9298 -- (.exr 0xfffff880022c9298)
ExceptionAddress: fffff880012149a9 (Ntfs!NtfsCleanupIrpContext+0x0000000000000119)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 0000000000000018
Attempt to read from address 0000000000000018

CONTEXT: fffff880022c8af0 -- (.cxr 0xfffff880022c8af0)
rax=0000000000000000 rbx=fffff880022c95f0 rcx=0000000000000020
rdx=0000000000000000 rsi=0000000000000001 rdi=0000000000000000
rip=fffff880012149a9 rsp=fffff880022c94d0 rbp=fffff8a0021c8b40
r8=0000000000000000 r9=0000000000000727 r10=fffff80002a15c80
r11=0000000000000000 r12=fffff880022c96a0 r13=0000000000000702
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po cy
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010247
Ntfs!NtfsCleanupIrpContext+0x119:
fffff880012149a9 488b4818 mov rcx,qword ptr [rax+18h] ds:002b:0000000000000018=????????????????
Resetting default scope

PROCESS_NAME: services.exe

CURRENT_IRQL: 2

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

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

EXCEPTION_PARAMETER1: 0000000000000000

EXCEPTION_PARAMETER2: 0000000000000018

READ_ADDRESS: 0000000000000018

FOLLOWUP_IP:
Ntfs!NtfsCleanupIrpContext+119
fffff880`012149a9 488b4818 mov rcx,qword ptr [rax+18h]

FAULTING_IP:
Ntfs!NtfsCleanupIrpContext+119
fffff880`012149a9 488b4818 mov rcx,qword ptr [rax+18h]

BUGCHECK_STR: 0x24

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER: from fffff88001215e4a to fffff880012149a9

STACK_TEXT:
fffff880022c94d0 fffff88001215e4a : fffff880022c95f0 0000000000000001 0000000000000000 fffff880022c95f0 : Ntfs!NtfsCleanupIrpContext+0x119
fffff880022c9520 fffff880012b4a04 : fffff880022c9840 fffff880022c95f0 fffffa80031ecc60 fffffa8002d34980 : Ntfs!NtfsCommonCleanupOnNewStack+0x14a
fffff880022c9590 fffff88001156bcf : fffff880022c95f0 fffffa80031ecc60 fffffa80031ecfb8 fffffa800343f810 : Ntfs!NtfsFsdCleanup+0x144
fffff880022c9800 fffff880011556df : fffffa8001d60a30 0000000000000000 fffffa8001a58800 fffffa80031ecc60 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
fffff880022c9890 fffff80002b9cf0f : fffffa80031ecc60 fffffa8002d31b30 0000000000000000 fffffa800345ce20 : fltmgr!FltpDispatch+0xcf
fffff880022c98f0 fffff80002b8c6b4 : 0000000000000000 fffffa8002d31b30 fffff880022c9b01 fffff80002898001 : nt!IopCloseFile+0x11f
fffff880022c9980 fffff80002b8c471 : fffffa8002d31b30 fffffa8000000001 fffff8a001cad290 0000000000000000 : nt!ObpDecrementHandleCount+0xb4
fffff880022c9a00 fffff80002b8ca34 : 0000000000000260 fffffa8002d31b30 fffff8a001cad290 0000000000000260 : nt!ObpCloseHandleTableEntry+0xb1
fffff880022c9a90 fffff800028948d3 : fffffa8003055910 fffff880022c9b60 0000000000000260 0000000001c2f130 : nt!ObpCloseHandle+0x94
fffff880022c9ae0 000000007791140a : 000007fefdb71863 0000000000000000 0000000000000000 0000000000000003 : nt!KiSystemServiceCopyEnd+0x13
0000000001c2e9d8 000007fefdb71863 : 0000000000000000 0000000000000000 0000000000000003 0000000000281c70 : ntdll!ZwClose+0xa
0000000001c2e9e0 00000000777c2fc1 : 00000000021a0092 0000000000281c70 0000000040000000 0000000000000030 : KERNELBASE!CloseHandle+0x13
0000000001c2ea10 000007fefc924576 : 0000000001ae90c0 0000000001c2ee10 ffffffffffffffff 0000000001ae90c0 : kernel32!CloseHandleImplementation+0x3d
0000000001c2eb20 000007fefc92fadf : 0000000001aec860 0000000000000000 0000000000000000 0000000000000000 : UBPM!UbpmStatsOperation+0x2f4
0000000001c2ede0 000007fefc92f0de : 0000000000000004 0000000001ae90c0 0000000000000001 0000000001c2eed8 : UBPM!UbpmpTriggerConsumerSaveRegistrationStats+0x122
0000000001c2ee60 000007fefc92ecb3 : 0000000000000005 000007fe00000000 0000000001c2efc0 0000000000000000 : UBPM!UbpmTriggerConsumerRegister+0x56d
0000000001c2ef70 000007fefdc123d5 : 0000000001aeb100 0000000000000005 0000000001c2eff0 0000000001c2f428 : UBPM!s_UbpmRpcRegisterTriggerConsumer+0x16a
0000000001c2efc0 000007fefdc069b2 : 0000000001c2f400 000007fefc94c9e2 0000000000000030 000007fefc94e450 : RPCRT4!Invoke+0x65
0000000001c2f030 000007fefdc0338d : 00000000ffe6fd30 0000000000197aac 0000000000000000 00000000ffe313c3 : RPCRT4!NdrStubCall2+0x32a
0000000001c2f650 000007fefdc050f4 : 0000000000000000 0000000000000001 0000000000000000 00000000019806b0 : RPCRT4!NdrServerCall2+0x1d
0000000001c2f680 000007fefdc04f56 : 0000000000000000 00000000001e1220 0000000001c2f830 0000000000000001 : RPCRT4!DispatchToStubInCNoAvrf+0x14
0000000001c2f6b0 000007fefdc05679 : 0000000000228518 000007fefdbfa9df 00000000002050a0 000000000027ef00 : RPCRT4!RPC_INTERFACE::DispatchToStubWorker+0x146
0000000001c2f7d0 000007fefdc0532d : 0000000000216c70 000000000028a8e0 000007fefdbe0000 0000000000221190 : RPCRT4!LRPC_SCALL::DispatchRequest+0x149
0000000001c2f8b0 000007fefdc22e7f : 0000000000010000 000000000021f910 0000000000000000 0000000000000001 : RPCRT4!LRPC_SCALL::HandleRequest+0x20d
0000000001c2f9e0 000007fefdc22a35 : 0000020000000000 0000000000000000 000000000021fa10 0000000000000000 : RPCRT4!LRPC_ADDRESS::ProcessIO+0x3bf
0000000001c2fb20 00000000778db68b : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : RPCRT4!LrpcIoComplete+0xa5
0000000001c2fbb0 00000000778dfeff : 0000000000000000 0000000000000000 000000000000ffff 0000000000000000 : ntdll!TppAlpcpExecuteCallback+0x26b
0000000001c2fc40 00000000777b652d : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!TppWorkerThread+0x3f8
0000000001c2ff40 00000000778ec521 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : kernel32!BaseThreadInitThunk+0xd
0000000001c2ff70 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart+0x1d

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: Ntfs!NtfsCleanupIrpContext+119

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Ntfs

IMAGE_NAME: Ntfs.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4ce792f9

STACK_COMMAND: .cxr 0xfffff880022c8af0 ; kb

FAILURE_BUCKET_ID: X64_0x24_Ntfs!NtfsCleanupIrpContext+119

BUCKET_ID: X64_0x24_Ntfs!NtfsCleanupIrpContext+119

Followup: MachineOwner

From some disassembly I see that IoGetTopLevelIrp returns NULL.

1: kd> u Ntfs!NtfsCleanupIrpContext+119-7
Ntfs!NtfsCleanupIrpContext+0x112:
fffff880012149a2 c3 ret fffff880012149a3 ff1507820300 call qword ptr [Ntfs!_imp_IoGetTopLevelIrp (fffff8800124cbb0)] fffff880012149a9 488b4818 mov rcx,qword ptr [rax+18h]
fffff880012149ad 44897804 mov dword ptr [rax+4],r15d fffff880012149b1 4c897820 mov qword ptr [rax+20h],r15
fffff880012149b5 ff154d770300 call qword ptr [Ntfs!_imp_IoSetTopLevelIrp (fffff8800124c108)]
fffff880012149bb 816308ffffefff and dword ptr [rbx+8],0FFEFFFFFh fffff880012149c2 ebbb jmp Ntfs!NtfsCleanupIrpContext+0xef (fffff880`0121497f)

Why does it happen? What do I miss? Thanks.

Peter_Scott · January 22, 2014, 11:15am

What are you passing in as the last parameter to ZwCreateSection? Are
you retrieving a handle from the file object passed into the preclose
routine?

Pete

On 1/22/2014 8:00 AM, xxxxx@yahoo.com wrote:

One more bugcheck…

Call to ZwCreateSection inside PreClose leads to BlueScreen (not the call itself, it occures a bit later). Commenting out the call removes BSoD. !analyze -v:

1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

NTFS_FILE_SYSTEM (24)
If you see NtfsExceptionFilter on the stack then the 2nd and 3rd
parameters are the exception record and context record. Do a .cxr
on the 3rd parameter and then kb to obtain a more informative stack
trace.
Arguments:
Arg1: 00000000001904fb
Arg2: fffff880022c9298
Arg3: fffff880022c8af0
Arg4: fffff880012149a9

Debugging Details:

EXCEPTION_RECORD: fffff880022c9298 – (.exr 0xfffff880022c9298)
ExceptionAddress: fffff880012149a9 (Ntfs!NtfsCleanupIrpContext+0x0000000000000119)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 0000000000000018
Attempt to read from address 0000000000000018

CONTEXT: fffff880022c8af0 – (.cxr 0xfffff880022c8af0)
rax=0000000000000000 rbx=fffff880022c95f0 rcx=0000000000000020
rdx=0000000000000000 rsi=0000000000000001 rdi=0000000000000000
rip=fffff880012149a9 rsp=fffff880022c94d0 rbp=fffff8a0021c8b40
r8=0000000000000000 r9=0000000000000727 r10=fffff80002a15c80
r11=0000000000000000 r12=fffff880022c96a0 r13=0000000000000702
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po cy
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010247
Ntfs!NtfsCleanupIrpContext+0x119:
fffff880012149a9 488b4818 mov rcx,qword ptr [rax+18h] ds:002b:0000000000000018=???
Resetting default scope

PROCESS_NAME: services.exe

CURRENT_IRQL: 2

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

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

EXCEPTION_PARAMETER1: 0000000000000000

EXCEPTION_PARAMETER2: 0000000000000018

READ_ADDRESS: 0000000000000018

FOLLOWUP_IP:
Ntfs!NtfsCleanupIrpContext+119
fffff880`012149a9 488b4818 mov rcx,qword ptr [rax+18h]

FAULTING_IP:
Ntfs!NtfsCleanupIrpContext+119
fffff880`012149a9 488b4818 mov rcx,qword ptr [rax+18h]

BUGCHECK_STR: 0x24

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER: from fffff88001215e4a to fffff880012149a9

STACK_TEXT:
fffff880022c94d0 fffff88001215e4a : fffff880022c95f0 0000000000000001 0000000000000000 fffff880022c95f0 : Ntfs!NtfsCleanupIrpContext+0x119
fffff880022c9520 fffff880012b4a04 : fffff880022c9840 fffff880022c95f0 fffffa80031ecc60 fffffa8002d34980 : Ntfs!NtfsCommonCleanupOnNewStack+0x14a
fffff880022c9590 fffff88001156bcf : fffff880022c95f0 fffffa80031ecc60 fffffa80031ecfb8 fffffa800343f810 : Ntfs!NtfsFsdCleanup+0x144
fffff880022c9800 fffff880011556df : fffffa8001d60a30 0000000000000000 fffffa8001a58800 fffffa80031ecc60 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
fffff880022c9890 fffff80002b9cf0f : fffffa80031ecc60 fffffa8002d31b30 0000000000000000 fffffa800345ce20 : fltmgr!FltpDispatch+0xcf
fffff880022c98f0 fffff80002b8c6b4 : 0000000000000000 fffffa8002d31b30 fffff880022c9b01 fffff80002898001 : nt!IopCloseFile+0x11f
fffff880022c9980 fffff80002b8c471 : fffffa8002d31b30 fffffa8000000001 fffff8a001cad290 0000000000000000 : nt!ObpDecrementHandleCount+0xb4
fffff880022c9a00 fffff80002b8ca34 : 0000000000000260 fffffa8002d31b30 fffff8a001cad290 0000000000000260 : nt!ObpCloseHandleTableEntry+0xb1
fffff880022c9a90 fffff800028948d3 : fffffa8003055910 fffff880022c9b60 0000000000000260 0000000001c2f130 : nt!ObpCloseHandle+0x94
fffff880022c9ae0 000000007791140a : 000007fefdb71863 0000000000000000 0000000000000000 0000000000000003 : nt!KiSystemServiceCopyEnd+0x13
0000000001c2e9d8 000007fefdb71863 : 0000000000000000 0000000000000000 0000000000000003 0000000000281c70 : ntdll!ZwClose+0xa
0000000001c2e9e0 00000000777c2fc1 : 00000000021a0092 0000000000281c70 0000000040000000 0000000000000030 : KERNELBASE!CloseHandle+0x13
0000000001c2ea10 000007fefc924576 : 0000000001ae90c0 0000000001c2ee10 ffffffffffffffff 0000000001ae90c0 : kernel32!CloseHandleImplementation+0x3d
0000000001c2eb20 000007fefc92fadf : 0000000001aec860 0000000000000000 0000000000000000 0000000000000000 : UBPM!UbpmStatsOperation+0x2f4
0000000001c2ede0 000007fefc92f0de : 0000000000000004 0000000001ae90c0 0000000000000001 0000000001c2eed8 : UBPM!UbpmpTriggerConsumerSaveRegistrationStats+0x122
0000000001c2ee60 000007fefc92ecb3 : 0000000000000005 000007fe00000000 0000000001c2efc0 0000000000000000 : UBPM!UbpmTriggerConsumerRegister+0x56d
0000000001c2ef70 000007fefdc123d5 : 0000000001aeb100 0000000000000005 0000000001c2eff0 0000000001c2f428 : UBPM!s_UbpmRpcRegisterTriggerConsumer+0x16a
0000000001c2efc0 000007fefdc069b2 : 0000000001c2f400 000007fefc94c9e2 0000000000000030 000007fefc94e450 : RPCRT4!Invoke+0x65
0000000001c2f030 000007fefdc0338d : 00000000ffe6fd30 0000000000197aac 0000000000000000 00000000ffe313c3 : RPCRT4!NdrStubCall2+0x32a
0000000001c2f650 000007fefdc050f4 : 0000000000000000 0000000000000001 0000000000000000 00000000019806b0 : RPCRT4!NdrServerCall2+0x1d
0000000001c2f680 000007fefdc04f56 : 0000000000000000 00000000001e1220 0000000001c2f830 0000000000000001 : RPCRT4!DispatchToStubInCNoAvrf+0x14
0000000001c2f6b0 000007fefdc05679 : 0000000000228518 000007fefdbfa9df 00000000002050a0 000000000027ef00 : RPCRT4!RPC_INTERFACE::DispatchToStubWorker+0x146
0000000001c2f7d0 000007fefdc0532d : 0000000000216c70 000000000028a8e0 000007fefdbe0000 0000000000221190 : RPCRT4!LRPC_SCALL::DispatchRequest+0x149
0000000001c2f8b0 000007fefdc22e7f : 0000000000010000 000000000021f910 0000000000000000 0000000000000001 : RPCRT4!LRPC_SCALL::HandleRequest+0x20d
0000000001c2f9e0 000007fefdc22a35 : 0000020000000000 0000000000000000 000000000021fa10 0000000000000000 : RPCRT4!LRPC_ADDRESS::ProcessIO+0x3bf
0000000001c2fb20 00000000778db68b : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : RPCRT4!LrpcIoComplete+0xa5
0000000001c2fbb0 00000000778dfeff : 0000000000000000 0000000000000000 000000000000ffff 0000000000000000 : ntdll!TppAlpcpExecuteCallback+0x26b
0000000001c2fc40 00000000777b652d : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!TppWorkerThread+0x3f8
0000000001c2ff40 00000000778ec521 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : kernel32!BaseThreadInitThunk+0xd
0000000001c2ff70 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart+0x1d

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: Ntfs!NtfsCleanupIrpContext+119

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Ntfs

IMAGE_NAME: Ntfs.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4ce792f9

STACK_COMMAND: .cxr 0xfffff880022c8af0 ; kb

FAILURE_BUCKET_ID: X64_0x24_Ntfs!NtfsCleanupIrpContext+119

BUCKET_ID: X64_0x24_Ntfs!NtfsCleanupIrpContext+119

Followup: MachineOwner

From some disassembly I see that IoGetTopLevelIrp returns NULL.

1: kd> u Ntfs!NtfsCleanupIrpContext+119-7
Ntfs!NtfsCleanupIrpContext+0x112:
fffff880012149a2 c3 ret fffff880012149a3 ff1507820300 call qword ptr [Ntfs!_imp_IoGetTopLevelIrp (fffff8800124cbb0)] fffff880012149a9 488b4818 mov rcx,qword ptr [rax+18h]
fffff880012149ad 44897804 mov dword ptr [rax+4],r15d fffff880012149b1 4c897820 mov qword ptr [rax+20h],r15
fffff880012149b5 ff154d770300 call qword ptr [Ntfs!_imp_IoSetTopLevelIrp (fffff8800124c108)]
fffff880012149bb 816308ffffefff and dword ptr [rbx+8],0FFEFFFFFh fffff880012149c2 ebbb jmp Ntfs!NtfsCleanupIrpContext+0xef (fffff880`0121497f)

Why does it happen? What do I miss? Thanks.

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

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

Mikae · January 23, 2014, 4:16pm

Test-test-test. Can’t reply here :-\

Mikae · January 23, 2014, 5:08pm

For some unknown reasons I could’t post the following message: http://pastebin.com/xKZXRJDc The server resets connection…

Mikae · January 25, 2014, 3:55pm

Sorry for bumping, but the problem is still alive.

Alex_Carp · January 31, 2014, 11:42am

You should probably start different threads for different problems.

Anyway, I don’t think you should create a new section in the IRP_MJ_CLOSE
for a FILE_OBJECT. The section might need a reference to the FILE_OBJECT
but the refcount has already dropped to 0 (that’s why you see the
IRP_MJ_CLOSE).

Thanks,
Alex.

On Sat, Jan 25, 2014 at 12:55 PM, wrote:

> Sorry for bumping, but the problem is still alive.
>
> —
> 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
>

Mikae · February 4, 2014, 6:17am

Alex,

Yes, I’ve shifted to MJ_CLEANUP (which is more suitable in my case) and it works.

From the dump above you can see that ZwCreateSection affects thread’s top level IRP. So it is possible to get rid of the crash by wrapping ZwCreateSection call with IoGetTopLevelIrp and IoSetTopLevelIrp. The problem is that I can’t explain why it happens. What is top level IRP? Why it is affected by ZwCreateSection? These questions are more about curiosity that practical meaning.

Alex_Carp · February 4, 2014, 12:56pm

I think you’re going the wrong way about it. Increasing the reference count
in from 0 to 1 is not just unsuitable, it’s plain wrong. Exactly how the
system will react (crash, leak the memory or anything else) is hard to
predict. I’d say it’s not worth focusing on patching the system to deal
with it, you’re most likely just pushing the thing along and it’ll fail in
a different way elsewhere.

There are many OSR threads about TopLevelIrp. In short, the way I think
about it is that it is a way for a file system to store a 4 byte value in
the ETHREAD, and what the value means is file system specific.

Thanks,
Alex.

On Tue, Feb 4, 2014 at 3:16 AM, wrote:

> Alex,
>
> Yes, I’ve shifted to MJ_CLEANUP (which is more suitable in my case) and it
> works.
>
> From the dump above you can see that ZwCreateSection affects thread’s top
> level IRP. So it is possible to get rid of the crash by wrapping
> ZwCreateSection call with IoGetTopLevelIrp and IoSetTopLevelIrp. The
> problem is that I can’t explain why it happens. What is top level IRP?
> Why it is affected by ZwCreateSection? These questions are more about
> curiosity that practical meaning.
>
> —
> 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
>

OSR_Community_User · February 4, 2014, 1:48pm

>file system to store a 4 byte value in the ETHREAD, and what the value means is file system specific.

4 or 8 byte, depending on 32/64 OS build

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

Alex_Carp · February 4, 2014, 2:35pm

Yeah, you’re absolutely right, it’s pointer-sized :). I guess that says
something about the sort of systems I do most my debugging on :).

Thanks,
Alex.

On Tue, Feb 4, 2014 at 10:47 AM, Maxim S. Shatskih
wrote:

> >file system to store a 4 byte value in the ETHREAD, and what the value
> means is file system specific.
>
> 4 or 8 byte, depending on 32/64 OS build
>
> –
> Maxim S. Shatskih
> Microsoft MVP on File System And Storage
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> 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
>