page fault when calling FltSetInformationFile

NTFSD
1

I hope someone can help with the following problem. I have developed a
function to rename files which uses FltSetInformationFile. I use the
function from two different places in my filter diver (a minidriver,
actually).

When called from the PreOp for IRP_MJ_CLEANUP it works out allright. When I
call it from a
DeferredIoWorkItem (of IRP_MJ_SET_INFORMATION ) it crashes within
FltSetInformationFile.

For the record, in my PostOp for IRP_MJ_SET_INFORMATION I detect if a file
has been renamed and if it has I queue a deferred Io work item, which,
AFAIK, runs at PASSIVE_LEVEL.

Any suggestion?

thanks,

Marco

The debugger tells me that it fails within FltSetInformationFile:

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

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by
try-except,
it must be protected by a Probe. Typically the address is just plain bad or
it
is pointing at freed memory.
Arguments:
Arg1: f25ac01c, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: baf284ae, If non-zero, the instruction address which referenced the
bad memory
address.
Arg4: 00000000, (reserved)

Debugging Details:

READ_ADDRESS: f25ac01c Nonpaged pool

FAULTING_IP:
fltmgr!FltAllocateCallbackData+c
baf284ae 8b401c mov eax,[eax+0x1c]

MM_INTERNAL_CODE: 0

IMAGE_NAME: fltmgr.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41107bad

MODULE_NAME: fltmgr

FAULTING_MODULE: baf24000 fltmgr

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x50

LAST_CONTROL_TRANSFER: from baf36bdf to baf284ae

TRAP_FRAME: f88f6854 -- (.trap fffffffff88f6854)
ErrCode = 00000000
eax=f25ac000 ebx=00000000 ecx=f25abbbc edx=824343b0 esi=824343b0
edi=828b8ec0
eip=baf284ae esp=f88f68c8 ebp=f88f68cc iopl=0 nv up ei pl zr na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
fltmgr!FltAllocateCallbackData+0xc:
baf284ae 8b401c mov eax,[eax+0x1c]
Resetting default scope

STACK_TEXT:
f88f68cc baf36bdf 824343b0 ffdff538 f88f68e4
fltmgr!FltAllocateCallbackData+0xc
f88f68ec f8898c70 824343b0 ffdff538 8307afd8
fltmgr!FltSetInformationFile+0x1f
f88f6914 f8897a93 e1cc0884 f25abbbc f88f6930 ick!RenameFile+0xc0 [xxx.cpp @
2263]
f88f6d64 baf3b272 828b8ec0 8248ec7c f25abbbc
ick!ICKDeferredPostSetInfo+0x1f3 [xxx.cpp @ 1521]
f88f6d7c 8080b3b5 828b8ec0 00000000 82ada3c8
fltmgr!FltpProcessDeferredIoWorkItem+0x16
f88f6dac 8089d128 828b8ec0 00000000 00000000 nt!ExpWorkerThread+0xef
f88f6ddc 80818c81 8080b2f1 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
fltmgr!FltAllocateCallbackData+c
baf284ae 8b401c mov eax,[eax+0x1c]

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: fltmgr!FltAllocateCallbackData+c

STACK_COMMAND: .trap fffffffff88f6854 ; kb

FAILURE_BUCKET_ID: 0x50_fltmgr!FltAllocateCallbackData+c

BUCKET_ID: 0x50_fltmgr!FltAllocateCallbackData+c

Followup: MachineOwner

***********************

here is a disassebly:

fltmgr!FltAllocateCallbackData:
baf284a2 8bff mov edi,edi
baf284a4 55 push ebp
baf284a5 8bec mov ebp,esp
baf284a7 56 push esi
baf284a8 8b7508 mov esi,[ebp+0x8]
baf284ab 8b4618 mov eax,[esi+0x18]
baf284ae 8b401c mov eax,[eax+0x1c] << bang!
baf284b1 57 push edi

and the PCR:

1: kd> !pcr
KPCR for Processor 1 at f872f000:
Major 1 Minor 1
NtTib.ExceptionList: f88f5ca4
NtTib.StackBase: f88f6df0
NtTib.StackLimit: f88f4000
NtTib.SubSystemTib: 00000000
NtTib.Version: 00000000
NtTib.UserPointer: 00000000
NtTib.SelfTib: 00000000

SelfPcr: f872f000
Prcb: f872f120
Irql: 00000000
IRR: 00000000
IDR: ffffffff
InterruptMode: 00000000
IDT: f8733560
GDT: f8733160
TSS: f872fd70

