problems with IRP_MJ_FLUSH_BUFFERS

Following code (realization of ZwFlushBuffersFile() :
what’s wrong with code ? I’ve got BSOD at last line - CallIoDriver().

NTSTATUS
NTAPI
ZwFlushBuffersFile( IN HANDLE Handle,
OUT PIO_STATUS_BLOCK IoStatusBlock )
{
PVOID ObjectHandle;
OBJECT_HANDLE_INFORMATION ObjectHandleInfo;
PDEVICE_OBJECT pDeviceObject;
KEVENT event;
PIRP pIrp;
IO_STATUS_BLOCK sb;
LARGE_INTEGER Timeout;
NTSTATUS res;
Timeout.QuadPart = 5000;

if(ObReferenceObjectByHandle(Handle, FILE_READ_DATA | FILE_WRITE_ATTRIBUTES,
NULL, KernelMode, &ObjectHandle, &ObjectHandleInfo) != STATUS_SUCCESS)
return STATUS_INVALID_DEVICE_REQUEST;

pDeviceObject = IoGetRelatedDeviceObject(ObjectHandle);

KeInitializeEvent(&event, NotificationEvent, FALSE);
if((pIrp = IoBuildSynchronousFsdRequest(IRP_MJ_FLUSH_BUFFERS, pDeviceObject,
NULL, 0, 0, &event, &sb)) == NULL)
{
return STATUS_INVALID_DEVICE_REQUEST;
}
pIrp->RequestorMode = KernelMode;

/*********************/
/* BSOD HERE in IoCallDriver */
if(IoCallDriver(pd, pIrp) == STATUS_PENDING)

You’re forgetting to set the file object field in the
current IRP stack location.

— Alexander Bilichenko wrote:
> Following code (realization of ZwFlushBuffersFile()
> :
> what’s wrong with code ? I’ve got BSOD at last line
> - CallIoDriver().
>
> NTSTATUS
> NTAPI
> ZwFlushBuffersFile( IN HANDLE Handle,
> OUT PIO_STATUS_BLOCK IoStatusBlock )
> {
> PVOID ObjectHandle;
> OBJECT_HANDLE_INFORMATION ObjectHandleInfo;
> PDEVICE_OBJECT pDeviceObject;
> KEVENT event;
> PIRP pIrp;
> IO_STATUS_BLOCK sb;
> LARGE_INTEGER Timeout;
> NTSTATUS res;
> Timeout.QuadPart = 5000;
>
> if(ObReferenceObjectByHandle(Handle, FILE_READ_DATA
> | FILE_WRITE_ATTRIBUTES,
> NULL, KernelMode, &ObjectHandle,
> &ObjectHandleInfo) != STATUS_SUCCESS)
> return STATUS_INVALID_DEVICE_REQUEST;
>
> pDeviceObject =
> IoGetRelatedDeviceObject(ObjectHandle);
>
> KeInitializeEvent(&event, NotificationEvent,
> FALSE);
> if((pIrp =
> IoBuildSynchronousFsdRequest(IRP_MJ_FLUSH_BUFFERS,
> pDeviceObject,
> NULL, 0, 0, &event, &sb)) == NULL)
> {
> return STATUS_INVALID_DEVICE_REQUEST;
> }
> pIrp->RequestorMode = KernelMode;
>
> / ********************* /
> /* BSOD HERE in IoCallDriver */
> if(IoCallDriver(pd, pIrp) == STATUS_PENDING)
>
>
>
> —
> You are currently subscribed to ntfsd as:
> xxxxx@nryan.com
> To unsubscribe send a blank email to
> %%email.unsub%%
>

=====
- Nicholas Ryan

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

Actually this would be the file object field in the
NEXT IRP stack location, not the current stack
location. Also it’s customary to set these two fields
as well, but I’m not sure if it’s strictly necessary:

pIrp->Tail.Overlay.Thread = PsGetCurrentThread();
pIrp->Tail.Overlay.OriginalFileObject = fileObject;

— Nicholas Ryan wrote:
> You’re forgetting to set the file object field in
> the
> current IRP stack location.
>
> — Alexander Bilichenko wrote:
> > Following code (realization of
> ZwFlushBuffersFile()
> > :
> > what’s wrong with code ? I’ve got BSOD at last
> line
> > - CallIoDriver().
> >
> > NTSTATUS
> > NTAPI
> > ZwFlushBuffersFile( IN HANDLE Handle,
> > OUT PIO_STATUS_BLOCK IoStatusBlock )
> > {
> > PVOID ObjectHandle;
> > OBJECT_HANDLE_INFORMATION ObjectHandleInfo;
> > PDEVICE_OBJECT pDeviceObject;
> > KEVENT event;
> > PIRP pIrp;
> > IO_STATUS_BLOCK sb;
> > LARGE_INTEGER Timeout;
> > NTSTATUS res;
> > Timeout.QuadPart = 5000;
> >
> > if(ObReferenceObjectByHandle(Handle,
> FILE_READ_DATA
> > | FILE_WRITE_ATTRIBUTES,
> > NULL, KernelMode, &ObjectHandle,
> > &ObjectHandleInfo) != STATUS_SUCCESS)
> > return STATUS_INVALID_DEVICE_REQUEST;
> >
> > pDeviceObject =
> > IoGetRelatedDeviceObject(ObjectHandle);
> >
> > KeInitializeEvent(&event, NotificationEvent,
> > FALSE);
> > if((pIrp =
> > IoBuildSynchronousFsdRequest(IRP_MJ_FLUSH_BUFFERS,
> > pDeviceObject,
> > NULL, 0, 0, &event, &sb)) == NULL)
> > {
> > return STATUS_INVALID_DEVICE_REQUEST;
> > }
> > pIrp->RequestorMode = KernelMode;
> >
> > / ********************* /
> > /* BSOD HERE in IoCallDriver */
> > if(IoCallDriver(pd, pIrp) == STATUS_PENDING)
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as:
> > xxxxx@nryan.com
> > To unsubscribe send a blank email to
> > %%email.unsub%%
> >
>
>
> =====
> - Nicholas Ryan
>
>
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/
>

=====
- Nicholas Ryan


Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

WARNING:

It is NEVER correct for a filter to set the OriginalFileObject field in
an IRP. Anyone that is currently doing this needs to stop. This field
is reserved for the IOManager (please read the comments in ntifs.h) and
setting this field by a filter in certain situations will cause the
system to crash.

Neal Christiansen

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

-----Original Message-----
From: Nicholas Ryan [mailto:xxxxx@yahoo.com]
Sent: Monday, April 15, 2002 09:34 AM
To: File Systems Developers
Subject: [ntfsd] Re: problems with IRP_MJ_FLUSH_BUFFERS

Actually this would be the file object field in the
NEXT IRP stack location, not the current stack
location. Also it’s customary to set these two fields
as well, but I’m not sure if it’s strictly necessary:

pIrp->Tail.Overlay.Thread = PsGetCurrentThread();
pIrp->Tail.Overlay.OriginalFileObject = fileObject;

— Nicholas Ryan wrote:
> You’re forgetting to set the file object field in
> the
> current IRP stack location.
>
> — Alexander Bilichenko wrote:
> > Following code (realization of
> ZwFlushBuffersFile()
> > :
> > what’s wrong with code ? I’ve got BSOD at last
> line
> > - CallIoDriver().
> >
> > NTSTATUS
> > NTAPI
> > ZwFlushBuffersFile( IN HANDLE Handle,
> > OUT PIO_STATUS_BLOCK IoStatusBlock )
> > {
> > PVOID ObjectHandle;
> > OBJECT_HANDLE_INFORMATION ObjectHandleInfo;
> > PDEVICE_OBJECT pDeviceObject;
> > KEVENT event;
> > PIRP pIrp;
> > IO_STATUS_BLOCK sb;
> > LARGE_INTEGER Timeout;
> > NTSTATUS res;
> > Timeout.QuadPart = 5000;
> >
> > if(ObReferenceObjectByHandle(Handle,
> FILE_READ_DATA
> > | FILE_WRITE_ATTRIBUTES,
> > NULL, KernelMode, &ObjectHandle,
> > &ObjectHandleInfo) != STATUS_SUCCESS)
> > return STATUS_INVALID_DEVICE_REQUEST;
> >
> > pDeviceObject =
> > IoGetRelatedDeviceObject(ObjectHandle);
> >
> > KeInitializeEvent(&event, NotificationEvent,
> > FALSE);
> > if((pIrp =
> > IoBuildSynchronousFsdRequest(IRP_MJ_FLUSH_BUFFERS,
> > pDeviceObject,
> > NULL, 0, 0, &event, &sb)) == NULL)
> > {
> > return STATUS_INVALID_DEVICE_REQUEST;
> > }
> > pIrp->RequestorMode = KernelMode;
> >
> > / ********************* /
> > /* BSOD HERE in IoCallDriver */
> > if(IoCallDriver(pd, pIrp) == STATUS_PENDING)
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as:
> > xxxxx@nryan.com
> > To unsubscribe send a blank email to
> > %%email.unsub%%
> >
>
>
> =====
> - Nicholas Ryan
>
>
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/
>

=====
- Nicholas Ryan


Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/


You are currently subscribed to ntfsd as: xxxxx@Windows.Microsoft.com
To unsubscribe send a blank email to %%email.unsub%%

Just for the record, I commented out the call to set
the pIrp->Tail.Overlay.OriginalFileObject field in my
filter and it still appears to work.

For anybody wanting to know how to roll your own IRP
the ‘right way’, check out
SpyQueryFileSystemForFileName in fspyLib.c in the XP
IFS kit. I’m beginning to learn that when FileMon and
FileSpy disagree about the right way to do something,
FileSpy is almost always right (which it should be,
given that it was written by Microsoft).

— Neal Christiansen
wrote:
> WARNING:
>
> It is NEVER correct for a filter to set the
> OriginalFileObject field in
> an IRP. Anyone that is currently doing this needs
> to stop. This field
> is reserved for the IOManager (please read the
> comments in ntifs.h) and
> setting this field by a filter in certain situations
> will cause the
> system to crash.
>
> Neal Christiansen
>
> This posting is provided “AS IS” with no warranties,
> and confers no
> rights.
>
> -----Original Message-----
> From: Nicholas Ryan [mailto:xxxxx@yahoo.com]
> Sent: Monday, April 15, 2002 09:34 AM
> To: File Systems Developers
> Subject: [ntfsd] Re: problems with
> IRP_MJ_FLUSH_BUFFERS
>
> Actually this would be the file object field in the
> NEXT IRP stack location, not the current stack
> location. Also it’s customary to set these two
> fields
> as well, but I’m not sure if it’s strictly
> necessary:
>
> pIrp->Tail.Overlay.Thread = PsGetCurrentThread();
> pIrp->Tail.Overlay.OriginalFileObject = fileObject;
>
> — Nicholas Ryan wrote:
> > You’re forgetting to set the file object field in
> > the
> > current IRP stack location.
> >
> > — Alexander Bilichenko wrote:
> > > Following code (realization of
> > ZwFlushBuffersFile()
> > > :
> > > what’s wrong with code ? I’ve got BSOD at last
> > line
> > > - CallIoDriver().
> > >
> > > NTSTATUS
> > > NTAPI
> > > ZwFlushBuffersFile( IN HANDLE Handle,
> > > OUT PIO_STATUS_BLOCK IoStatusBlock )
> > > {
> > > PVOID ObjectHandle;
> > > OBJECT_HANDLE_INFORMATION ObjectHandleInfo;
> > > PDEVICE_OBJECT pDeviceObject;
> > > KEVENT event;
> > > PIRP pIrp;
> > > IO_STATUS_BLOCK sb;
> > > LARGE_INTEGER Timeout;
> > > NTSTATUS res;
> > > Timeout.QuadPart = 5000;
> > >
> > > if(ObReferenceObjectByHandle(Handle,
> > FILE_READ_DATA
> > > | FILE_WRITE_ATTRIBUTES,
> > > NULL, KernelMode, &ObjectHandle,
> > > &ObjectHandleInfo) != STATUS_SUCCESS)
> > > return STATUS_INVALID_DEVICE_REQUEST;
> > >
> > > pDeviceObject =
> > > IoGetRelatedDeviceObject(ObjectHandle);
> > >
> > > KeInitializeEvent(&event, NotificationEvent,
> > > FALSE);
> > > if((pIrp =
> > >
> IoBuildSynchronousFsdRequest(IRP_MJ_FLUSH_BUFFERS,
> > > pDeviceObject,
> > > NULL, 0, 0, &event, &sb)) == NULL)
> > > {
> > > return STATUS_INVALID_DEVICE_REQUEST;
> > > }
> > > pIrp->RequestorMode = KernelMode;
> > >
> > > / ********************* /
> > > /* BSOD HERE in IoCallDriver */
> > > if(IoCallDriver(pd, pIrp) == STATUS_PENDING)
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntfsd as:
> > > xxxxx@nryan.com
> > > To unsubscribe send a blank email to
> > > %%email.unsub%%
> > >
> >
> >
> > =====
> > - Nicholas Ryan
> >
> >
> > Do You Yahoo!?
> > Yahoo! Tax Center - online filing with TurboTax
> > http://taxes.yahoo.com/
> >
>
>
> =====
> - Nicholas Ryan
>
>

> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/
>
> —
> You are currently subscribed to ntfsd as:
> xxxxx@Windows.Microsoft.com
> To unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to ntfsd as:
> xxxxx@nryan.com
> To unsubscribe send a blank email to
%%email.unsub%%

=====
- Nicholas Ryan

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

Thank you for fixing this.

If you ever find a case where you believe FileMon is correct and FileSpy
is not, we would appreciate it if you would report it to us.

Thanks,

Neal Christiansen

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

-----Original Message-----
From: Nicholas Ryan [mailto:xxxxx@nryan.com]
Sent: Monday, April 15, 2002 12:47 PM
To: File Systems Developers
Subject: [ntfsd] Re: problems with IRP_MJ_FLUSH_BUFFERS

Just for the record, I commented out the call to set
the pIrp->Tail.Overlay.OriginalFileObject field in my
filter and it still appears to work.

For anybody wanting to know how to roll your own IRP
the ‘right way’, check out
SpyQueryFileSystemForFileName in fspyLib.c in the XP
IFS kit. I’m beginning to learn that when FileMon and
FileSpy disagree about the right way to do something,
FileSpy is almost always right (which it should be,
given that it was written by Microsoft).

— Neal Christiansen
wrote:
> WARNING:
>
> It is NEVER correct for a filter to set the
> OriginalFileObject field in
> an IRP. Anyone that is currently doing this needs
> to stop. This field
> is reserved for the IOManager (please read the
> comments in ntifs.h) and
> setting this field by a filter in certain situations
> will cause the
> system to crash.
>
> Neal Christiansen
>
> This posting is provided “AS IS” with no warranties,
> and confers no
> rights.
>
> -----Original Message-----
> From: Nicholas Ryan [mailto:xxxxx@yahoo.com]
> Sent: Monday, April 15, 2002 09:34 AM
> To: File Systems Developers
> Subject: [ntfsd] Re: problems with
> IRP_MJ_FLUSH_BUFFERS
>
> Actually this would be the file object field in the
> NEXT IRP stack location, not the current stack
> location. Also it’s customary to set these two
> fields
> as well, but I’m not sure if it’s strictly
> necessary:
>
> pIrp->Tail.Overlay.Thread = PsGetCurrentThread();
> pIrp->Tail.Overlay.OriginalFileObject = fileObject;
>
> — Nicholas Ryan wrote:
> > You’re forgetting to set the file object field in
> > the
> > current IRP stack location.
> >
> > — Alexander Bilichenko wrote:
> > > Following code (realization of
> > ZwFlushBuffersFile()
> > > :
> > > what’s wrong with code ? I’ve got BSOD at last
> > line
> > > - CallIoDriver().
> > >
> > > NTSTATUS
> > > NTAPI
> > > ZwFlushBuffersFile( IN HANDLE Handle,
> > > OUT PIO_STATUS_BLOCK IoStatusBlock )
> > > {
> > > PVOID ObjectHandle;
> > > OBJECT_HANDLE_INFORMATION ObjectHandleInfo;
> > > PDEVICE_OBJECT pDeviceObject;
> > > KEVENT event;
> > > PIRP pIrp;
> > > IO_STATUS_BLOCK sb;
> > > LARGE_INTEGER Timeout;
> > > NTSTATUS res;
> > > Timeout.QuadPart = 5000;
> > >
> > > if(ObReferenceObjectByHandle(Handle,
> > FILE_READ_DATA
> > > | FILE_WRITE_ATTRIBUTES,
> > > NULL, KernelMode, &ObjectHandle,
> > > &ObjectHandleInfo) != STATUS_SUCCESS)
> > > return STATUS_INVALID_DEVICE_REQUEST;
> > >
> > > pDeviceObject =
> > > IoGetRelatedDeviceObject(ObjectHandle);
> > >
> > > KeInitializeEvent(&event, NotificationEvent,
> > > FALSE);
> > > if((pIrp =
> > >
> IoBuildSynchronousFsdRequest(IRP_MJ_FLUSH_BUFFERS,
> > > pDeviceObject,
> > > NULL, 0, 0, &event, &sb)) == NULL)
> > > {
> > > return STATUS_INVALID_DEVICE_REQUEST;
> > > }
> > > pIrp->RequestorMode = KernelMode;
> > >
> > > / ********************* /
> > > /* BSOD HERE in IoCallDriver */
> > > if(IoCallDriver(pd, pIrp) == STATUS_PENDING)
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntfsd as:
> > > xxxxx@nryan.com
> > > To unsubscribe send a blank email to
> > > %%email.unsub%%
> > >
> >
> >
> > =====
> > - Nicholas Ryan
> >
> >
> > Do You Yahoo!?
> > Yahoo! Tax Center - online filing with TurboTax
> > http://taxes.yahoo.com/
> >
>
>
> =====
> - Nicholas Ryan
>
>

> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/
>
> —
> You are currently subscribed to ntfsd as:
> xxxxx@Windows.Microsoft.com
> To unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to ntfsd as:
> xxxxx@nryan.com
> To unsubscribe send a blank email to
%%email.unsub%%

=====
- Nicholas Ryan

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/


You are currently subscribed to ntfsd as: xxxxx@Windows.Microsoft.com
To unsubscribe send a blank email to %%email.unsub%%

> location. Also it’s customary to set these two fields

as well, but I’m not sure if it’s strictly necessary:

pIrp->Tail.Overlay.Thread = PsGetCurrentThread();
pIrp->Tail.Overlay.OriginalFileObject = fileObject;

No.
They are for IopCompleteRequest only, not for driver use.
If you return STATUS_MORE_PROCESSING_REQUIRED - then they are not used.

Max