2 questions about PreCreate() and PostCreate()

Michael_Zhu · November 24, 2009, 3:56pm

Hi guys, I have 2 questions about PreCreate() and PostCreate() callbacks.

For PreCreate(), Under what conditions, the passed in
FltObjects->FileObject could be NULL? And why?
According to my test, in PostCreate(), if the operation fails, the
contents of the FileName buffer were changed. The FileName.Length was
changed to 1 in my case. And I want to reissue the create with
FltReissueSynchronousIo(). So I saved the original name in PreCreate routine
by allocating a new buffer. Before I reissue the create in PostCreate() I
restored the original name. My question is: at this point what I should do
to the original FileName.Buffer? Is it reasonable and safe to explicitly
free the file name buffer?

Thanks.

OSR_Community_User · November 25, 2009, 2:33am

I don’t think that FltObjects->FileObject can be NULL ever.
My filters don’t even have a check for this field in the PreCreate.
And they seem to be working fine in various deployments.

FltObjects->FileObject->FileName.Buffer can be NULL. I guess this is when someone is opening a handle to the volume.

With regards to management of the memory.
You can free buffer pointed by FileName.Buffer yourself using ExFreePool.
The I/O manager will free the memory allocated by you.
Ensure you allocate memory using ExAllocatePool from Non Paged memory pool.

Aditya_Shrivastava · November 25, 2009, 4:29am

>>You can free buffer pointed by FileName.Buffer yourself using ExFreePool.

Its allocated by FltMgr, as a basic rule you are not suppose to alter it. if you have to change some thing you should change it inside parameter block as described in documentation.

“The contents of the FLT_RELATED_OBJECTS structure are set by the filter manager. Minifilter drivers cannot directly modify the contents of this structure. However, if a minifilter driver modifies the target instance or target file object for an I/O operation in the FLT_IO_PARAMETER_BLOCK structure for the operation, the filter manager modifies the value of the corresponding Instance or FileObject member of the FLT_RELATED_OBJECTS structure that is passed to lower minifilter drivers.”

Another thing which one should consider is that if the memory does not belongs to you or if the protocol(if any) stated by the owner do not mention that you are authorized to free it, you shouldn’t.

Although You can go to caller assembly and verify what it is calling to allocate and use its counter part to de-allocate but that can fail in future release, so better avoid this path. For example If we assume that FltMgr has allocated memory using ExAllocatePool that in later version it may use some lookaside list or some other mechnism, which we will break in case we free the memory.

>The I/O manager will free the memory allocated by you.

ExFreePool does not belongs to IoManager, its provided by Executive.

>Ensure you allocate memory using ExAllocatePool from Non Paged memory pool.

file objects are allocated using non-paged memory, but here OP is concerned about the name buffer, which can be allocated from paged pool, in fact FltMgr also allocates it from paged pool. I verified it my self and following are the steps taken.

kb
ChildEBP RetAddr Args to Child
f69abc28 f7743944 866a4624 f69abc48 f69abc78 scanner!ScannerPreDirectory [c:\winddk\6001.18001\src\filesys\minifilter\my_scanner\filter\scanner.c @ 1397]
f69abc88 f7745352 009abcd0 00000000 f69abcd0 fltMgr!FltpPerformPreCallbacks+0x2d4
f69abc9c f7745c15 f69abcd0 00000000 863c7858 fltMgr!FltpPassThroughInternal+0x32
f69abcb8 f7745ffb f69abc00 86564fb8 867cd280 fltMgr!FltpPassThrough+0x1df
f69abce8 804e19ee 865ce020 8662b9f8 80703410 fltMgr!FltpDispatch+0xf3
f69abcf8 8057184c f69abd64 0012f624 805844f6 nt!IopfCallDriver+0x31

dt _FLT_RELATED_OBJECTS 0xf69abc48
+0x000 Size : 0x18
+0x002 Reserved : 0
+0x004 Filter : 0x866cdea8 _FLT_FILTER
+0x008 Volume : 0x863c7858 _FLT_VOLUME
+0x00c Instance : 0x867162e8 _FLT_INSTANCE
+0x010 FileObject : 0x86616400 _FILE_OBJECT
+0x014 Transaction : (null)

1: kd> !pool 0x86616400
Pool page 86616400 region is Nonpaged pool