CurrentThread: 82ada3c8
NextThread: 00000000
IdleThread: f8731e20

DpcQueue:

--
Marco [www.neovalens.com]

2

Can you confirm that you are: (a) running under driver verifier (which
would suggest that whatever failed in this case was NOT under verifier,
since that would have bug checked in a special pool block); and (b) are
using a checked build of the filter manager?

The block of memory (whatever f25ac000 represents) has been freed.
Since it isn't very far into the function (0xc) this is likely to be
very closely related to whatever was passed into this function from the
previous call.

My guess is that you are using (or relying upon) some value that has
been freed; in the case where you do it immediately, the block is still
valid, but afterwards, the block is freed.

Go back, look at the code sequence leading up to this point. Figure out
where the value in EAX originated - that's going to tell you what EAX
represents. That's likely to be the "aha" and you'll know you need to
bump a reference count before you queue the work item.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.

P.S. In general, using system work threads for doing anything in a file
system filter driver is potentially dangerous, particularly when you
call back into the underlying file system. We continue to see periodic
deadlocks (out in the real world) due to interactions with the file
systems which also use such work threads because eventually we have
worker threads blocked waiting for work items that need worker threads
to service the work item. That's not your problem now, but I thought it
worth reiterating this warning once again.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Marco Peretti
Sent: Tuesday, May 24, 2005 9:48 AM
To: ntfsd redirect
Subject: [ntfsd] page fault when calling FltSetInformationFile

I hope someone can help with the following problem. I have developed a
function to rename files which uses FltSetInformationFile. I use the
function from two different places in my filter diver (a minidriver,
actually).

When called from the PreOp for IRP_MJ_CLEANUP it works out allright.
When I
call it from a
DeferredIoWorkItem (of IRP_MJ_SET_INFORMATION ) it crashes within
FltSetInformationFile.

For the record, in my PostOp for IRP_MJ_SET_INFORMATION I detect if a
file
has been renamed and if it has I queue a deferred Io work item, which,
AFAIK, runs at PASSIVE_LEVEL.

Any suggestion?

thanks,

Marco

The debugger tells me that it fails within FltSetInformationFile:

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

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by
try-except,
it must be protected by a Probe. Typically the address is just plain
bad or
it
is pointing at freed memory.
Arguments:
Arg1: f25ac01c, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: baf284ae, If non-zero, the instruction address which referenced
the
bad memory
address.
Arg4: 00000000, (reserved)

Debugging Details:

READ_ADDRESS: f25ac01c Nonpaged pool

FAULTING_IP:
fltmgr!FltAllocateCallbackData+c
baf284ae 8b401c mov eax,[eax+0x1c]

MM_INTERNAL_CODE: 0

IMAGE_NAME: fltmgr.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41107bad

MODULE_NAME: fltmgr

FAULTING_MODULE: baf24000 fltmgr

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x50

LAST_CONTROL_TRANSFER: from baf36bdf to baf284ae

TRAP_FRAME: f88f6854 -- (.trap fffffffff88f6854)
ErrCode = 00000000
eax=f25ac000 ebx=00000000 ecx=f25abbbc edx=824343b0 esi=824343b0
edi=828b8ec0
eip=baf284ae esp=f88f68c8 ebp=f88f68cc iopl=0 nv up ei pl zr na
po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
fltmgr!FltAllocateCallbackData+0xc:
baf284ae 8b401c mov eax,[eax+0x1c]
Resetting default scope

STACK_TEXT:
f88f68cc baf36bdf 824343b0 ffdff538 f88f68e4
fltmgr!FltAllocateCallbackData+0xc
f88f68ec f8898c70 824343b0 ffdff538 8307afd8
fltmgr!FltSetInformationFile+0x1f
f88f6914 f8897a93 e1cc0884 f25abbbc f88f6930 ick!RenameFile+0xc0
[xxx.cpp @
2263]
f88f6d64 baf3b272 828b8ec0 8248ec7c f25abbbc
ick!ICKDeferredPostSetInfo+0x1f3 [xxx.cpp @ 1521]
f88f6d7c 8080b3b5 828b8ec0 00000000 82ada3c8
fltmgr!FltpProcessDeferredIoWorkItem+0x16
f88f6dac 8089d128 828b8ec0 00000000 00000000 nt!ExpWorkerThread+0xef
f88f6ddc 80818c81 8080b2f1 00000001 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
fltmgr!FltAllocateCallbackData+c
baf284ae 8b401c mov eax,[eax+0x1c]

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: fltmgr!FltAllocateCallbackData+c

