FileObject Null in WriteRequest recieved by disk filter driver

NTFSD
1

Hi,

I have a disk filter driver which maintains a list of all the writes
happening on a particular volume. Normally the driver works fine. But when
there is heavy IO on the volume, for some of the writes, the fileobject is
NULL. Any idea why for some writes, the fileobject comes as null but for
some other writes, it doesn`t. I store the File Objects FSContext to
determine if the write already happened to a particular location or not. So
when this FileObject comes as NULL, driver does not log the write . Could
anybody please help me regarding this?

Thanks,
manorama

2

Hi,

The driver is a disk filter driver. Normally i check the
irp->Tail.Overlay.OriginalFileObject if is NULL check the irp->
AssociatedIrp.MasterIrp->Tail.Overlay.OriginalFileObject. if either of them
is not NULL get the FSContext from the FileObject and store it in a list to
keep track of the writes going through to the Volume. In normal cases either
of them were always not NULL. But in case where there was heavy IO, both of
them were NULL. In this case it is difficult to find out if the write is
happening to the same location previously written or not. Could any one
please help why this could be happening.

Thanks,

Manorama

On 4/4/07, pidapa manorama wrote:
>
> Hi,
>
> I have a disk filter driver which maintains a list of all the writes
> happening on a particular volume. Normally the driver works fine. But when
> there is heavy IO on the volume, for some of the writes, the fileobject is
> NULL. Any idea why for some writes, the fileobject comes as null but for
> some other writes, it doesn`t. I store the File Objects FSContext to
> determine if the write already happened to a particular location or not. So
> when this FileObject comes as NULL, driver does not log the write . Could
> anybody please help me regarding this?
>
> Thanks,
> manorama
>

3

You’ve been (un)lucky before this. There is *no requirement* that
either of these fields be filled in when passed to the volume manager
from the FSD. If you look at FatMultipleAsync (search for
IoMakeAssociatedIrp) you can see that it doesn’t set up a file object in
the associated IRP. This is at least one path in which you would
receive an IRP that is no longer directly associated with the file.

The reason you USUALLY see it is because FAT/NTFS normally use the IRP
at hand. However, if the I/O needs to be broken up into pieces (as is
the case I mentioned above) it builds a new IRP. Relying on any other
behavior is fundamentally broken and certainly not necessary for the
correct function of the system.

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com http:</http:>