Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTFSD
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Re: page fault when send queued irp to a lower level driver <LYR1318-2241-2000.04.26-12.29.46--rnaga

OSR_Community_UserOSR_Community_User Member Posts: 110,217
(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: [email protected]
[mailto:[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
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: [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
> driver
>
>
> 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;
> 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 extension
>
> then
>
> 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: [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')

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    First I like to thank all that reply to my question. The (f) in Rajeev's
    post is exactly my problem. I wrap that functionality in a function that is
    enclosed by a pair of get/release SPIN-LOCK.

    Wow, a good lesson learned, thanks again !

    Jack Cheng
    (Curriculum Corp.)
    ----- Original Message -----
    From: Rajeev Nagar <[email protected]>
    To: File Systems Developers <[email protected]>
    Sent: Wednesday, April 26, 2000 12:08 AM
    Subject: [ntfsd] Re: page fault when send queued irp to a lower level driver
    <LYR1318-2241-2000.04.26-12.29.46--rnagar#[email protected]>


    > (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: [email protected]
    > [mailto:[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
    > 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: [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
    > > driver
    > >
    > >
    > > 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;
    > > 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 extension
    > >
    > > then
    > >
    > > 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: [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')
    >
    >
    > ---
    > You are currently subscribed to ntfsd as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Hello David,

    I am cc'ing the list assuming that others may have the
    same question.

    The answer to your query:

    When the IRP is eventually completed, the IoStatus.Status
    field should contain the "real" results of the operation
    and not "pending". By definition, the fact that you are completing
    an IRP implies it is not pending any more ...

    The I/O Manager, therefore, checks for the above error and
    flags it in the checked/debug build.

    Corollary: when you or any driver returns pending, the IRP
    still "belongs" to the driver that returned STATUS_PENDING
    and hence, no other module would examine the contents
    of the IoStatus.Status field. Therefore, the contents being
    set to STATUS_PENDING is an irrelevant operation.

    HTH.

    Regards,

    - rajeev

    -----Original Message-----
    From: david c. steere [mailto:[email protected]]
    Sent: Friday, April 28, 2000 11:12 AM
    To: Rajeev Nagar
    Subject: Re: [ntfsd] Re: page fault when send queued irp to a lower
    level driver



    Hi, I had a few questions regarding your answer to somebody else's question.
    I hope you don't mind that I'm asking you directly.

    At 09:38 AM 4/26/00 +0530, you wrote:
    >(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.

    How do you impersonate a caller?

    >(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.

    Why is this an error? I would assume that the return code from a dispatch
    routine should match the IoStatus.Status field.

    Thanks!

    david





    >(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: [email protected]
    >[mailto:[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
    >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: [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
    > > driver
    > >
    > >
    > > 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;
    > > 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 extension
    > >
    > > then
    > >
    > > 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: [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')
    >
    >
    >---
    >You are currently subscribed to ntfsd as: [email protected]
    >To unsubscribe send a blank email to $subst('Email.Unsub')
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > post is exactly my problem. I wrap that functionality in a function that
    is
    > enclosed by a pair of get/release SPIN-LOCK.
    >
    > Wow, a good lesson learned, thanks again !

    One of the good rules is "never call anything complex while holding a spin
    lock".

    Max
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE