Using FltQueueDeferredIoWorkItem

I am just starting to investigate file system filter drivers, and thought
I’d write some simple filters to try out some of the basic operations. One
of my tests is to log information from certain operations to a log file (but
I haven’t got that far). As I understand it neither a post-op routine nor a
routine called by it using ‘FltDoCompletionProcessingWhenSafe’ should write
to a file, as neither of these are guaranteed to be running at PASSIVE_LEVEL

  • required by ZwWriteFile.

So I tried using ‘FltQueueDeferredIoWorkItem’ instead - but my work routine
does nothing yet except a DbgPrint, FltCompletePendedPostOperation and
FltFreeDeferredIoWorkItem - Full code for the post-op callback and deferred
routine below. (Actually the work routine was calling ZwWriteFile but that
all got stripped out when trying to isolate the bug).

The problem is that whatever operations I use the callback on my system blue
screens - I guess I must be doing something incredibly stupid or have missed
something really obvious but I’m afraid I can’t see it. I haven’t yet found
any examples of these calls, nor other relevant posts, so any help or
pointers you can give me will be most gratefully received.

The test environment is Windows XP SP2, running as virtual machine under
VMWare. Could that be relevant?

Thanks in advance,
Gareth Evans


FLT_POSTOP_CALLBACK_STATUS MyFilterPostOperationCB(
IN OUT PFLT_CALLBACK_DATA CallbackData,
IN PCFLT_RELATED_OBJECTS FltObjects,
IN PVOID CompletionContext,
IN FLT_POST_OPERATION_FLAGS Flags)
{
FLT_POSTOP_CALLBACK_STATUS ReturnStatus =
FLT_POSTOP_FINISHED_PROCESSING;
PFLT_IO_PARAMETER_BLOCK Iopb = CallbackData->Iopb;

DbgPrint(“MyFilterPostOperationCB IRP_MJ=%ld\n”, Iopb->MajorFunction);

if (FALSE == FlagOn(Flags,FLTFL_POST_OPERATION_DRAINING))
{
PFLT_DEFERRED_IO_WORKITEM WorkItem = NULL;

WorkItem = FltAllocateDeferredIoWorkItem();
if (NULL == WorkItem)
{
DbgPrint(“OUT OF MEMORY!\n”);
}
else
{
NTSTATUS Status;

Status = FltQueueDeferredIoWorkItem(WorkItem,
CallbackData,
MyFilterDelayedPostOpCB,
DelayedWorkQueue,
CompletionContext);
if (NT_SUCCESS(Status))
{
ReturnStatus = FLT_POSTOP_MORE_PROCESSING_REQUIRED;
}
else if (STATUS_FLT_NOT_SAFE_TO_POST_OPERATION == Status)
{
DbgPrint(“Not safe to post operation\n”);
}
else
{
DbgPrint(“Failed post operation 0x%x\n”,Status);
}
}
}
return FLT_POSTOP_FINISHED_PROCESSING;
}

VOID MyFilterDelayedPostOpCB(IN PFLT_DEFERRED_IO_WORKITEM WorkItem,
IN PFLT_CALLBACK_DATA CallbackData,
IN PVOID CompletionContext)
{
PFLT_IO_PARAMETER_BLOCK Iopb = CallbackData->Iopb;
PFLT_PARAMETERS Params = &Iopb->Parameters;

DbgPrint(“DelayedPostOpCB. IRP_MJ=%ld\n”, Iopb->MajorFunction);

FltCompletePendedPostOperation(CallbackData);
FltFreeDeferredIoWorkItem(WorkItem);
}

****************************************************************************
***
*
*
* 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: f97c7452, The address that the exception occurred at
Arg3: f798069c, 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:
fltMgr!FltpCompleteCompletionNode+2c
f97c7452 8b4008 mov eax,dword ptr [eax+8]

TRAP_FRAME: f798069c – (.trap fffffffff798069c)
ErrCode = 00000000
eax=00000000 ebx=815d4064 ecx=815d40bc edx=00000001 esi=815d4008
edi=815d4008
eip=f97c7452 esp=f7980710 ebp=f7980714 iopl=0 nv up ei pl zr na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
fltMgr!FltpCompleteCompletionNode+0x2c:
f97c7452 8b4008 mov eax,dword ptr [eax+8]
ds:0023:00000008=???
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: ls.exe

LAST_CONTROL_TRANSFER: from f97c7f06 to f97c7452

STACK_TEXT:
f7980714 f97c7f06 815d4008 00000000 815d4008
fltMgr!FltpCompleteCompletionNode+0x2c
f7980770 f97ca338 005d4008 00000000 815d4008
fltMgr!FltpPerformPostCallbacks+0x1d8
f7980784 f97ca867 815d4008 81907c88 f79807c4
fltMgr!FltpProcessIoCompletion+0x10
f7980794 f97caef9 81190368 81907c88 815d4008
fltMgr!FltpPassThroughCompletion+0x89
f79807c4 f97d7448 f79807e4 00000000 00000000
fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x269
f7980800 804eddf9 81190368 81907c88 81907c88 fltMgr!FltpCreate+0x26a
f7980810 805773b4 819976c0 816bf8dc f79809b8 nt!IopfCallDriver+0x31
f79808f0 805b3642 819976d8 00000000 816bf838 nt!IopParseDevice+0xa58
f7980978 805afb23 00000000 f79809b8 00000240 nt!ObpLookupObjectName+0x56a
f79809cc 8056a11d 00000000 00000000 710c8000 nt!ObOpenObjectByName+0xeb
f7980a48 8056aa94 f7980bf4 00100180 f7980bd8 nt!IopCreateFile+0x407
f7980aa4 8056d166 f7980bf4 00100180 f7980bd8 nt!IoCreateFile+0x8e
f7980ae4 8053c808 f7980bf4 00100180 f7980bd8 nt!NtCreateFile+0x30
f7980ae4 804fd569 f7980bf4 00100180 f7980bd8 nt!KiFastCallEntry+0xf8
f7980b88 8061376f f7980bf4 00100180 f7980bd8 nt!ZwCreateFile+0x11
f7980c18 806151a9 e1cf8f92 f7980c58 f7980c3c nt!CcPfQueryVolumeInfo+0x6b
f7980c5c 80615856 01980c70 09485270 00000023
nt!CcPfOpenVolumesForPrefetch+0xa3
f7980c88 80615c9c e1cf7000 00080000 816e98a0 nt!CcPfPrefetchScenario+0x5e
f7980d04 805c4953 816e98a0 e1da6790 00000000 nt!CcPfBeginAppLaunch+0x158
f7980d50 80540fa2 00000000 7c810665 00000001 nt!PspUserThreadStartup+0xeb
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
fltMgr!FltpCompleteCompletionNode+2c
f97c7452 8b4008 mov eax,dword ptr [eax+8]

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: fltMgr!FltpCompleteCompletionNode+2c

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: fltMgr

IMAGE_NAME: fltMgr.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 44e97991

FAILURE_BUCKET_ID: 0x8E_fltMgr!FltpCompleteCompletionNode+2c

BUCKET_ID: 0x8E_fltMgr!FltpCompleteCompletionNode+2c

Followup: MachineOwner

Gareth:

I think the problem’s simple – you have hard-coded the return rather than
use ReturnStatus, so FLT_POSTOP_FINISHED_PROCESSING never gets returned.
Try changing

return FLT_POSTOP_FINISHED_PROCESSING;

to

return ReturnStatus;

BTW, you should use FltWriteFile, not ZwWriteFile.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gareth Evans
Sent: Thursday, October 19, 2006 7:09 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Using FltQueueDeferredIoWorkItem

I am just starting to investigate file system filter drivers, and thought
I’d write some simple filters to try out some of the basic operations. One
of my tests is to log information from certain operations to a log file (but
I haven’t got that far). As I understand it neither a post-op routine nor a
routine called by it using ‘FltDoCompletionProcessingWhenSafe’ should write
to a file, as neither of these are guaranteed to be running at PASSIVE_LEVEL

  • required by ZwWriteFile.

So I tried using ‘FltQueueDeferredIoWorkItem’ instead - but my work routine
does nothing yet except a DbgPrint, FltCompletePendedPostOperation and
FltFreeDeferredIoWorkItem - Full code for the post-op callback and deferred
routine below. (Actually the work routine was calling ZwWriteFile but that
all got stripped out when trying to isolate the bug).

The problem is that whatever operations I use the callback on my system blue
screens - I guess I must be doing something incredibly stupid or have missed
something really obvious but I’m afraid I can’t see it. I haven’t yet found
any examples of these calls, nor other relevant posts, so any help or
pointers you can give me will be most gratefully received.

The test environment is Windows XP SP2, running as virtual machine under
VMWare. Could that be relevant?

Thanks in advance,
Gareth Evans


FLT_POSTOP_CALLBACK_STATUS MyFilterPostOperationCB(
IN OUT PFLT_CALLBACK_DATA CallbackData,
IN PCFLT_RELATED_OBJECTS FltObjects,
IN PVOID CompletionContext,
IN FLT_POST_OPERATION_FLAGS Flags)
{
FLT_POSTOP_CALLBACK_STATUS ReturnStatus =
FLT_POSTOP_FINISHED_PROCESSING;
PFLT_IO_PARAMETER_BLOCK Iopb = CallbackData->Iopb;

DbgPrint(“MyFilterPostOperationCB IRP_MJ=%ld\n”, Iopb->MajorFunction);

if (FALSE == FlagOn(Flags,FLTFL_POST_OPERATION_DRAINING))
{
PFLT_DEFERRED_IO_WORKITEM WorkItem = NULL;

WorkItem = FltAllocateDeferredIoWorkItem();
if (NULL == WorkItem)
{
DbgPrint(“OUT OF MEMORY!\n”);
}
else
{
NTSTATUS Status;

Status = FltQueueDeferredIoWorkItem(WorkItem,
CallbackData,
MyFilterDelayedPostOpCB,
DelayedWorkQueue,
CompletionContext);
if (NT_SUCCESS(Status))
{
ReturnStatus = FLT_POSTOP_MORE_PROCESSING_REQUIRED;
}
else if (STATUS_FLT_NOT_SAFE_TO_POST_OPERATION == Status)
{
DbgPrint(“Not safe to post operation\n”);
}
else
{
DbgPrint(“Failed post operation 0x%x\n”,Status);
}
}
}
return FLT_POSTOP_FINISHED_PROCESSING;
}

VOID MyFilterDelayedPostOpCB(IN PFLT_DEFERRED_IO_WORKITEM WorkItem,
IN PFLT_CALLBACK_DATA CallbackData,
IN PVOID CompletionContext)
{
PFLT_IO_PARAMETER_BLOCK Iopb = CallbackData->Iopb;
PFLT_PARAMETERS Params = &Iopb->Parameters;

DbgPrint(“DelayedPostOpCB. IRP_MJ=%ld\n”, Iopb->MajorFunction);

FltCompletePendedPostOperation(CallbackData);
FltFreeDeferredIoWorkItem(WorkItem);
}

****************************************************************************
***
*
*
* 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: f97c7452, The address that the exception occurred at
Arg3: f798069c, 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:
fltMgr!FltpCompleteCompletionNode+2c
f97c7452 8b4008 mov eax,dword ptr [eax+8]

TRAP_FRAME: f798069c – (.trap fffffffff798069c)
ErrCode = 00000000
eax=00000000 ebx=815d4064 ecx=815d40bc edx=00000001 esi=815d4008
edi=815d4008
eip=f97c7452 esp=f7980710 ebp=f7980714 iopl=0 nv up ei pl zr na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
fltMgr!FltpCompleteCompletionNode+0x2c:
f97c7452 8b4008 mov eax,dword ptr [eax+8]
ds:0023:00000008=???
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: ls.exe

LAST_CONTROL_TRANSFER: from f97c7f06 to f97c7452

STACK_TEXT:
f7980714 f97c7f06 815d4008 00000000 815d4008
fltMgr!FltpCompleteCompletionNode+0x2c
f7980770 f97ca338 005d4008 00000000 815d4008
fltMgr!FltpPerformPostCallbacks+0x1d8
f7980784 f97ca867 815d4008 81907c88 f79807c4
fltMgr!FltpProcessIoCompletion+0x10
f7980794 f97caef9 81190368 81907c88 815d4008
fltMgr!FltpPassThroughCompletion+0x89
f79807c4 f97d7448 f79807e4 00000000 00000000
fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x269
f7980800 804eddf9 81190368 81907c88 81907c88 fltMgr!FltpCreate+0x26a
f7980810 805773b4 819976c0 816bf8dc f79809b8 nt!IopfCallDriver+0x31
f79808f0 805b3642 819976d8 00000000 816bf838 nt!IopParseDevice+0xa58
f7980978 805afb23 00000000 f79809b8 00000240 nt!ObpLookupObjectName+0x56a
f79809cc 8056a11d 00000000 00000000 710c8000 nt!ObOpenObjectByName+0xeb
f7980a48 8056aa94 f7980bf4 00100180 f7980bd8 nt!IopCreateFile+0x407
f7980aa4 8056d166 f7980bf4 00100180 f7980bd8 nt!IoCreateFile+0x8e
f7980ae4 8053c808 f7980bf4 00100180 f7980bd8 nt!NtCreateFile+0x30
f7980ae4 804fd569 f7980bf4 00100180 f7980bd8 nt!KiFastCallEntry+0xf8
f7980b88 8061376f f7980bf4 00100180 f7980bd8 nt!ZwCreateFile+0x11
f7980c18 806151a9 e1cf8f92 f7980c58 f7980c3c nt!CcPfQueryVolumeInfo+0x6b
f7980c5c 80615856 01980c70 09485270 00000023
nt!CcPfOpenVolumesForPrefetch+0xa3
f7980c88 80615c9c e1cf7000 00080000 816e98a0 nt!CcPfPrefetchScenario+0x5e
f7980d04 805c4953 816e98a0 e1da6790 00000000 nt!CcPfBeginAppLaunch+0x158
f7980d50 80540fa2 00000000 7c810665 00000001 nt!PspUserThreadStartup+0xeb
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
fltMgr!FltpCompleteCompletionNode+2c
f97c7452 8b4008 mov eax,dword ptr [eax+8]

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: fltMgr!FltpCompleteCompletionNode+2c

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: fltMgr

IMAGE_NAME: fltMgr.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 44e97991

FAILURE_BUCKET_ID: 0x8E_fltMgr!FltpCompleteCompletionNode+2c

BUCKET_ID: 0x8E_fltMgr!FltpCompleteCompletionNode+2c

Followup: MachineOwner


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

Can the following be the reason: you prepare

ReturnStatus = FLT_POSTOP_MORE_PROCESSING_REQUIRED;

after a successful call to FltQueueDeferredIoWorkItem, but
return FLT_POSTOP_FINISHED_PROCESSING from
MyFilterPostOperationCB always.

Double completion follows…

----- Original Message -----
From: “Gareth Evans”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, October 19, 2006 7:09 AM
Subject: [ntfsd] Using FltQueueDeferredIoWorkItem

>I am just starting to investigate file system filter drivers, and thought
> I’d write some simple filters to try out some of the basic operations. One
> of my tests is to log information from certain operations to a log file
> (but
> I haven’t got that far). As I understand it neither a post-op routine nor
> a
> routine called by it using ‘FltDoCompletionProcessingWhenSafe’ should
> write
> to a file, as neither of these are guaranteed to be running at
> PASSIVE_LEVEL
> - required by ZwWriteFile.
>
> So I tried using ‘FltQueueDeferredIoWorkItem’ instead - but my work
> routine
> does nothing yet except a DbgPrint, FltCompletePendedPostOperation and
> FltFreeDeferredIoWorkItem - Full code for the post-op callback and
> deferred
> routine below. (Actually the work routine was calling ZwWriteFile but that
> all got stripped out when trying to isolate the bug).
>
> The problem is that whatever operations I use the callback on my system
> blue
> screens - I guess I must be doing something incredibly stupid or have
> missed
> something really obvious but I’m afraid I can’t see it. I haven’t yet
> found
> any examples of these calls, nor other relevant posts, so any help or
> pointers you can give me will be most gratefully received.
>
> The test environment is Windows XP SP2, running as virtual machine under
> VMWare. Could that be relevant?
>
> Thanks in advance,
> Gareth Evans
>
> _____________________________________
>
>
> FLT_POSTOP_CALLBACK_STATUS MyFilterPostOperationCB(
> IN OUT PFLT_CALLBACK_DATA CallbackData,
> IN PCFLT_RELATED_OBJECTS FltObjects,
> IN PVOID CompletionContext,
> IN FLT_POST_OPERATION_FLAGS Flags)
> {
> FLT_POSTOP_CALLBACK_STATUS ReturnStatus =
> FLT_POSTOP_FINISHED_PROCESSING;
> PFLT_IO_PARAMETER_BLOCK Iopb = CallbackData->Iopb;
>
> DbgPrint(“MyFilterPostOperationCB IRP_MJ=%ld\n”, Iopb->MajorFunction);
>
> if (FALSE == FlagOn(Flags,FLTFL_POST_OPERATION_DRAINING))
> {
> PFLT_DEFERRED_IO_WORKITEM WorkItem = NULL;
>
> WorkItem = FltAllocateDeferredIoWorkItem();
> if (NULL == WorkItem)
> {
> DbgPrint(“OUT OF MEMORY!\n”);
> }
> else
> {
> NTSTATUS Status;
>
> Status = FltQueueDeferredIoWorkItem(WorkItem,
> CallbackData,
> MyFilterDelayedPostOpCB,
> DelayedWorkQueue,
> CompletionContext);
> if (NT_SUCCESS(Status))
> {
> ReturnStatus = FLT_POSTOP_MORE_PROCESSING_REQUIRED;
> }
> else if (STATUS_FLT_NOT_SAFE_TO_POST_OPERATION == Status)
> {
> DbgPrint(“Not safe to post operation\n”);
> }
> else
> {
> DbgPrint(“Failed post operation 0x%x\n”,Status);
> }
> }
> }
> return FLT_POSTOP_FINISHED_PROCESSING;
> }
>
>
> VOID MyFilterDelayedPostOpCB(IN PFLT_DEFERRED_IO_WORKITEM WorkItem,
> IN PFLT_CALLBACK_DATA CallbackData,
> IN PVOID CompletionContext)
> {
> PFLT_IO_PARAMETER_BLOCK Iopb = CallbackData->Iopb;
> PFLT_PARAMETERS Params = &Iopb->Parameters;
>
> DbgPrint(“DelayedPostOpCB. IRP_MJ=%ld\n”, Iopb->MajorFunction);
>
> FltCompletePendedPostOperation(CallbackData);
> FltFreeDeferredIoWorkItem(WorkItem);
> }
>
>
> *************************************************************************
>

> *
> *
> * 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: f97c7452, The address that the exception occurred at
> Arg3: f798069c, 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:
> fltMgr!FltpCompleteCompletionNode+2c
> f97c7452 8b4008 mov eax,dword ptr [eax+8]
>
> TRAP_FRAME: f798069c – (.trap fffffffff798069c)
> ErrCode = 00000000
> eax=00000000 ebx=815d4064 ecx=815d40bc edx=00000001 esi=815d4008
> edi=815d4008
> eip=f97c7452 esp=f7980710 ebp=f7980714 iopl=0 nv up ei pl zr na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010246
> fltMgr!FltpCompleteCompletionNode+0x2c:
> f97c7452 8b4008 mov eax,dword ptr [eax+8]
> ds:0023:00000008=???
> Resetting default scope
>
> CUSTOMER_CRASH_COUNT: 1
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x8E
>
> PROCESS_NAME: ls.exe
>
> LAST_CONTROL_TRANSFER: from f97c7f06 to f97c7452
>
> STACK_TEXT:
> f7980714 f97c7f06 815d4008 00000000 815d4008
> fltMgr!FltpCompleteCompletionNode+0x2c
> f7980770 f97ca338 005d4008 00000000 815d4008
> fltMgr!FltpPerformPostCallbacks+0x1d8
> f7980784 f97ca867 815d4008 81907c88 f79807c4
> fltMgr!FltpProcessIoCompletion+0x10
> f7980794 f97caef9 81190368 81907c88 815d4008
> fltMgr!FltpPassThroughCompletion+0x89
> f79807c4 f97d7448 f79807e4 00000000 00000000
> fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x269
> f7980800 804eddf9 81190368 81907c88 81907c88 fltMgr!FltpCreate+0x26a
> f7980810 805773b4 819976c0 816bf8dc f79809b8 nt!IopfCallDriver+0x31
> f79808f0 805b3642 819976d8 00000000 816bf838 nt!IopParseDevice+0xa58
> f7980978 805afb23 00000000 f79809b8 00000240 nt!ObpLookupObjectName+0x56a
> f79809cc 8056a11d 00000000 00000000 710c8000 nt!ObOpenObjectByName+0xeb
> f7980a48 8056aa94 f7980bf4 00100180 f7980bd8 nt!IopCreateFile+0x407
> f7980aa4 8056d166 f7980bf4 00100180 f7980bd8 nt!IoCreateFile+0x8e
> f7980ae4 8053c808 f7980bf4 00100180 f7980bd8 nt!NtCreateFile+0x30
> f7980ae4 804fd569 f7980bf4 00100180 f7980bd8 nt!KiFastCallEntry+0xf8
> f7980b88 8061376f f7980bf4 00100180 f7980bd8 nt!ZwCreateFile+0x11
> f7980c18 806151a9 e1cf8f92 f7980c58 f7980c3c nt!CcPfQueryVolumeInfo+0x6b
> f7980c5c 80615856 01980c70 09485270 00000023
> nt!CcPfOpenVolumesForPrefetch+0xa3
> f7980c88 80615c9c e1cf7000 00080000 816e98a0 nt!CcPfPrefetchScenario+0x5e
> f7980d04 805c4953 816e98a0 e1da6790 00000000 nt!CcPfBeginAppLaunch+0x158
> f7980d50 80540fa2 00000000 7c810665 00000001 nt!PspUserThreadStartup+0xeb
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> fltMgr!FltpCompleteCompletionNode+2c
> f97c7452 8b4008 mov eax,dword ptr [eax+8]
>
> SYMBOL_STACK_INDEX: 0
>
> SYMBOL_NAME: fltMgr!FltpCompleteCompletionNode+2c
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: fltMgr
>
> IMAGE_NAME: fltMgr.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 44e97991
>
> FAILURE_BUCKET_ID: 0x8E_fltMgr!FltpCompleteCompletionNode+2c
>
> BUCKET_ID: 0x8E_fltMgr!FltpCompleteCompletionNode+2c
>
> Followup: MachineOwner
> ---------
>
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com

Unfortunately after fixing the PostOp callback to return ReturnStatus I
still get the blue screen. So that’s something else I’m doing wrong :frowning:

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of sh_alex
Sent: 19 October 2006 12:47
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Using FltQueueDeferredIoWorkItem

Can the following be the reason: you prepare

ReturnStatus = FLT_POSTOP_MORE_PROCESSING_REQUIRED;

after a successful call to FltQueueDeferredIoWorkItem, but
return FLT_POSTOP_FINISHED_PROCESSING from
MyFilterPostOperationCB always.

Double completion follows…

----- Original Message -----
From: “Gareth Evans”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, October 19, 2006 7:09 AM
Subject: [ntfsd] Using FltQueueDeferredIoWorkItem

