RE: page fault from synchronous FSD request in Create-- Completion routine

In general, any re-entry to the FSD from your FSD filter’s completion
routine will trigger this bug regardless of where you re-enter the stack. I
hope this helps.

Regards,

Rob

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Monday, March 13, 2000 11:31 AM
To: File Systems Developers
Subject: [ntfsd] RE: page fault from synchronous FSD request in Create
Completion routine

Interesting.

We are not re-entering the FSD from the top. We simply issue a read IRP to
the taget device below us in the completion handler.

I will look into the TOP-LEVEL IRP issue. Thanks for the heads up.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Rob Fuller
Sent: Monday, March 13, 2000 7:54 AM
To: File Systems Developers
Subject: [ntfsd] RE: page fault from synchronous FSD request in Create
Completion routine

If you’re re-entering the FSD from a completion routine, then you
must save
the top level IRP field of the thread and set it to NULL before
re-entering.
Otherwise, the FSD may access an IRP context structure it stored
in the top
level IRP field of the thread. This access wouldn’t be a problem
if the FSD
hadn’t freed the IRP context structure before invoking your completion
routine by calling IoCompleteRequest.

Are you setting the top level IRP field of the thread to NULL before
re-entering the FSD from your filter’s completion routine?
Jamie’s 90%/10%
success/failure statistics are consistent with statistics I’ve
observed when
NOT setting the top level IRP field to NULL before re-entry.

Also, is the machine that is failing an SMP machine? SMP machines under
load exacerbate this bug.

-----Original Message-----
From: Neil Weicher [mailto:xxxxx@netlib.com]
Sent: Sunday, March 12, 2000 12:42 AM
To: File Systems Developers
Cc: Tony Mason
Subject: [ntfsd] RE: page fault from synchronous FSD request in Create
Com pletion routine

Thanks very much for the reply.

<< Given that this is a page fault, is it possible that maybe you have the
address on which it is faulting? >>

The address is an invalid one, usually something like 000000A4h. All the
other pointer values seem valid. I have included the stripped down code
below.

<< Best of luck - trying to debug problems like this via general
descriptions
is (in my experience) a tough thing for this group (or anyone, really) to
accomplish. >>

Understandable. I was just wondering if it struck any familiar note.

The stripped down code is shown below. The file object and device
object are
extracted from the appropriate parameters of the Create
Completion routine.
The routine below works fine, but then crashes after a number of
iterations,
usually at the time of a process change.

Again, many thanks.

Neil

NTSTATUS ReadFile( PDEVICE_OBJECT DeviceObject,
PFILE_OBJECT FileObject,
PUCHAR Buffer,
ULONG Length,
PLARGE_INTEGER Offset )
{
NTSTATUS ntStatus = STATUS_INSUFFICIENT_RESOURCES;
PIRP irp;
KEVENT event;
IO_STATUS_BLOCK ioStatus;
PIO_STACK_LOCATION irpSp;
KeInitializeEvent(&event, NotificationEvent, FALSE);
irp = IoBuildSynchronousFsdRequest (
IRP_MJ_READ, DeviceObject, Buffer, Length, Offset, &event,
&ioStatus );
);
if (irp != NULL)
{
irpSp = IoGetNextIrpStackLocation(irp);
irpSp->FileObject = FileObject;
if ((ntStatus = IoCallDriver(DeviceObject, irp)) ==
STATUS_PENDING)
{
KeWaitForSingleObject(&event, Suspended, KernelMode, FALSE,
NULL);
ntStatus = ioStatus.Status;
}
}
return (ntStatus);
}


You are currently subscribed to ntfsd as: xxxxx@nsisw.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)


You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)


You are currently subscribed to ntfsd as: xxxxx@nsisw.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)