Log IRP Data In Minifilter Pre_Operation or Post-Oparation

NTDEV
1

its better log IRP data In Pre or post operation or it depend on IRP and my aim ?

like it

FLT_POSTOP_CALLBACK_STATUS
PtPostWrite
(
__inout PFLT_CALLBACK_DATA Data,
__in PCFLT_RELATED_OBJECTS FltObjects,
__in_opt PVOID CompletionContext,
__in FLT_POST_OPERATION_FLAGS Flags
)

{

PrintFilePath(Data);
DbgPrint(“Write Process name is: %s \r \n”,PsGetProcessImageFileName(IoThreadToProcess( Data->Thread )));
DbgPrint(“Write Length %x \n”,Data->Iopb->Parameters.Write.Length);

//Data->Iopb->Parameters.Read.ByteOffset;

return FLT_POSTOP_FINISHED_PROCESSING;
}

this code produce BSOD with ATTEMPTED_SWITCH_FROM_DPC

2

I’m don’t know what are your aims, but if you would like to monitor
operations that has been done (not only requests, but results),
I would suggest to use post-op and install your filter at altitude “FSFilter
Activity Monitor”.
Pre-op can be failed by many filters below yours, so you can log for example
file open (in pre-create), but in fact file wasn’t exists, there was access
denied, etc.
Post-op can be failed too, but I think that it’s much more less common
(maybe except post-create), as it’s much complicated, because operation has
been already done (like write, create).
Also I think that filters in “FSFilter Activity Monitor” should not
cancel/fail or modify operation in any way (but it’s just my guess).

Did you looked at minispy example from WDK? It might help you a bit.

About BSOD, !analyze -v

Best regards,
Krystian Bigaj

On 14 August 2011 12:57, wrote:

> its better log IRP data In Pre or post operation or it depend on IRP and
> my aim ?

3

thanks but i cant understand who "Pre-op can be failed by many filters below yours" i think minifilter above me can fail my pre-op with FLT_PREOP_COMPLETE

""""Did you looked at minispy example from WDK? It might help you a bit. """

yes any day and any time :slight_smile:

"""About BSOD, !analyze -v """"

whene i change my log to pre-ope dont get BSOD

it is !analyze -v ( i change passthrough )

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

ATTEMPTED_SWITCH_FROM_DPC (b8)
A wait operation, attach process, or yield was attempted from a DPC routine.
This is an illegal operation and the stack track will lead to the offending
code and original DPC routine.
Arguments:
Arg1: 00000000, Original thread which is the cause of the failure
Arg2: 00000000, New thread
Arg3: 00000000, Stack address of the original thread
Arg4: 00000000

Debugging Details:

Unable to load image PassThrough.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for PassThrough.sys

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xB8

PROCESS_NAME: notepad++.exe

LAST_CONTROL_TRANSFER: from 80541a37 to 804f8c90

STACK_TEXT:
8054992c 80541a37 000000b8 ffffffff 00000202 nt!KeBugCheck+0x14
8054993c 805418af 80549954 806d228d 0000003d nt!SwapContext+0x157
8054994c 806d2a86 805499e0 806d228d badb0d00 nt!KiDispatchInterrupt+0x7f
8054994c 806d228d 805499e0 806d228d badb0d00 hal!HalpDispatchInterrupt+0xba
805499c4 f82da592 00000000 82089e78 00000001 hal!KfRaiseIrql+0x15
805499e0 f82dfda9 821072c0 00000001 00000000 fltMgr!FltpGetNextCallbackNodeForInstance+0x40
80549a14 f82e0366 82089e78 820f8008 820f8064 fltMgr!FltpGetFileNameInformation+0x49
80549a3c f8a05510 030f8064 00000101 80549a54 fltMgr!FltGetFileNameInformation+0x114
80549a58 f8a05661 820f8064 820f80bc 80549ad0 PassThrough!PrintFilePath+0x1c [d:\project\passthrough\passthrough.c @ 737]
80549a68 f82daef3 820f8064 80549a8c 00000000 PassThrough!PtPreRead+0xd [d:\project\passthrough\passthrough.c @ 687]
80549ad0 f82dd338 000f8008 82165153 820f8008 fltMgr!FltpPerformPostCallbacks+0x1c5
80549ae4 f82dd867 820f8008 82165008 80549b24 fltMgr!FltpProcessIoCompletion+0x10
80549af4 804f069e 8221ac08 82165008 820f8008 fltMgr!FltpPassThroughCompletion+0x89
80549b24 f84efbf4 80549b54 f84efed4 823a68d8 nt!IopfCompleteRequest+0xa2
80549b2c f84efed4 823a68d8 82165008 00000001 CLASSPNP!ClassCompleteRequest+0x11
80549b54 804f069e 00000000 82129790 82129928 CLASSPNP!TransferPktComplete+0x180
80549b84 f83196fc 8235e550 823d00e8 00000000 nt!IopfCompleteRequest+0xa2
80549bb0 f8319c8e 82129790 8235e550 80549c2b atapi!IdeProcessCompletedRequest+0x664
80549c2c 80541b8d 823d00a4 823d0030 00000000 atapi!IdePortCompletionDpc+0x204
80549c50 80541b06 00000000 0000000e 00000000 nt!KiRetireDpcList+0x46
80549c54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x26

