OK, I have solved the problem. It appears to be a bug relating to FASTFAT;
the bug is not present on NTFS volumes. Here is a synopsis:
If you are pre-reading data from a file on CREATE completion and the file is
on a FAT drive and it is an EXE file loading via WinExec, your pre-read must
NOT cause caching to initiate on the file. To solve the problem, I simply
set my I/O on a sector boundry and OR’d in the IRP_NO_CACHE flag in my IRP.
It looks like the second section mapping for the EXE file is causing the
problem. It was always faulting in CcFlushCache().
Jamey
StorageCraft
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Rob Fuller
Sent: Monday, March 13, 2000 8:45 AM
To: File Systems Developers
Subject: [ntfsd] 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’)
You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)