>I am just starting to investigate file system filter drivers, and thought
> I’d write some simple filters to try out some of the basic operations. One
> of my tests is to log information from certain operations to a log file
> (but
> I haven’t got that far). As I understand it neither a post-op routine nor
> a
> routine called by it using ‘FltDoCompletionProcessingWhenSafe’ should
> write
> to a file, as neither of these are guaranteed to be running at
> PASSIVE_LEVEL
> - required by ZwWriteFile.
>
> So I tried using ‘FltQueueDeferredIoWorkItem’ instead - but my work
> routine
> does nothing yet except a DbgPrint, FltCompletePendedPostOperation and
> FltFreeDeferredIoWorkItem - Full code for the post-op callback and
> deferred
> routine below. (Actually the work routine was calling ZwWriteFile but that
> all got stripped out when trying to isolate the bug).
>
> The problem is that whatever operations I use the callback on my system
> blue
> screens - I guess I must be doing something incredibly stupid or have
> missed
> something really obvious but I’m afraid I can’t see it. I haven’t yet
> found
> any examples of these calls, nor other relevant posts, so any help or
> pointers you can give me will be most gratefully received.
>
> The test environment is Windows XP SP2, running as virtual machine under
> VMWare. Could that be relevant?
>
> Thanks in advance,
> Gareth Evans
>
> _____________________________________
>
>
> FLT_POSTOP_CALLBACK_STATUS MyFilterPostOperationCB(
> IN OUT PFLT_CALLBACK_DATA CallbackData,
> IN PCFLT_RELATED_OBJECTS FltObjects,
> IN PVOID CompletionContext,
> IN FLT_POST_OPERATION_FLAGS Flags)
> {
> FLT_POSTOP_CALLBACK_STATUS ReturnStatus =
> FLT_POSTOP_FINISHED_PROCESSING;
> PFLT_IO_PARAMETER_BLOCK Iopb = CallbackData->Iopb;
>
> DbgPrint(“MyFilterPostOperationCB IRP_MJ=%ld\n”, Iopb->MajorFunction);
>
> if (FALSE == FlagOn(Flags,FLTFL_POST_OPERATION_DRAINING))
> {
> PFLT_DEFERRED_IO_WORKITEM WorkItem = NULL;
>
> WorkItem = FltAllocateDeferredIoWorkItem();
> if (NULL == WorkItem)
> {
> DbgPrint(“OUT OF MEMORY!\n”);
> }
> else
> {
> NTSTATUS Status;
>
> Status = FltQueueDeferredIoWorkItem(WorkItem,
> CallbackData,
> MyFilterDelayedPostOpCB,
> DelayedWorkQueue,
> CompletionContext);
> if (NT_SUCCESS(Status))
> {
> ReturnStatus = FLT_POSTOP_MORE_PROCESSING_REQUIRED;
> }
> else if (STATUS_FLT_NOT_SAFE_TO_POST_OPERATION == Status)
> {
> DbgPrint(“Not safe to post operation\n”);
> }
> else
> {
> DbgPrint(“Failed post operation 0x%x\n”,Status);
> }
> }
> }
> return FLT_POSTOP_FINISHED_PROCESSING;
> }
>
>
> VOID MyFilterDelayedPostOpCB(IN PFLT_DEFERRED_IO_WORKITEM WorkItem,
> IN PFLT_CALLBACK_DATA CallbackData,
> IN PVOID CompletionContext)
> {
> PFLT_IO_PARAMETER_BLOCK Iopb = CallbackData->Iopb;
> PFLT_PARAMETERS Params = &Iopb->Parameters;
>
> DbgPrint(“DelayedPostOpCB. IRP_MJ=%ld\n”, Iopb->MajorFunction);
>
> FltCompletePendedPostOperation(CallbackData);
> FltFreeDeferredIoWorkItem(WorkItem);
> }
>
>
>
*************************************************************************
>

> *
> *
> * 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: f97c7452, The address that the exception occurred at
> Arg3: f798069c, 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:
> fltMgr!FltpCompleteCompletionNode+2c
> f97c7452 8b4008 mov eax,dword ptr [eax+8]
>
> TRAP_FRAME: f798069c – (.trap fffffffff798069c)
> ErrCode = 00000000
> eax=00000000 ebx=815d4064 ecx=815d40bc edx=00000001 esi=815d4008
> edi=815d4008
> eip=f97c7452 esp=f7980710 ebp=f7980714 iopl=0 nv up ei pl zr na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010246
> fltMgr!FltpCompleteCompletionNode+0x2c:
> f97c7452 8b4008 mov eax,dword ptr [eax+8]
> ds:0023:00000008=???
> Resetting default scope
>
> CUSTOMER_CRASH_COUNT: 1
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x8E
>
> PROCESS_NAME: ls.exe
>
> LAST_CONTROL_TRANSFER: from f97c7f06 to f97c7452
>
> STACK_TEXT:
> f7980714 f97c7f06 815d4008 00000000 815d4008
> fltMgr!FltpCompleteCompletionNode+0x2c
> f7980770 f97ca338 005d4008 00000000 815d4008
> fltMgr!FltpPerformPostCallbacks+0x1d8
> f7980784 f97ca867 815d4008 81907c88 f79807c4
> fltMgr!FltpProcessIoCompletion+0x10
> f7980794 f97caef9 81190368 81907c88 815d4008
> fltMgr!FltpPassThroughCompletion+0x89
> f79807c4 f97d7448 f79807e4 00000000 00000000
> fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x269
> f7980800 804eddf9 81190368 81907c88 81907c88 fltMgr!FltpCreate+0x26a
> f7980810 805773b4 819976c0 816bf8dc f79809b8 nt!IopfCallDriver+0x31
> f79808f0 805b3642 819976d8 00000000 816bf838 nt!IopParseDevice+0xa58
> f7980978 805afb23 00000000 f79809b8 00000240 nt!ObpLookupObjectName+0x56a
> f79809cc 8056a11d 00000000 00000000 710c8000 nt!ObOpenObjectByName+0xeb
> f7980a48 8056aa94 f7980bf4 00100180 f7980bd8 nt!IopCreateFile+0x407
> f7980aa4 8056d166 f7980bf4 00100180 f7980bd8 nt!IoCreateFile+0x8e
> f7980ae4 8053c808 f7980bf4 00100180 f7980bd8 nt!NtCreateFile+0x30
> f7980ae4 804fd569 f7980bf4 00100180 f7980bd8 nt!KiFastCallEntry+0xf8
> f7980b88 8061376f f7980bf4 00100180 f7980bd8 nt!ZwCreateFile+0x11
> f7980c18 806151a9 e1cf8f92 f7980c58 f7980c3c nt!CcPfQueryVolumeInfo+0x6b
> f7980c5c 80615856 01980c70 09485270 00000023
> nt!CcPfOpenVolumesForPrefetch+0xa3
> f7980c88 80615c9c e1cf7000 00080000 816e98a0 nt!CcPfPrefetchScenario+0x5e
> f7980d04 805c4953 816e98a0 e1da6790 00000000 nt!CcPfBeginAppLaunch+0x158
> f7980d50 80540fa2 00000000 7c810665 00000001 nt!PspUserThreadStartup+0xeb
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> fltMgr!FltpCompleteCompletionNode+2c
> f97c7452 8b4008 mov eax,dword ptr [eax+8]
>
> SYMBOL_STACK_INDEX: 0
>
> SYMBOL_NAME: fltMgr!FltpCompleteCompletionNode+2c
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: fltMgr
>
> IMAGE_NAME: fltMgr.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 44e97991
>
> FAILURE_BUCKET_ID: 0x8E_fltMgr!FltpCompleteCompletionNode+2c
>
> BUCKET_ID: 0x8E_fltMgr!FltpCompleteCompletionNode+2c
>
> Followup: MachineOwner
> ---------
>
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@grevans.demon.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com

