(a) I assume that you return STATUS_PENDING after the initial
queuing of the IRP. Please check that this is indeed the
(b) I would strongly advise that you impersonate the original
caller when you forward the IRP later or else the FSD
will be quite unhappy (and so will the filter drivers below
you in the stack).
BTW, I do not believe that this would be the cause of the
(c) Do not ever complete an IRP with STATUS_PENDING set in the
IoStatus.Status field. In the debug/checked build, you
will hit upon an assertion in IoCompleteRequest() guarding
precisely against this error.
(d) How do you queue the IRP? What sort of list structure
do you utilize? Do you support canceling of the request?
(e) If you were to examine the stack trace upon getting the
page fault, you might be able to tell us where (in which
module) the page fault occurs which should be able to shed
more light on the problem.
(f) Do ensure that you do not forward any requests below with
a spin-lock OR fast-mutex acquired which would raise the
IRQL of the dispatching thread. This would be bad since the
driver(s) below you in the stack might allocate paged
memory and then encounter a fault that would be fatal.
From: [email protected]
]On Behalf Of Jamey Kirby
Sent: Wednesday, April 26, 2000 9:53 PM
To: File Systems Developers
Subject: [ntfsd] Re: page fault when send queued irp to a lower level
I suspect that you can not queue the IPR_MJ_CREATE IRP to a worker thread
because the create call MUST be processed by the FSD in the context of the
Just a thought, I have not verified this.
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]
]On Behalf Of [email protected]
> Sent: Wednesday, April 26, 2000 12:15 PM
> To: File Systems Developers
> Subject: [ntfsd] Re: page fault when send queued irp to a lower level
> Sorry and allow me to rephrase my question again because I feel the
> generous response I got misinterpret my question.
> In a file system filter driver, I intercept IRP_MJ_CREATE requests and
> queue it in an driver maintained queue, then
> Irp->IoStatus.Status = STATUS_PENDING;
> Then I de-queue an service IRP setup by an User mode service, send the
> necessary information to it to process.
> After the service finished its task, it send the result back to
> the filter
> driver. It is at this point I dequeue the original IRP_MJ_CREATE request
> and do the following as in what in Rajeev Nagar's sfilter sample,
> ..get pointer to extension
> ..set a completion routine
> ..find target object from extension
> IoCallDriver(pTargetDeviceObject, Irp);
> If the call return back from IoCallDriver, then everything is fine.
> Otherwise, I got page fault in SoftIce and this happen before the
> completion routine get called.
> My understanding is that Irp is allocated in NonPage space, I also do all
> my allocation in NonPage space. So my question is what caused this page
> fault in lower level driver. Is it because I handle the above in
> process context ? If yes, is there a way to switch to that context ?
> Or is there other thing I miss that the lower level driver is
> expecting me
> to comply ?
> I would appreciate any help that I can get and hopefully it is more clear
> in regard to the problem than my previous post !
> Jack Cheng
> (Curriculum Corp.)
> You are currently subscribed to ntfsd as: [email protected]
> To unsubscribe send a blank email to $subst('Email.Unsub')
You are currently subscribed to ntfsd as: [email protected]
To unsubscribe send a blank email to $subst('Email.Unsub')