1: kd> dt _file_object 0x86616400
ntdll!_FILE_OBJECT
+0x000 Type : 5
+0x002 Size : 112
+0x004 DeviceObject : 0x8677d030 _DEVICE_OBJECT
+0x008 Vpb : 0x8677f7a0 _VPB
+0x00c FsContext : 0xe14f0d20
+0x010 FsContext2 : 0xe1847940
+0x014 SectionObjectPointer : (null)
+0x018 PrivateCacheMap : (null)
+0x01c FinalStatus : 0
+0x020 RelatedFileObject : (null)
+0x024 LockOperation : 0 ‘’
+0x025 DeletePending : 0 ‘’
+0x026 ReadAccess : 0x1 ‘’
+0x027 WriteAccess : 0 ‘’
+0x028 DeleteAccess : 0 ‘’
+0x029 SharedRead : 0x1 ‘’
+0x02a SharedWrite : 0x1 ‘’
+0x02b SharedDelete : 0 ‘’
+0x02c Flags : 0x40002
+0x030 FileName : _UNICODE_STRING “\Documents and Settings\All Users\Application Data\VMware\VMware Tools”
+0x038 CurrentByteOffset : _LARGE_INTEGER 0x0
+0x040 Waiters : 0
+0x044 Busy : 1
+0x048 LastLock : (null)
+0x04c Lock : _KEVENT
+0x05c Event : _KEVENT
+0x06c CompletionContext : (null)

1: kd> dt _UNICODE_STRING 0x86616400 + 0x30
“\Documents and Settings\All Users\Application Data\VMware\VMware Tools”
+0x000 Length : 0x8c
+0x002 MaximumLength : 0xf8
+0x004 Buffer : 0xe1577a68 “\Documents and Settings\All Users\Application Data\VMware\VMware Tools”

1: kd> !pool 0xe1577a68
Pool page e1577a68 region is Paged pool

Aditya_Shrivastava · November 25, 2009, 4:46am

>> According to my test, in PostCreate(), if the operation fails, the contents of the FileName buffer were changed. The FileName.Length was changed to 1 in my case.

True, but what make you think that the actual buffer is truncated, have you checked the MaximumLength field?

Ayush_Gupta-2 · November 25, 2009, 7:06am

Well, the FileName.Length CANNOT be 1 for a valid UNICODE_STRING.

Regards,
Ayush Gupta
AI Consulting

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Wednesday, November 25, 2009 3:18 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] 2 questions about PreCreate() and PostCreate()

> According to my test, in PostCreate(), if the operation fails, the
contents of the FileName buffer were changed. The FileName.Length was
changed to 1 in my case.

True, but what make you think that the actual buffer is truncated, have you
checked the MaximumLength field?

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

Ayush_Gupta-2 · November 25, 2009, 7:08am

Comments below…

>You can free buffer pointed by FileName.Buffer yourself using ExFreePool.

Its allocated by FltMgr, as a basic rule you are not suppose to alter it. if
you have to change some thing you should change it inside parameter block as
described in documentation.
[Ayush Gupta] You can free the buffer of the FileName in FileObject. That
is how drivers do the STATUS_REPARSE thing.

>The I/O manager will free the memory allocated by you.

ExFreePool does not belongs to IoManager, its provided by Executive.

[Ayush Gupta] Who said that ExFreePool belongs to the IO Manager. But the
person saying that the buffer that you allocate and stuff in the
FileObject->FileName.Buffer is absolutely correct. The IO Manger will free
the buffer when it is tearing the FileObject.

Regards,
Ayush Gupta
AI Consulting

Aditya_Shrivastava · November 25, 2009, 7:33am

>>[Ayush Gupta] You can free the buffer of the FileName in FileObject. That is how drivers do the STATUS_REPARSE thing.

Is it? Isn’t it fileobject in _FLT_IO_PARAMETER_BLOCK, which a driver is suppose to change.

>[Ayush Gupta] Who said that ExFreePool belongs to the IO Manager. But the person saying that the buffer that you allocate and stuff in the FileObject->FileName.Buffer is absolutely correct. The IO Manger will free the buffer when it is tearing the FileObject.

My bad if this is the case, I deduced something totally different based on these lines.

“Buffer yourself using ExFreePool. The I/O manager will free the memory allocated by you.”

Ayush_Gupta-2 · November 25, 2009, 8:05am