STACK_COMMAND: .trap fffffffff88f6854 ; kb

FAILURE_BUCKET_ID: 0x50_fltmgr!FltAllocateCallbackData+c

BUCKET_ID: 0x50_fltmgr!FltAllocateCallbackData+c

Followup: MachineOwner

***********************

here is a disassebly:

fltmgr!FltAllocateCallbackData:
baf284a2 8bff mov edi,edi
baf284a4 55 push ebp
baf284a5 8bec mov ebp,esp
baf284a7 56 push esi
baf284a8 8b7508 mov esi,[ebp+0x8]
baf284ab 8b4618 mov eax,[esi+0x18]
baf284ae 8b401c mov eax,[eax+0x1c] << bang!
baf284b1 57 push edi

and the PCR:

1: kd> !pcr
KPCR for Processor 1 at f872f000:
Major 1 Minor 1
NtTib.ExceptionList: f88f5ca4
NtTib.StackBase: f88f6df0
NtTib.StackLimit: f88f4000
NtTib.SubSystemTib: 00000000
NtTib.Version: 00000000
NtTib.UserPointer: 00000000
NtTib.SelfTib: 00000000

SelfPcr: f872f000
Prcb: f872f120
Irql: 00000000
IRR: 00000000
IDR: ffffffff
InterruptMode: 00000000
IDT: f8733560
GDT: f8733160
TSS: f872fd70

CurrentThread: 82ada3c8
NextThread: 00000000
IdleThread: f8731e20

DpcQueue:

--
Marco [www.neovalens.com]

Questions? First check the IFS FAQ at

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

3

Tony,

thank you for your comments. I am indeed running the checked build with
driver verifier on.

I suspect that the bug I am seeing is related to the FltObjects being freed.

From my PostOP, I queue the work item as follows:

status = FltQueueDeferredIoWorkItem( pIo, // work item
Cbd, // callback data
&ICKDeferredPostSetInfo, // workitem routine
DelayedWorkQueue, // QueueType,
(PVOID)FltObjects // Context
);

and from within my workitem routine I call FltSetInformationFile passing in
the FltObject I got as a context parameter.

I do return FLT_POSTOP_MORE_PROCESSING_REQUIRED from my PostOp but that will
not keep the file object around.

Gee, I'll have to re-think my design! it seemed to simple to be true :wink:

thanks,

Marco

--
Marco [www.neovalens.com]

"Tony Mason" wrote in message news:xxxxx@ntfsd...
Can you confirm that you are: (a) running under driver verifier (which
would suggest that whatever failed in this case was NOT under verifier,
since that would have bug checked in a special pool block); and (b) are
using a checked build of the filter manager?

The block of memory (whatever f25ac000 represents) has been freed.
Since it isn't very far into the function (0xc) this is likely to be
very closely related to whatever was passed into this function from the
previous call.

My guess is that you are using (or relying upon) some value that has
been freed; in the case where you do it immediately, the block is still
valid, but afterwards, the block is freed.

Go back, look at the code sequence leading up to this point. Figure out
where the value in EAX originated - that's going to tell you what EAX
represents. That's likely to be the "aha" and you'll know you need to
bump a reference count before you queue the work item.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

P.S. In general, using system work threads for doing anything in a file
system filter driver is potentially dangerous, particularly when you
call back into the underlying file system. We continue to see periodic
deadlocks (out in the real world) due to interactions with the file
systems which also use such work threads because eventually we have
worker threads blocked waiting for work items that need worker threads
to service the work item. That's not your problem now, but I thought it
worth reiterating this warning once again.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Marco Peretti
Sent: Tuesday, May 24, 2005 9:48 AM
To: ntfsd redirect
Subject: [ntfsd] page fault when calling FltSetInformationFile

I hope someone can help with the following problem. I have developed a
function to rename files which uses FltSetInformationFile. I use the
function from two different places in my filter diver (a minidriver,
actually).

When called from the PreOp for IRP_MJ_CLEANUP it works out allright.
When I
call it from a
DeferredIoWorkItem (of IRP_MJ_SET_INFORMATION ) it crashes within
FltSetInformationFile.

For the record, in my PostOp for IRP_MJ_SET_INFORMATION I detect if a
file
has been renamed and if it has I queue a deferred Io work item, which,
AFAIK, runs at PASSIVE_LEVEL.

Any suggestion?

thanks,

Marco

The debugger tells me that it fails within FltSetInformationFile:

***********************************************************