There’s nothing else obviously wrong. Is the stack dump the same (where is
the ZwCreateFile coming from?)?

You may have to step through in a debugger to find out what’s going on.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gareth Evans
Sent: Thursday, October 19, 2006 8:06 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Using FltQueueDeferredIoWorkItem

Unfortunately after fixing the PostOp callback to return ReturnStatus I
still get the blue screen. So that’s something else I’m doing wrong :frowning:

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of sh_alex
Sent: 19 October 2006 12:47
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Using FltQueueDeferredIoWorkItem

Can the following be the reason: you prepare

ReturnStatus = FLT_POSTOP_MORE_PROCESSING_REQUIRED;

after a successful call to FltQueueDeferredIoWorkItem, but
return FLT_POSTOP_FINISHED_PROCESSING from
MyFilterPostOperationCB always.

Double completion follows…

----- Original Message -----
From: “Gareth Evans”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, October 19, 2006 7:09 AM
Subject: [ntfsd] Using FltQueueDeferredIoWorkItem

>I am just starting to investigate file system filter drivers, and thought
> I’d write some simple filters to try out some of the basic operations. One
> of my tests is to log information from certain operations to a log file
> (but
> I haven’t got that far). As I understand it neither a post-op routine nor
> a
> routine called by it using ‘FltDoCompletionProcessingWhenSafe’ should
> write
> to a file, as neither of these are guaranteed to be running at
> PASSIVE_LEVEL
> - required by ZwWriteFile.
>
> So I tried using ‘FltQueueDeferredIoWorkItem’ instead - but my work
> routine
> does nothing yet except a DbgPrint, FltCompletePendedPostOperation and
> FltFreeDeferredIoWorkItem - Full code for the post-op callback and
> deferred
> routine below. (Actually the work routine was calling ZwWriteFile but that
> all got stripped out when trying to isolate the bug).
>
> The problem is that whatever operations I use the callback on my system
> blue
> screens - I guess I must be doing something incredibly stupid or have
> missed
> something really obvious but I’m afraid I can’t see it. I haven’t yet
> found
> any examples of these calls, nor other relevant posts, so any help or
> pointers you can give me will be most gratefully received.
>
> The test environment is Windows XP SP2, running as virtual machine under
> VMWare. Could that be relevant?
>
> Thanks in advance,
> Gareth Evans
>
> _____________________________________
>
>
> FLT_POSTOP_CALLBACK_STATUS MyFilterPostOperationCB(
> IN OUT PFLT_CALLBACK_DATA CallbackData,
> IN PCFLT_RELATED_OBJECTS FltObjects,
> IN PVOID CompletionContext,
> IN FLT_POST_OPERATION_FLAGS Flags)
> {
> FLT_POSTOP_CALLBACK_STATUS ReturnStatus =
> FLT_POSTOP_FINISHED_PROCESSING;
> PFLT_IO_PARAMETER_BLOCK Iopb = CallbackData->Iopb;
>
> DbgPrint(“MyFilterPostOperationCB IRP_MJ=%ld\n”, Iopb->MajorFunction);
>
> if (FALSE == FlagOn(Flags,FLTFL_POST_OPERATION_DRAINING))
> {
> PFLT_DEFERRED_IO_WORKITEM WorkItem = NULL;
>
> WorkItem = FltAllocateDeferredIoWorkItem();
> if (NULL == WorkItem)
> {
> DbgPrint(“OUT OF MEMORY!\n”);
> }
> else
> {
> NTSTATUS Status;
>
> Status = FltQueueDeferredIoWorkItem(WorkItem,
> CallbackData,
> MyFilterDelayedPostOpCB,
> DelayedWorkQueue,
> CompletionContext);
> if (NT_SUCCESS(Status))
> {
> ReturnStatus = FLT_POSTOP_MORE_PROCESSING_REQUIRED;
> }
> else if (STATUS_FLT_NOT_SAFE_TO_POST_OPERATION == Status)
> {
> DbgPrint(“Not safe to post operation\n”);
> }
> else
> {
> DbgPrint(“Failed post operation 0x%x\n”,Status);
> }
> }
> }
> return FLT_POSTOP_FINISHED_PROCESSING;
> }
>
>
> VOID MyFilterDelayedPostOpCB(IN PFLT_DEFERRED_IO_WORKITEM WorkItem,
> IN PFLT_CALLBACK_DATA CallbackData,
> IN PVOID CompletionContext)
> {
> PFLT_IO_PARAMETER_BLOCK Iopb = CallbackData->Iopb;
> PFLT_PARAMETERS Params = &Iopb->Parameters;
>
> DbgPrint(“DelayedPostOpCB. IRP_MJ=%ld\n”, Iopb->MajorFunction);
>
> FltCompletePendedPostOperation(CallbackData);
> FltFreeDeferredIoWorkItem(WorkItem);
> }
>
>
>
*************************************************************************
>