Aditya, as you mentioned, one should use the _FLT_IO_PARAMETER_BLOCK
structure to change these parameters. But ultimately, both structures lead
to the same FileObject and hence the same Buffer.
My guess is that when MS says that one should use the
_FLT_IO_PARAMETER_BLOCK to change the parameters, it is for changing the
File Object or the instance itself (for example for redirection purposes).
In that case, this restriction becomes very very important because the
developer also needs to call FltSetCallbackDataDirty. And obviously this
cannot be done by changing the parameters in the Related objects structure.

Regards,
Ayush Gupta
AI Consulting

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Wednesday, November 25, 2009 6:05 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] 2 questions about PreCreate() and PostCreate()

>[Ayush Gupta] You can free the buffer of the FileName in FileObject. That
is how drivers do the STATUS_REPARSE thing.

Is it? Isn’t it fileobject in _FLT_IO_PARAMETER_BLOCK, which a driver is
suppose to change.

>[Ayush Gupta] Who said that ExFreePool belongs to the IO Manager. But the
person saying that the buffer that you allocate and stuff in the
FileObject->FileName.Buffer is absolutely correct. The IO Manger will free
the buffer when it is tearing the FileObject.

My bad if this is the case, I deduced something totally different based on
these lines.

“Buffer yourself using ExFreePool. The I/O manager will free the memory
allocated by you.”

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

Aditya_Shrivastava · November 25, 2009, 8:17am

>>But ultimately, both structures lead to the same FileObject and hence the same Buffer.

I thought for that once, in fact I than checked it at pre directory control callback and found that the fileobject field inside FLT_RELATED_OBJECTS was null, though the one inside parameter was pointing to a valid fileobject. Based on this observation I asserted on not changing this field directly.

Michael_Zhu · November 25, 2009, 9:24am

I had a system crash several months ago. In that crash the
FltObjects->FileObject is NULL. The system crashed when I tried to access
the FltObjects->FileObject->FileName in PreCreate(). But now I couldn’t find
that crash dump any more. That is why I asked under what conditions
FltObjects->FileObject could be NULL.

The following is some information from my test. In PostCreate(). You can see
the FltObjects->FileObject->FileName.Length is 1.

4: kd> dt _FLT_RELATED_OBJECTS 0xa44c3854
RepDrv!_FLT_RELATED_OBJECTS
+0x000 Size : 0x18
+0x002 TransactionContext : 0
+0x004 Filter : 0x87d717e0 _FLT_FILTER
+0x008 Volume : 0x8ac96008 _FLT_VOLUME
+0x00c Instance : 0x8728a3b0 _FLT_INSTANCE
+0x010 FileObject : 0x88435e38 _FILE_OBJECT
+0x014 Transaction : (null)

4: kd> dt _FILE_OBJECT 0x88435e38
nt!_FILE_OBJECT
+0x000 Type : 5
+0x002 Size : 112
+0x004 DeviceObject : 0x8acaf900 _DEVICE_OBJECT
+0x008 Vpb : 0x8aca48e0 _VPB
+0x00c FsContext : (null)
+0x010 FsContext2 : 0xe4cf69e0
+0x014 SectionObjectPointer : 0x883df77c _SECTION_OBJECT_POINTERS
+0x018 PrivateCacheMap : (null)
+0x01c FinalStatus : 0
+0x020 RelatedFileObject : (null)
+0x024 LockOperation : 0 ‘’
+0x025 DeletePending : 0 ‘’
+0x026 ReadAccess : 0x1 ‘’
+0x027 WriteAccess : 0x1 ‘’
+0x028 DeleteAccess : 0x1 ‘’
+0x029 SharedRead : 0 ‘’
+0x02a SharedWrite : 0 ‘’
+0x02b SharedDelete : 0 ‘’
+0x02c Flags : 0x42
+0x030 FileName : _UNICODE_STRING ""
+0x038 CurrentByteOffset : _LARGE_INTEGER 0x0
+0x040 Waiters : 0
+0x044 Busy : 0
+0x048 LastLock : (null)
+0x04c Lock : _KEVENT
+0x05c Event : _KEVENT
+0x06c CompletionContext : (null)

4: kd> dt _UNICODE_STRING 0x88435e38 + 0x30
nt!_UNICODE_STRING
""
+0x000 Length : 1
+0x002 MaximumLength : 0x78
+0x004 Buffer : 0xe5c1b558 ""

