(a) I assume that you return STATUS_PENDING after the initial
queuing of the IRP. Please check that this is indeed the
case.
(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
panic.
(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.
HTH,
- rajeev
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]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
driver
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
calling process.
Just a thought, I have not verified this.
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of xxxxx@erinet.com
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
driverSorry 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;
IoMarkIrpPending(Irp);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,IoCopyCurrentIrpStackLocationToNext(Irp);
…get pointer to extension
…set a completion routine
…find target object from extensionthen
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
different
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 !Thanx,
Jack Cheng
(Curriculum Corp.)
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@ntcoresvcs.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)