> *
> *
> * 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: f97c7452, The address that the exception occurred at
> Arg3: f798069c, 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:
> fltMgr!FltpCompleteCompletionNode+2c
> f97c7452 8b4008 mov eax,dword ptr [eax+8]
>
> TRAP_FRAME: f798069c – (.trap fffffffff798069c)
> ErrCode = 00000000
> eax=00000000 ebx=815d4064 ecx=815d40bc edx=00000001 esi=815d4008
> edi=815d4008
> eip=f97c7452 esp=f7980710 ebp=f7980714 iopl=0 nv up ei pl zr na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010246
> fltMgr!FltpCompleteCompletionNode+0x2c:
> f97c7452 8b4008 mov eax,dword ptr [eax+8]
> ds:0023:00000008=???
> Resetting default scope
>
> CUSTOMER_CRASH_COUNT: 1
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x8E
>
> PROCESS_NAME: ls.exe
>
> LAST_CONTROL_TRANSFER: from f97c7f06 to f97c7452
>
> STACK_TEXT:
> f7980714 f97c7f06 815d4008 00000000 815d4008
> fltMgr!FltpCompleteCompletionNode+0x2c
> f7980770 f97ca338 005d4008 00000000 815d4008
> fltMgr!FltpPerformPostCallbacks+0x1d8
> f7980784 f97ca867 815d4008 81907c88 f79807c4
> fltMgr!FltpProcessIoCompletion+0x10
> f7980794 f97caef9 81190368 81907c88 815d4008
> fltMgr!FltpPassThroughCompletion+0x89
> f79807c4 f97d7448 f79807e4 00000000 00000000
> fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x269
> f7980800 804eddf9 81190368 81907c88 81907c88 fltMgr!FltpCreate+0x26a
> f7980810 805773b4 819976c0 816bf8dc f79809b8 nt!IopfCallDriver+0x31
> f79808f0 805b3642 819976d8 00000000 816bf838 nt!IopParseDevice+0xa58
> f7980978 805afb23 00000000 f79809b8 00000240 nt!ObpLookupObjectName+0x56a
> f79809cc 8056a11d 00000000 00000000 710c8000 nt!ObOpenObjectByName+0xeb
> f7980a48 8056aa94 f7980bf4 00100180 f7980bd8 nt!IopCreateFile+0x407
> f7980aa4 8056d166 f7980bf4 00100180 f7980bd8 nt!IoCreateFile+0x8e
> f7980ae4 8053c808 f7980bf4 00100180 f7980bd8 nt!NtCreateFile+0x30
> f7980ae4 804fd569 f7980bf4 00100180 f7980bd8 nt!KiFastCallEntry+0xf8
> f7980b88 8061376f f7980bf4 00100180 f7980bd8 nt!ZwCreateFile+0x11
> f7980c18 806151a9 e1cf8f92 f7980c58 f7980c3c nt!CcPfQueryVolumeInfo+0x6b
> f7980c5c 80615856 01980c70 09485270 00000023
> nt!CcPfOpenVolumesForPrefetch+0xa3
> f7980c88 80615c9c e1cf7000 00080000 816e98a0 nt!CcPfPrefetchScenario+0x5e
> f7980d04 805c4953 816e98a0 e1da6790 00000000 nt!CcPfBeginAppLaunch+0x158
> f7980d50 80540fa2 00000000 7c810665 00000001 nt!PspUserThreadStartup+0xeb
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> fltMgr!FltpCompleteCompletionNode+2c
> f97c7452 8b4008 mov eax,dword ptr [eax+8]
>
> SYMBOL_STACK_INDEX: 0
>
> SYMBOL_NAME: fltMgr!FltpCompleteCompletionNode+2c
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: fltMgr
>
> IMAGE_NAME: fltMgr.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 44e97991
>
> FAILURE_BUCKET_ID: 0x8E_fltMgr!FltpCompleteCompletionNode+2c
>
> BUCKET_ID: 0x8E_fltMgr!FltpCompleteCompletionNode+2c
>
> Followup: MachineOwner
> ---------
>
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@grevans.demon.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

Ah yes, the stack dump is different - attached. Fault is caused by the
post-op trying to queue the work item. But I must be a bit dim because I
still cannot see what is wrong with the call to FltQueueDeferredIoWorkItem

My post-op is currently only installed for IRP_MJ_READ & IRP_MJ_WRITE.
Interestingly enough using a DOS window & the ‘type f:\temp\myfile.txt’
works OK, and yet using a cygwin bash window & the ‘cat /f/temp/myfile.txt’
generates a blue screen.

****************************************************************************
***
*
*
* 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: f97ce184, The address that the exception occurred at
Arg3: f77d4b28, 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:
fltMgr!FltQueueDeferredIoWorkItem+c
f97ce184 f6400802 test byte ptr [eax+8],2

TRAP_FRAME: f77d4b28 – (.trap fffffffff77d4b28)
ErrCode = 00000000
eax=00000000 ebx=815d4064 ecx=816ce798 edx=00000000 esi=815d4064
edi=815d4008
eip=f97ce184 esp=f77d4b9c ebp=f77d4ba0 iopl=0 nv up ei ng nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010282
fltMgr!FltQueueDeferredIoWorkItem+0xc:
f97ce184 f6400802 test byte ptr [eax+8],2
ds:0023:00000008=??
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: cat.exe

LAST_CONTROL_TRANSFER: from f9f105f1 to f97ce184

STACK_TEXT:
f77d4ba0 f9f105f1 816ce798 815d4064 f9f104b0
fltMgr!FltQueueDeferredIoWorkItem+0xc
f77d4bcc f97c7ef3 815d4064 f77d4bf0 00000000
cfilter!MyFilterPostOperationCB+0x71
[e:\cofio\filterdriver\windows\cfilter.c @ 262]
f77d4c34 f97ca20c 005d4008 00670000 f77d4cc0
fltMgr!FltpPerformPostCallbacks+0x1c5
f77d4c4c f97d57bc 007d4c6c 0022c960 819a1178
fltMgr!FltpPassThroughFastIo+0xa0
f77d4c8c 805708d7 811a6768 f77d4cc8 00000400 fltMgr!FltpFastIoRead+0x148
f77d4d38 8053c808 00000738 00000000 00000000 nt!NtReadFile+0x2d5
f77d4d38 7c90eb94 00000738 00000000 00000000 nt!KiFastCallEntry+0xf8
WARNING: Frame IP not in any known module. Following frames may be wrong.
0022c988 00000000 00000000 00000000 00000000 0x7c90eb94

STACK_COMMAND: kb

FOLLOWUP_IP:
cfilter!MyFilterPostOperationCB+71 [e:\cofio\filterdriver\windows\cfilter.c
@ 262]
f9f105f1 8945f0 mov dword ptr [ebp-10h],eax

FAULTING_SOURCE_CODE:
258: Status = FltQueueDeferredIoWorkItem(WorkItem,
259: CallbackData,
260: MyFilterDelayedPostOpCB,
261: DelayedWorkQueue,

262: CompletionContext);
263: if (NT_SUCCESS(Status))
264: {
265: ReturnStatus = FLT_POSTOP_MORE_PROCESSING_REQUIRED;
266: }
267: else if (STATUS_FLT_NOT_SAFE_TO_POST_OPERATION == Status)

SYMBOL_STACK_INDEX: 1

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: cfilter

IMAGE_NAME: cfilter.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 453768cb

SYMBOL_NAME: cfilter!MyFilterPostOperationCB+71