4: kd> !pool 0xe5c1b558
Pool page e5c1b558 region is Paged pool
*e5c1b550 size: 80 previous size: 8 (Allocated) *IoNm
Pooltag IoNm : Io parsing names, Binary : nt!io

4: kd> db 0xe5c1b558
e5c1b558 5c 00 44 00 4f 00 43 00-55 00 4d 00 45 00 7e 00 .D.O.C.U.M.E.~.
e5c1b568 31 00 5c 00 42 00 52 00-49 00 41 00 4e 00 7e 00 1..B.R.I.A.N.~.
e5c1b578 31 00 2e 00 4f 00 57 00-45 00 5c 00 4c 00 4f 00 1…O.W.E..L.O.
e5c1b588 43 00 41 00 4c 00 53 00-7e 00 31 00 5c 00 54 00 C.A.L.S.~.1..T.
e5c1b598 65 00 6d 00 70 00 5c 00-6c 00 6d 00 63 00 33 00 e.m.p..l.m.c.3.
e5c1b5a8 38 00 36 00 45 00 2e 00-74 00 6d 00 70 00 00 00 8.6.E…t.m.p…
e5c1b5b8 72 00 74 00 69 00 65 00-73 00 00 00 00 00 00 05 r.t.i.e.s…
e5c1b5c8 12 00 00 00 72 00 6c 00-10 04 08 0c 43 4d 4e e2 …r.l…CMN.

On Wed, Nov 25, 2009 at 8:19 AM, wrote:

> >>But ultimately, both structures lead to the same FileObject and hence the
> same Buffer.
>
> I thought for that once, in fact I than checked it at pre directory control
> callback and found that the fileobject field inside FLT_RELATED_OBJECTS was
> null, though the one inside parameter was pointing to a valid fileobject.
> Based on this observation I asserted on not changing this field directly.
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) 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
>

Lijun_Wang · November 25, 2009, 3:26pm

The file object can be null? in FltObjects. If you do not know hot to handle it, just ignore it. Some third party driver may not speicify a file object in the stack location for an IRP. For regular file create operations though the file object must be there – so you need not to worry about leaving targets sneaking through your filter.

Lijun

From: Michael Zhu
To: Windows File Systems Devs Interest List
Sent: Wed, November 25, 2009 9:23:59 AM
Subject: Re: [ntfsd] 2 questions about PreCreate() and PostCreate()

I had a system crash several months ago. In that crash the FltObjects->FileObject is NULL. The system crashed when I tried to access the FltObjects->FileObject->FileName in PreCreate(). But now I couldn’t find that crash dump any more. That is why I asked under what conditions FltObjects->FileObject could be NULL.

The following is some information from my test. In PostCreate(). You can see the FltObjects->FileObject->FileName.Length is 1.

4: kd> dt _FLT_RELATED_OBJECTS 0xa44c3854
RepDrv!_FLT_RELATED_OBJECTS
?? +0x000 Size??? : 0x18
?? +0x002 TransactionContext : 0
?? +0x004 Filter??? : 0x87d717e0 _FLT_FILTER
?? +0x008 Volume??? : 0x8ac96008 _FLT_VOLUME
?? +0x00c Instance??? : 0x8728a3b0 _FLT_INSTANCE
?? +0x010 FileObject??? : 0x88435e38 _FILE_OBJECT
?? +0x014 Transaction??? : (null)

4: kd> dt _FILE_OBJECT 0x88435e38
nt!_FILE_OBJECT
?? +0x000 Type??? : 5
?? +0x002 Size??? : 112
?? +0x004 DeviceObject??? : 0x8acaf900 _DEVICE_OBJECT
?? +0x008 Vpb??? : 0x8aca48e0 _VPB
?? +0x00c FsContext??? : (null)
?? +0x010 FsContext2??? : 0xe4cf69e0
?? +0x014 SectionObjectPointer : 0x883df77c _SECTION_OBJECT_POINTERS
?? +0x018 PrivateCacheMap? : (null)
?? +0x01c FinalStatus??? : 0
?? +0x020 RelatedFileObject : (null)
?? +0x024 LockOperation??? : 0 ‘’
?? +0x025 DeletePending??? : 0 ‘’
?? +0x026 ReadAccess??? : 0x1 ‘’
?? +0x027 WriteAccess??? : 0x1 ‘’
?? +0x028 DeleteAccess??? : 0x1 ‘’
?? +0x029 SharedRead??? : 0 ‘’
?? +0x02a SharedWrite??? : 0 ‘’
?? +0x02b SharedDelete??? : 0 ‘’
?? +0x02c Flags??? : 0x42
?? +0x030 FileName??? : _UNICODE_STRING “"
?? +0x038 CurrentByteOffset : _LARGE_INTEGER 0x0
?? +0x040 Waiters??? : 0
?? +0x044 Busy??? : 0
?? +0x048 LastLock??? : (null)
?? +0x04c Lock??? : _KEVENT
?? +0x05c Event??? : _KEVENT
?? +0x06c CompletionContext : (null)