STACK_COMMAND: kb

FOLLOWUP_IP:
PassThrough!PrintFilePath+1c [d:\project\passthrough\passthrough.c @ 737]
f8a05510 ?? ???

FAULTING_SOURCE_CODE:
733:
734: status = FltGetFileNameInformation
735: (
736: Data,

737: FLT_FILE_NAME_NORMALIZED|FLT_FILE_NAME_QUERY_ALWAYS_ALLOW_CACHE_LOOKUP,
738: &nameInfo
739: );
740:
741: if(NT_ERROR(status))
742: {

SYMBOL_STACK_INDEX: 8

SYMBOL_NAME: PassThrough!PrintFilePath+1c

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: PassThrough

IMAGE_NAME: PassThrough.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4e478e3d

FAILURE_BUCKET_ID: 0xB8_PassThrough!PrintFilePath+1c

BUCKET_ID: 0xB8_PassThrough!PrintFilePath+1c

Followup: MachineOwner

4

If you look at
http://msdn.microsoft.com/en-us/library/ff541610(v=vs.85).aspx request goes
from up-to-bottom (pre-op’s), and any minifilter (or legacy), can complete
operation (failing or succeed it), if nothing like that happend, request is
completed is some drivers below. From that point operations goes from
bottom-to-up in post-op.
(I think that above naming is correct, if I’m wrong, please correct me).

BSOD: you are calling FltGetFileNameInformation(IRQL <= APC_LEVEL) in
post-read which are called at DISPATCH_LEVEL.
Also it’s really bad idea, to get file name for each operation (most time at
post-op you cannot do this), best would be get name in post-create(which is
always at PASSIVE_LEVEL) and store it in context.

I think that you will have to do some readings :slight_smile:
http://msdn.microsoft.com/en-us/library/ms810029.aspx
http://msdn.microsoft.com/en-us/library/ff540402(v=VS.85).aspx (from
beginning to
end :slight_smile:
…

Best regards,
Krystian Bigaj

On 15 August 2011 07:35, wrote:

> thanks but i cant understand who “Pre-op can be failed by many filters
> below yours” i think minifilter above me can fail my pre-op with
> FLT_PREOP_COMPLETE
>
> “”““Did you looked at minispy example from WDK? It might help you a bit.
> “””
>
> yes any day and any time :slight_smile:
>
>
> “”“About BSOD, !analyze -v “”””
>
> whene i change my log to pre-ope dont get BSOD
>
> it is !analyze -v ( i change passthrough )

5

wow it’s my language problem i misunderstood this “Pre-op can be failed
by many filters below yours” i know how IRP work

i solved our BSOD problem :slight_smile:

i have already read http://msdn.microsoft.com/en-us/library/ms810029.aspx

and in http://msdn.microsoft.com/en-us/library/ff540402(v=VS.85).aspx i
already read all topic except Managing Contexts in a Minifilter
Driverhttp:

can you explain more this " to get file name for each operation (most time
at post-op you cannot do this), best would be get name in post-create(which
is always at PASSIVE_LEVEL) and store it in context."</http:>

6

As you want to know result of operation (like write), you should use
post-write, but it can be called at <= DISPATCH_LEVEL. Calling
FltGetFileNameInformation at DISPATCH_LEVEL will cause BSOD (as you saw it
yourself before). You could possibly use worker-thread, but in that case it
will be IMO too much overhead.

I think that best way would be to use stream-handle-context. At (successful)
post-create, you could get file name, allocate context, fill it with your
data (maybe allocate memory, serialize your file name/path/ext to it, and
store just a pointer to that memory in context), at end set context to file
object. Later in post-read/write you could use that context ‘with’ file name
(only if that memory was allocated from non-paged pool) at I would say
‘no-cost’.
You could alternatively try to store pointer to FLT_FILE_NAME_INFORMATION in
context (and when at end context will be cleared/deleted you just release
reference to that object), but I’m not sure if there are any constraints
about doing it (structure is owned by flt-mgr). I think that you should not
touch content at DISPATCH_LEVEL as you cannot call FltGetFileNameInformation
at this level (but this is just my guess).

Best if you would learn more about context first from:

Then you could choose best way to do it, or/and share your taken concept to
list (ntfsd).

btw: This whole topic should be posted to NTFSD.

Best regards,
Krystian Bigaj

On 15 August 2011 12:35, meysam firozi wrote:

> … i already read all topic except Managing Contexts in a Minifilter
> Driver http:
>
> can you explain more this " to get file name for each operation (most time
> at post-op you cannot do this), best would be get name in post-create(which
> is always at PASSIVE_LEVEL) and store it in context."
></http:>

7

very thanks
you can explain concept very good i have never seen it before in any
forum