FAILURE_BUCKET_ID: 0x8E_cfilter!MyFilterPostOperationCB+71

BUCKET_ID: 0x8E_cfilter!MyFilterPostOperationCB+71

Followup: MachineOwner

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
Sent: 19 October 2006 13:39
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Using FltQueueDeferredIoWorkItem

There’s nothing else obviously wrong. Is the stack dump the same (where is
the ZwCreateFile coming from?)?

You may have to step through in a debugger to find out what’s going on.

Ken

Have you ensured that you are only using FltQueueDeferredIoWorkItem for IRP
based operations, and not for Fast I/O?

It appears that the routine is unexpectedly getting a null pointer out of
the callback data (perhaps the IRP address?).

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gareth Evans
Sent: Thursday, October 19, 2006 7:10 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Using FltQueueDeferredIoWorkItem

Ah yes, the stack dump is different - attached. Fault is caused by the
post-op trying to queue the work item. But I must be a bit dim because I
still cannot see what is wrong with the call to FltQueueDeferredIoWorkItem

My post-op is currently only installed for IRP_MJ_READ & IRP_MJ_WRITE.
Interestingly enough using a DOS window & the ‘type f:\temp\myfile.txt’
works OK, and yet using a cygwin bash window & the ‘cat /f/temp/myfile.txt’
generates a blue screen.

****************************************************************************
***
*
*
* 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: f97ce184, The address that the exception occurred at
Arg3: f77d4b28, 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:
fltMgr!FltQueueDeferredIoWorkItem+c
f97ce184 f6400802 test byte ptr [eax+8],2

TRAP_FRAME: f77d4b28 – (.trap fffffffff77d4b28)
ErrCode = 00000000
eax=00000000 ebx=815d4064 ecx=816ce798 edx=00000000 esi=815d4064
edi=815d4008
eip=f97ce184 esp=f77d4b9c ebp=f77d4ba0 iopl=0 nv up ei ng nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282
fltMgr!FltQueueDeferredIoWorkItem+0xc:
f97ce184 f6400802 test byte ptr [eax+8],2
ds:0023:00000008=??
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: cat.exe

LAST_CONTROL_TRANSFER: from f9f105f1 to f97ce184

STACK_TEXT:
f77d4ba0 f9f105f1 816ce798 815d4064 f9f104b0
fltMgr!FltQueueDeferredIoWorkItem+0xc
f77d4bcc f97c7ef3 815d4064 f77d4bf0 00000000
cfilter!MyFilterPostOperationCB+0x71
[e:\cofio\filterdriver\windows\cfilter.c @ 262]
f77d4c34 f97ca20c 005d4008 00670000 f77d4cc0
fltMgr!FltpPerformPostCallbacks+0x1c5
f77d4c4c f97d57bc 007d4c6c 0022c960 819a1178
fltMgr!FltpPassThroughFastIo+0xa0 f77d4c8c 805708d7 811a6768 f77d4cc8
00000400 fltMgr!FltpFastIoRead+0x148 f77d4d38 8053c808 00000738 00000000
00000000 nt!NtReadFile+0x2d5 f77d4d38 7c90eb94 00000738 00000000 00000000
nt!KiFastCallEntry+0xf8
WARNING: Frame IP not in any known module. Following frames may be wrong.
0022c988 00000000 00000000 00000000 00000000 0x7c90eb94

STACK_COMMAND: kb

FOLLOWUP_IP:
cfilter!MyFilterPostOperationCB+71 [e:\cofio\filterdriver\windows\cfilter.c
@ 262]
f9f105f1 8945f0 mov dword ptr [ebp-10h],eax

FAULTING_SOURCE_CODE:
258: Status = FltQueueDeferredIoWorkItem(WorkItem,
259: CallbackData,
260: MyFilterDelayedPostOpCB,
261: DelayedWorkQueue,

262: CompletionContext);
263: if (NT_SUCCESS(Status))
264: {
265: ReturnStatus = FLT_POSTOP_MORE_PROCESSING_REQUIRED;
266: }
267: else if (STATUS_FLT_NOT_SAFE_TO_POST_OPERATION == Status)

SYMBOL_STACK_INDEX: 1

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: cfilter

IMAGE_NAME: cfilter.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 453768cb

SYMBOL_NAME: cfilter!MyFilterPostOperationCB+71

FAILURE_BUCKET_ID: 0x8E_cfilter!MyFilterPostOperationCB+71

BUCKET_ID: 0x8E_cfilter!MyFilterPostOperationCB+71

Followup: MachineOwner

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
Sent: 19 October 2006 13:39
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Using FltQueueDeferredIoWorkItem

There’s nothing else obviously wrong. Is the stack dump the same (where is
the ZwCreateFile coming from?)?

You may have to step through in a debugger to find out what’s going on.

Ken


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

No, I hadn’t ensured that I was only using FltQueueDeferredIoWorkItem for IRP based operations, and not for Fast I/O. Adding

if (FALSE == FLT_IS_IRP_OPERATION(CallbackData))

before trying to defer has stopped the blue screens. As I should have spotted from the IFS Kit help.

Sorry, and many thanks for everyone’s help.

I wonder if the MS Filter Manager team might consider returning
STATUS_INVALID_PARAMETER (or STATUS_FLT_NOT_IRP_OP) in this case, instead of
dereferencing the null pointer and accvioing.

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@grevans.demon.co.uk
Sent: Thursday, October 19, 2006 10:31 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Using FltQueueDeferredIoWorkItem

No, I hadn’t ensured that I was only using FltQueueDeferredIoWorkItem for
IRP based operations, and not for Fast I/O. Adding

if (FALSE == FLT_IS_IRP_OPERATION(CallbackData))

before trying to defer has stopped the blue screens. As I should have
spotted from the IFS Kit help.

Sorry, and many thanks for everyone’s help.


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

ROFL @ the word :wink:

Dan Kyler wrote:

accvioing.


King regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.

Glad you enjoyed it. It comes from VMS, where the equivalent of
STATUS_ACCESS_VIOLATION is SS$_ACCVIO.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dejan Maksimovic
Sent: Thursday, October 19, 2006 1:00 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Using FltQueueDeferredIoWorkItem

ROFL @ the word :wink:

Dan Kyler wrote:

accvioing.


King regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com