Bugcheck Analysis



*****************************************************************

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by
try-except,
it must be protected by a Probe. Typically the address is just plain
bad or
it
is pointing at freed memory.
Arguments:
Arg1: f25ac01c, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: baf284ae, If non-zero, the instruction address which referenced
the
bad memory
address.
Arg4: 00000000, (reserved)

Debugging Details:
------------------

READ_ADDRESS: f25ac01c Nonpaged pool

FAULTING_IP:
fltmgr!FltAllocateCallbackData+c
baf284ae 8b401c mov eax,[eax+0x1c]

MM_INTERNAL_CODE: 0

IMAGE_NAME: fltmgr.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41107bad

MODULE_NAME: fltmgr

FAULTING_MODULE: baf24000 fltmgr

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x50

LAST_CONTROL_TRANSFER: from baf36bdf to baf284ae

TRAP_FRAME: f88f6854 -- (.trap fffffffff88f6854)
ErrCode = 00000000
eax=f25ac000 ebx=00000000 ecx=f25abbbc edx=824343b0 esi=824343b0
edi=828b8ec0
eip=baf284ae esp=f88f68c8 ebp=f88f68cc iopl=0 nv up ei pl zr na
po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
fltmgr!FltAllocateCallbackData+0xc:
baf284ae 8b401c mov eax,[eax+0x1c]
Resetting default scope

STACK_TEXT:
f88f68cc baf36bdf 824343b0 ffdff538 f88f68e4
fltmgr!FltAllocateCallbackData+0xc
f88f68ec f8898c70 824343b0 ffdff538 8307afd8
fltmgr!FltSetInformationFile+0x1f
f88f6914 f8897a93 e1cc0884 f25abbbc f88f6930 ick!RenameFile+0xc0
[xxx.cpp @
2263]
f88f6d64 baf3b272 828b8ec0 8248ec7c f25abbbc
ick!ICKDeferredPostSetInfo+0x1f3 [xxx.cpp @ 1521]
f88f6d7c 8080b3b5 828b8ec0 00000000 82ada3c8
fltmgr!FltpProcessDeferredIoWorkItem+0x16
f88f6dac 8089d128 828b8ec0 00000000 00000000 nt!ExpWorkerThread+0xef
f88f6ddc 80818c81 8080b2f1 00000001 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
fltmgr!FltAllocateCallbackData+c
baf284ae 8b401c mov eax,[eax+0x1c]

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: fltmgr!FltAllocateCallbackData+c

STACK_COMMAND: .trap fffffffff88f6854 ; kb

FAILURE_BUCKET_ID: 0x50_fltmgr!FltAllocateCallbackData+c

BUCKET_ID: 0x50_fltmgr!FltAllocateCallbackData+c

Followup: MachineOwner
---------

***********************

here is a disassebly:

fltmgr!FltAllocateCallbackData:
baf284a2 8bff mov edi,edi
baf284a4 55 push ebp
baf284a5 8bec mov ebp,esp
baf284a7 56 push esi
baf284a8 8b7508 mov esi,[ebp+0x8]
baf284ab 8b4618 mov eax,[esi+0x18]
baf284ae 8b401c mov eax,[eax+0x1c] << bang!
baf284b1 57 push edi

and the PCR:

1: kd> !pcr
KPCR for Processor 1 at f872f000:
Major 1 Minor 1
NtTib.ExceptionList: f88f5ca4
NtTib.StackBase: f88f6df0
NtTib.StackLimit: f88f4000
NtTib.SubSystemTib: 00000000
NtTib.Version: 00000000
NtTib.UserPointer: 00000000
NtTib.SelfTib: 00000000

SelfPcr: f872f000
Prcb: f872f120
Irql: 00000000
IRR: 00000000
IDR: ffffffff
InterruptMode: 00000000
IDT: f8733560
GDT: f8733160
TSS: f872fd70

CurrentThread: 82ada3c8
NextThread: 00000000
IdleThread: f8731e20

DpcQueue:

--
Marco [www.neovalens.com]
--

---
Questions? First check the IFS FAQ at
The NT Insider:Windows NT Virtual Memory (Part I)

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

4

Marco,

As you surmise, FltObjects is not valid in a posted thread. Copy the
structure into some memory you control before you post.

5

Rod

as I had the file name anyway, I ended up forgetting about the file object
and using ZwOpenFile and ZwSetInformationFile.
The doc says also that the FltObjects is only valid in the context of the
callback so I am not sure that simply copying it would work.
Interesting idea though .. thanks!

