Strange buffer behavior

NTFSD
1

Hi all,

Continuing the story of the DO_NEITHER_IO buffer.
We came upon a really strange behavior.
Our legacy filter sits above the NPFS driver and accesses the buffers for
WRITE and READ operations.
As I wrote earlier in this forum, the device is DO_NEITHER_IO, so we take
the Irp->UserBuffer, allocate the MDL and lock the pages in the dispatch
handler,
retrieve the system address and use it in the completion routine. But, what
is really weird is that in some cases, the buffer doesn’t seem to contain
the valid data, but some
seemingly older leftover from the last read. In these cases, the valid
buffer is located at Irp->AssociatedIrp.SystemBuffer, just as for
BUFFERED_IO !
One interesting detail is that these cases always coincide with
Irp->PendingReturned set in the completion routine.

Can somebody shed some light on this?

Thanks in advance,
Greg.

2

If the operation is Notify Change directory and you are using a minifilter
then you might want to look at FltGetNewSystemBufferAddress in post-op
(thanks to Alex for pointing this one out to me). If you are not (and ISTR
you saying that you arte not because of issues filtering NPFS) look out for
Irp->AssociatedIrp.SystemBuffer suddenly coming back with a value in it
which wasn’t there on the way down.

As far as I can work out the (completely undocumented) notify change code
will convert neither IO into buffered IO on the fly (which makes a lot of
sense in the face of booting into 64Mb and long lasting operations). But
beware - not every IO is treated like this and some kernel components just
send down the system address pre-populated…

R

“Greg” wrote in message news:xxxxx@ntfsd…
Hi all,

Continuing the story of the DO_NEITHER_IO buffer.
We came upon a really strange behavior.
Our legacy filter sits above the NPFS driver and accesses the buffers for
WRITE and READ operations.
As I wrote earlier in this forum, the device is DO_NEITHER_IO, so we take
the Irp->UserBuffer, allocate the MDL and lock the pages in the dispatch
handler,
retrieve the system address and use it in the completion routine. But, what
is really weird is that in some cases, the buffer doesn’t seem to contain
the valid data, but some
seemingly older leftover from the last read. In these cases, the valid
buffer is located at Irp->AssociatedIrp.SystemBuffer, just as for
BUFFERED_IO !
One interesting detail is that these cases always coincide with
Irp->PendingReturned set in the completion routine.

Can somebody shed some light on this?

Thanks in advance,
Greg.

3

Hi all,

Continuing the story of the DO_NEITHER_IO buffer.
We came upon a really strange behavior.
Our legacy filter sits above the NPFS driver and accesses the buffers
for WRITE and READ operations.
As I wrote earlier in this forum, the device is DO_NEITHER_IO, so we
take the Irp->UserBuffer, allocate the MDL and lock the pages in the
dispatch handler,
retrieve the system address and use it in the completion routine. But,
what is really weird is that in some cases, the buffer doesn’t seem to
contain the valid data, but some
seemingly older leftover from the last read. In these cases, the valid
buffer is located at Irp->AssociatedIrp.SystemBuffer, just as for
BUFFERED_IO !
One interesting detail is that these cases always coincide with Irp-
>PendingReturned set in the completion routine.

Can somebody shed some light on this?

Thanks in advance,
Greg.

4

Greg,

NPFS never looks at the MDL. It must be called in a context where the Irp->UserBuffer is valid.

When NPFS pends a read it will change the IRP flags to reflect IRP_BUFFERED_IO and use the Irp->AssociatedIrp.SystemBuffer on completion.

Hope this helps.

Regards,
Scott.
File System Filter Team
Microsoft Corp

This posting is provided “AS IS” with no warranties, and confers no Rights

5

Hi Scott,
Thanks a lot for the explanation, now it’s completely clear.

G.

On Fri, Jan 7, 2011 at 8:55 PM, wrote:

> Greg,
>
> NPFS never looks at the MDL. It must be called in a context where the
> Irp->UserBuffer is valid.
>
> When NPFS pends a read it will change the IRP flags to reflect
> IRP_BUFFERED_IO and use the Irp->AssociatedIrp.SystemBuffer on completion.
>
> Hope this helps.
>
> Regards,
> Scott.
> File System Filter Team
> Microsoft Corp
>
> This posting is provided “AS IS” with no warranties, and confers no Rights
>
>
> —
> 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
>