4: kd> dt _UNICODE_STRING 0x88435e38 + 0x30
nt!_UNICODE_STRING
?”"
?? +0x000 Length??? : 1
?? +0x002 MaximumLength??? : 0x78
?? +0x004 Buffer??? : 0xe5c1b558? ""

4: kd> !pool 0xe5c1b558?
Pool page e5c1b558 region is Paged pool
*e5c1b550 size:?? 80 previous size:??? 8? (Allocated) *IoNm
??? ??? Pooltag IoNm : Io parsing names, Binary : nt!io

4: kd> db 0xe5c1b558?
e5c1b558? 5c 00 44 00 4f 00 43 00-55 00 4d 00 45 00 7e 00? .D.O.C.U.M.E.~.
e5c1b568? 31 00 5c 00 42 00 52 00-49 00 41 00 4e 00 7e 00? 1..B.R.I.A.N.~.
e5c1b578? 31 00 2e 00 4f 00 57 00-45 00 5c 00 4c 00 4f 00? 1…O.W.E..L.O.
e5c1b588? 43 00 41 00 4c 00 53 00-7e 00 31 00 5c 00 54 00? C.A.L.S.~.1..T.
e5c1b598? 65 00 6d 00 70 00 5c 00-6c 00 6d 00 63 00 33 00? e.m.p..l.m.c.3.
e5c1b5a8? 38 00 36 00 45 00 2e 00-74 00 6d 00 70 00 00 00? 8.6.E…t.m.p…
e5c1b5b8? 72 00 74 00 69 00 65 00-73 00 00 00 00 00 00 05? r.t.i.e.s…
e5c1b5c8? 12 00 00 00 72 00 6c 00-10 04 08 0c 43 4d 4e e2? …r.l…CMN.

On Wed, Nov 25, 2009 at 8:19 AM, wrote:

>>But ultimately, both structures lead to the same FileObject and hence the same Buffer.
>
>I thought for that once, in fact I than checked it at pre directory control callback and found that the fileobject field inside FLT_RELATED_OBJECTS was null, though the one inside parameter was pointing to a valid fileobject. Based on this observation I asserted on not changing this field directly.
>
>
>
>
>—
>NTFSD is sponsored by OSR
>
>For our schedule of debugging and file system seminars
>(including our new fs mini-filter seminar) 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 For our schedule of debugging and file system seminars (including our new fs mini-filter seminar) 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

Michael_Zhu · November 25, 2009, 3:40pm

Right now I always have the following code in my driver to cover that
condition.

if (NULL == FltObjects->FileObject) {
return = FLT_PREOP_SUCCESS_NO_CALLBACK;
}

On Wed, Nov 25, 2009 at 3:25 PM, Lijun Wang wrote:

> The file object can be null in FltObjects. If you do not know hot to
> handle it, just ignore it. Some third party driver may not speicify a file
> object in the stack location for an IRP. For regular file create operations
> though the file object must be there – so you need not to worry about
> leaving targets sneaking through your filter.
> Lijun
> ------------------------------
> From: Michael Zhu
> To: Windows File Systems Devs Interest List
> Sent: Wed, November 25, 2009 9:23:59 AM
> Subject: Re: [ntfsd] 2 questions about PreCreate() and PostCreate()
>
> I had a system crash several months ago. In that crash the
> FltObjects->FileObject is NULL. The system crashed when I tried to access
> the FltObjects->FileObject->FileName in PreCreate(). But now I couldn’t find
> that crash dump any more. That is why I asked under what conditions
> FltObjects->FileObject could be NULL.
>
> The following is some information from my test. In PostCreate(). You can
> see the FltObjects->FileObject->FileName.Length is 1.
>
> 4: kd> dt _FLT_RELATED_OBJECTS 0xa44c3854
> RepDrv!_FLT_RELATED_OBJECTS
> +0x000 Size : 0x18
> +0x002 TransactionContext : 0
> +0x004 Filter : 0x87d717e0 _FLT_FILTER
> +0x008 Volume : 0x8ac96008 _FLT_VOLUME
> +0x00c Instance : 0x8728a3b0 _FLT_INSTANCE
> +0x010 FileObject : 0x88435e38 _FILE_OBJECT
> +0x014 Transaction : (null)
>
> 4: kd> dt _FILE_OBJECT 0x88435e38
> nt!_FILE_OBJECT
> +0x000 Type : 5
> +0x002 Size : 112
> +0x004 DeviceObject : 0x8acaf900 _DEVICE_OBJECT
> +0x008 Vpb : 0x8aca48e0 _VPB
> +0x00c FsContext : (null)
> +0x010 FsContext2 : 0xe4cf69e0
> +0x014 SectionObjectPointer : 0x883df77c _SECTION_OBJECT_POINTERS
> +0x018 PrivateCacheMap : (null)
> +0x01c FinalStatus : 0
> +0x020 RelatedFileObject : (null)
> +0x024 LockOperation : 0 ‘’
> +0x025 DeletePending : 0 ‘’
> +0x026 ReadAccess : 0x1 ‘’
> +0x027 WriteAccess : 0x1 ‘’
> +0x028 DeleteAccess : 0x1 ‘’
> +0x029 SharedRead : 0 ‘’
> +0x02a SharedWrite : 0 ‘’
> +0x02b SharedDelete : 0 ‘’
> +0x02c Flags : 0x42
> +0x030 FileName : _UNICODE_STRING ""
> +0x038 CurrentByteOffset : _LARGE_INTEGER 0x0
> +0x040 Waiters : 0
> +0x044 Busy : 0
> +0x048 LastLock : (null)
> +0x04c Lock : _KEVENT
> +0x05c Event : _KEVENT
> +0x06c CompletionContext : (null)
>
> 4: kd> dt _UNICODE_STRING 0x88435e38 + 0x30
> nt!_UNICODE_STRING
> ""
> +0x000 Length : 1
> +0x002 MaximumLength : 0x78
> +0x004 Buffer : 0xe5c1b558 ""
>
> 4: kd> !pool 0xe5c1b558
> Pool page e5c1b558 region is Paged pool
> *e5c1b550 size: 80 previous size: 8 (Allocated) *IoNm
> Pooltag IoNm : Io parsing names, Binary : nt!io
>
> 4: kd> db 0xe5c1b558
> e5c1b558 5c 00 44 00 4f 00 43 00-55 00 4d 00 45 00 7e 00 .D.O.C.U.M.E.~.
> e5c1b568 31 00 5c 00 42 00 52 00-49 00 41 00 4e 00 7e 00 1..B.R.I.A.N.~.
> e5c1b578 31 00 2e 00 4f 00 57 00-45 00 5c 00 4c 00 4f 00 1…O.W.E..L.O.
> e5c1b588 43 00 41 00 4c 00 53 00-7e 00 31 00 5c 00 54 00 C.A.L.S.~.1..T.
> e5c1b598 65 00 6d 00 70 00 5c 00-6c 00 6d 00 63 00 33 00 e.m.p..l.m.c.3.
> e5c1b5a8 38 00 36 00 45 00 2e 00-74 00 6d 00 70 00 00 00 8.6.E…t.m.p…
> e5c1b5b8 72 00 74 00 69 00 65 00-73 00 00 00 00 00 00 05 r.t.i.e.s…
> e5c1b5c8 12 00 00 00 72 00 6c 00-10 04 08 0c 43 4d 4e e2 …r.l…CMN.
>
>
>
>
> On Wed, Nov 25, 2009 at 8:19 AM, wrote:
>
>> >>But ultimately, both structures lead to the same FileObject and hence
>> the same Buffer.
>>
>> I thought for that once, in fact I than checked it at pre directory
>> control callback and found that the fileobject field inside
>> FLT_RELATED_OBJECTS was null, though the one inside parameter was pointing
>> to a valid fileobject. Based on this observation I asserted on not changing
>> this field directly.
>>
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule of debugging and file system seminars
>> (including our new fs mini-filter seminar) 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 For our schedule of debugging and file system
> seminars (including our new fs mini-filter seminar) 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
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) 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
>