cheers,

Marco

--
Marco [www.neovalens.com]

"Rod Widdowson" wrote in message news:xxxxx@ntfsd...
> Marco,
>
> As you surmise, FltObjects is not valid in a posted thread. Copy the
> structure into some memory you control before you post.
>
>
>

6

> The doc says also that the FltObjects is only valid in the context of the

callback so I am not sure that simply copying it would work.

I wouldn’t want to make any assumptions about FltObjects->Transaction
without careful thought, but I’d be suprised if any of the other fields
(FileObject, Filter, Volume or Instance) becoming invalid until the IO is
complete (which is the cue for Neil to say I’m wrong of course).

FWIW I try to avoid using ZwXXX in minifilters, the chances are that I’ll be
more future proof and less reentrant that way…

/r

7

>>> FWIW I try to avoid using ZwXXX in minifilters

do you mean I should use the NtXXX version or not at all?

cheers,

--
Marco [www.neovalens.com]

"Rod Widdowson" wrote in message news:xxxxx@ntfsd...
>> The doc says also that the FltObjects is only valid in the context of the
>> callback so I am not sure that simply copying it would work.
>
> I wouldn't want to make any assumptions about FltObjects->Transaction
> without careful thought, but I'd be suprised if any of the other fields
> (FileObject, Filter, Volume or Instance) becoming invalid until the IO is
> complete (which is the cue for Neil to say I'm wrong of course).
>
> FWIW I try to avoid using ZwXXX in minifilters, the chances are that I'll
> be more future proof and less reentrant that way....
>
> /r
>
>

8

No, use FltXXX versions.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Marco Peretti
Sent: Thursday, May 26, 2005 11:31 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] page fault when calling FltSetInformationFile

>> FWIW I try to avoid using ZwXXX in minifilters

do you mean I should use the NtXXX version or not at all?

cheers,

--
Marco [www.neovalens.com]

"Rod Widdowson" wrote in message news:xxxxx@ntfsd...
>> The doc says also that the FltObjects is only valid in the context of the

>> callback so I am not sure that simply copying it would work.
>
> I wouldn't want to make any assumptions about FltObjects->Transaction
> without careful thought, but I'd be suprised if any of the other fields
> (FileObject, Filter, Volume or Instance) becoming invalid until the IO is
> complete (which is the cue for Neil to say I'm wrong of course).
>
> FWIW I try to avoid using ZwXXX in minifilters, the chances are that I'll
> be more future proof and less reentrant that way....
>
> /r
>
>

---
Questions? First check the IFS FAQ at
The NT Insider:Windows NT Virtual Memory (Part I)

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

9

> do you mean I should use the NtXXX version or not at all?

I try to use the FltXXX versions if there is one, and there usually is. My
leitmotif when doing a minifilter has become ‘if you are typing too much
code, look and see whether there is an Flt version’.

/rod

10

Rod, Ken

thank you both. Indeed the doc says that: Minifilters must use
FltSetInformationFile , not ZwSetInformationFile, to rename a file. I wasn’t
aware of it, and a scan of the minifilter samples show that Zw functions are
only used for registry stuff.

thanks,

Marco

“Rod Widdowson” wrote in message news:xxxxx@ntfsd…
>> do you mean I should use the NtXXX version or not at all?
>
> I try to use the FltXXX versions if there is one, and there usually is.
> My leitmotif when doing a minifilter has become ‘if you are typing too
> much code, look and see whether there is an Flt version’.
>
> /rod
>
>

11

The FltObjects structure passed into the pre- and post-operation
callbacks is a local on the stack of the calling routine so obviously
this disappears when you return.

It is OK to copy the contents of the FltObjects structure but it is your
responsibility to reference the objects you are going to use to make
sure they don’t disappear by the time your worker thread runs.

For example you should reference the file object before queuing the
worker thread and then dereference it in your worker thread when you are
done with it.

Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
Rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Rod Widdowson
Sent: Thursday, May 26, 2005 5:53 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] page fault when calling FltSetInformationFile

The doc says also that the FltObjects is only valid in the context of
the
callback so I am not sure that simply copying it would work.

I wouldn’t want to make any assumptions about FltObjects->Transaction
without careful thought, but I’d be suprised if any of the other fields
(FileObject, Filter, Volume or Instance) becoming invalid until the IO
is
complete (which is the cue for Neil to say I’m wrong of course).

FWIW I try to avoid using ZwXXX in minifilters, the chances are that
I’ll be
more future proof and less reentrant that way…

/r

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

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