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

Home NTDEV

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/


Driver Verifier error message

OSR_Community_UserOSR_Community_User Member Posts: 110,217
I'm getting the following DriverVerifier error message in the debugger:

"An IRP dispatch handler has returned without passing down or completing
this Irp or someone forgot to return STATUS_PENDING."

It appears that it's mad a me returning STATUS_MORE_PROCESSING_REQUIRED
after I call PoRequestPowerIrp(..). However, I'm following the exact steps
specified in the DDK, below.

FROM DDK:
1) Set an IoCompletion routine in the system set-power IRP.
2) Set up the IRP stack location for the next lower driver by
calling IoCopyCurrentIrpStackLocationToNext.
3) Call PoCallDriver to pass the IRP to the next-lower driver.
4) Propagate the status returned by PoCallDriver as the return value
of its DispatchPower routine.
In the IoCompletion routine, the driver sends a device set-power IRP as
follows:
1) Inspect the IRP to get the requested system power state. Choose
an appropriate device power state for that system state.
2) Call PoRequestPowerIrp to send an IRP_MN_SET_POWER for the device
power state determined in Step 1. The power policy owner must send the
device set-power request even if the device is already in that state.
3) Specify a callback routine (CompletionFunction) in the call to
PoRequestPowerIrp and pass the system IRP in the Context area.
4) Return STATUS_MORE_PROCESSING_REQUIRED from the IoCompletion
routine, so that the driver can finish processing the system set-power IRP
in the callback routine.

Any ideas?

Daniel

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Are you calling IoCompleteRequest()? You must do this yourself if you return
    STATUS_MORE_PROCESSING_REQUIRED.

    Jamey

    > -----Original Message-----
    > From: [email protected]
    > [mailto:[email protected]]On Behalf Of Nemiroff, Daniel
    > Sent: Thursday, May 11, 2000 10:11 AM
    > To: NT Developers Interest List
    > Subject: [ntdev] Driver Verifier error message
    >
    >
    > I'm getting the following DriverVerifier error message in the debugger:
    >
    > "An IRP dispatch handler has returned without passing down or completing
    > this Irp or someone forgot to return STATUS_PENDING."
    >
    > It appears that it's mad a me returning STATUS_MORE_PROCESSING_REQUIRED
    > after I call PoRequestPowerIrp(..). However, I'm following the
    > exact steps
    > specified in the DDK, below.
    >
    > FROM DDK:
    > 1) Set an IoCompletion routine in the system set-power IRP.
    > 2) Set up the IRP stack location for the next lower driver by
    > calling IoCopyCurrentIrpStackLocationToNext.
    > 3) Call PoCallDriver to pass the IRP to the next-lower driver.
    > 4) Propagate the status returned by PoCallDriver as the return value
    > of its DispatchPower routine.
    > In the IoCompletion routine, the driver sends a device set-power IRP as
    > follows:
    > 1) Inspect the IRP to get the requested system power state. Choose
    > an appropriate device power state for that system state.
    > 2) Call PoRequestPowerIrp to send an IRP_MN_SET_POWER for the device
    > power state determined in Step 1. The power policy owner must send the
    > device set-power request even if the device is already in that state.
    > 3) Specify a callback routine (CompletionFunction) in the call to
    > PoRequestPowerIrp and pass the system IRP in the Context area.
    > 4) Return STATUS_MORE_PROCESSING_REQUIRED from the IoCompletion
    > routine, so that the driver can finish processing the system set-power IRP
    > in the callback routine.
    >
    > Any ideas?
    >
    > Daniel
    >
    >
    > ---
    > You are currently subscribed to ntdev as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    As I call IoCompleteRequest in the callback routine I set in
    PoRequestPowerIrp(..). DriverVerifier signals an error before it sends the
    DevicePower Irp I requested with PoRequestPowerIrp.

    The DDK states what to do in the callback routine set in PoRequestPowerIrp.
    I follow it to the letter:

    ***From the DDK***

    The callback routine must do the following:

    1) Call PoStartNextPowerIrp to start the next power IRP.
    2) Complete the system set-power IRP (IoCompleteRequest) with the status
    returned for the device set-power IRP.
    3) Return the status with which the set-power IRPs completed.

    ***
    -Daniel
    -----Original Message-----
    From: Jamey Kirby [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 10:13 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    Are you calling IoCompleteRequest()? You must do this yourself if you return
    STATUS_MORE_PROCESSING_REQUIRED.

    Jamey

    > -----Original Message-----
    > From: [email protected]
    > [mailto:[email protected]]On Behalf Of Nemiroff, Daniel
    > Sent: Thursday, May 11, 2000 10:11 AM
    > To: NT Developers Interest List
    > Subject: [ntdev] Driver Verifier error message
    >
    >
    > I'm getting the following DriverVerifier error message in the debugger:
    >
    > "An IRP dispatch handler has returned without passing down or completing
    > this Irp or someone forgot to return STATUS_PENDING."
    >
    > It appears that it's mad a me returning STATUS_MORE_PROCESSING_REQUIRED
    > after I call PoRequestPowerIrp(..). However, I'm following the
    > exact steps
    > specified in the DDK, below.
    >
    > FROM DDK:
    > 1) Set an IoCompletion routine in the system set-power IRP.
    > 2) Set up the IRP stack location for the next lower driver by
    > calling IoCopyCurrentIrpStackLocationToNext.
    > 3) Call PoCallDriver to pass the IRP to the next-lower driver.
    > 4) Propagate the status returned by PoCallDriver as the return value
    > of its DispatchPower routine.
    > In the IoCompletion routine, the driver sends a device set-power IRP as
    > follows:
    > 1) Inspect the IRP to get the requested system power state. Choose
    > an appropriate device power state for that system state.
    > 2) Call PoRequestPowerIrp to send an IRP_MN_SET_POWER for the device
    > power state determined in Step 1. The power policy owner must send the
    > device set-power request even if the device is already in that state.
    > 3) Specify a callback routine (CompletionFunction) in the call to
    > PoRequestPowerIrp and pass the system IRP in the Context area.
    > 4) Return STATUS_MORE_PROCESSING_REQUIRED from the IoCompletion
    > routine, so that the driver can finish processing the system set-power IRP
    > in the callback routine.
    >
    > Any ideas?
    >
    > Daniel
    >
    >
    > ---
    > You are currently subscribed to ntdev as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >


    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')
  • Eliyas_YakubEliyas_Yakub Member Posts: 229
    This stuff is pretty complex and DDK documentation is not very clear. The
    doc has not described several little steps that one needs to perform to
    avoid violating IRP rules. It just tells you what you need to conceptually.
    Not going into lot of details what you are doing wrong, I would suggest you
    to follow the function driver's power handling logic of toaster package. It
    shows in terms of real code what the doc is trying to explain in words. It
    will save your lot of time and energy.

    -Eliyas

    -----Original Message-----
    From: Nemiroff, Daniel [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 10:33 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    As I call IoCompleteRequest in the callback routine I set in
    PoRequestPowerIrp(..). DriverVerifier signals an error before it sends the
    DevicePower Irp I requested with PoRequestPowerIrp.

    The DDK states what to do in the callback routine set in PoRequestPowerIrp.
    I follow it to the letter:

    ***From the DDK***

    The callback routine must do the following:

    1) Call PoStartNextPowerIrp to start the next power IRP.
    2) Complete the system set-power IRP (IoCompleteRequest) with the status
    returned for the device set-power IRP.
    3) Return the status with which the set-power IRPs completed.

    ***
    -Daniel
    -----Original Message-----
    From: Jamey Kirby [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 10:13 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    Are you calling IoCompleteRequest()? You must do this yourself if you return
    STATUS_MORE_PROCESSING_REQUIRED.

    Jamey

    > -----Original Message-----
    > From: [email protected]
    > [mailto:[email protected]]On Behalf Of Nemiroff, Daniel
    > Sent: Thursday, May 11, 2000 10:11 AM
    > To: NT Developers Interest List
    > Subject: [ntdev] Driver Verifier error message
    >
    >
    > I'm getting the following DriverVerifier error message in the debugger:
    >
    > "An IRP dispatch handler has returned without passing down or completing
    > this Irp or someone forgot to return STATUS_PENDING."
    >
    > It appears that it's mad a me returning STATUS_MORE_PROCESSING_REQUIRED
    > after I call PoRequestPowerIrp(..). However, I'm following the
    > exact steps
    > specified in the DDK, below.
    >
    > FROM DDK:
    > 1) Set an IoCompletion routine in the system set-power IRP.
    > 2) Set up the IRP stack location for the next lower driver by
    > calling IoCopyCurrentIrpStackLocationToNext.
    > 3) Call PoCallDriver to pass the IRP to the next-lower driver.
    > 4) Propagate the status returned by PoCallDriver as the return value
    > of its DispatchPower routine.
    > In the IoCompletion routine, the driver sends a device set-power IRP as
    > follows:
    > 1) Inspect the IRP to get the requested system power state. Choose
    > an appropriate device power state for that system state.
    > 2) Call PoRequestPowerIrp to send an IRP_MN_SET_POWER for the device
    > power state determined in Step 1. The power policy owner must send the
    > device set-power request even if the device is already in that state.
    > 3) Specify a callback routine (CompletionFunction) in the call to
    > PoRequestPowerIrp and pass the system IRP in the Context area.
    > 4) Return STATUS_MORE_PROCESSING_REQUIRED from the IoCompletion
    > routine, so that the driver can finish processing the system set-power IRP
    > in the callback routine.
    >
    > Any ideas?
    >
    > Daniel
    >
    >
    > ---
    > You are currently subscribed to ntdev as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >


    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')



    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Eliyas:

    Just looked at the Toaster/func sample and it's pretty strait forward.

    However, I've always been told that we have to handle PowerUp and PowerDown
    conditions differently.

    Is this true?

    Thanks,

    Daniel

    -----Original Message-----
    From: Eliyas Yakub [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 11:09 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    This stuff is pretty complex and DDK documentation is not very clear. The
    doc has not described several little steps that one needs to perform to
    avoid violating IRP rules. It just tells you what you need to conceptually.
    Not going into lot of details what you are doing wrong, I would suggest you
    to follow the function driver's power handling logic of toaster package. It
    shows in terms of real code what the doc is trying to explain in words. It
    will save your lot of time and energy.

    -Eliyas

    -----Original Message-----
    From: Nemiroff, Daniel [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 10:33 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    As I call IoCompleteRequest in the callback routine I set in
    PoRequestPowerIrp(..). DriverVerifier signals an error before it sends the
    DevicePower Irp I requested with PoRequestPowerIrp.

    The DDK states what to do in the callback routine set in PoRequestPowerIrp.
    I follow it to the letter:

    ***From the DDK***

    The callback routine must do the following:

    1) Call PoStartNextPowerIrp to start the next power IRP.
    2) Complete the system set-power IRP (IoCompleteRequest) with the status
    returned for the device set-power IRP.
    3) Return the status with which the set-power IRPs completed.

    ***
    -Daniel
    -----Original Message-----
    From: Jamey Kirby [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 10:13 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    Are you calling IoCompleteRequest()? You must do this yourself if you return
    STATUS_MORE_PROCESSING_REQUIRED.

    Jamey

    > -----Original Message-----
    > From: [email protected]
    > [mailto:[email protected]]On Behalf Of Nemiroff, Daniel
    > Sent: Thursday, May 11, 2000 10:11 AM
    > To: NT Developers Interest List
    > Subject: [ntdev] Driver Verifier error message
    >
    >
    > I'm getting the following DriverVerifier error message in the debugger:
    >
    > "An IRP dispatch handler has returned without passing down or completing
    > this Irp or someone forgot to return STATUS_PENDING."
    >
    > It appears that it's mad a me returning STATUS_MORE_PROCESSING_REQUIRED
    > after I call PoRequestPowerIrp(..). However, I'm following the
    > exact steps
    > specified in the DDK, below.
    >
    > FROM DDK:
    > 1) Set an IoCompletion routine in the system set-power IRP.
    > 2) Set up the IRP stack location for the next lower driver by
    > calling IoCopyCurrentIrpStackLocationToNext.
    > 3) Call PoCallDriver to pass the IRP to the next-lower driver.
    > 4) Propagate the status returned by PoCallDriver as the return value
    > of its DispatchPower routine.
    > In the IoCompletion routine, the driver sends a device set-power IRP as
    > follows:
    > 1) Inspect the IRP to get the requested system power state. Choose
    > an appropriate device power state for that system state.
    > 2) Call PoRequestPowerIrp to send an IRP_MN_SET_POWER for the device
    > power state determined in Step 1. The power policy owner must send the
    > device set-power request even if the device is already in that state.
    > 3) Specify a callback routine (CompletionFunction) in the call to
    > PoRequestPowerIrp and pass the system IRP in the Context area.
    > 4) Return STATUS_MORE_PROCESSING_REQUIRED from the IoCompletion
    > routine, so that the driver can finish processing the system set-power IRP
    > in the callback routine.
    >
    > Any ideas?
    >
    > Daniel
    >
    >
    > ---
    > You are currently subscribed to ntdev as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >


    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')



    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')

    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')
  • Eliyas_YakubEliyas_Yakub Member Posts: 229
    Yep. You should also Walter Oney's book to get another perspective on how
    this thing works.

    -----Original Message-----
    From: Nemiroff, Daniel [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 11:24 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    Eliyas:

    Just looked at the Toaster/func sample and it's pretty strait forward.

    However, I've always been told that we have to handle PowerUp and PowerDown
    conditions differently.

    Is this true?

    Thanks,

    Daniel

    -----Original Message-----
    From: Eliyas Yakub [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 11:09 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    This stuff is pretty complex and DDK documentation is not very clear. The
    doc has not described several little steps that one needs to perform to
    avoid violating IRP rules. It just tells you what you need to conceptually.
    Not going into lot of details what you are doing wrong, I would suggest you
    to follow the function driver's power handling logic of toaster package. It
    shows in terms of real code what the doc is trying to explain in words. It
    will save your lot of time and energy.

    -Eliyas

    -----Original Message-----
    From: Nemiroff, Daniel [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 10:33 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    As I call IoCompleteRequest in the callback routine I set in
    PoRequestPowerIrp(..). DriverVerifier signals an error before it sends the
    DevicePower Irp I requested with PoRequestPowerIrp.

    The DDK states what to do in the callback routine set in PoRequestPowerIrp.
    I follow it to the letter:

    ***From the DDK***

    The callback routine must do the following:

    1) Call PoStartNextPowerIrp to start the next power IRP.
    2) Complete the system set-power IRP (IoCompleteRequest) with the status
    returned for the device set-power IRP.
    3) Return the status with which the set-power IRPs completed.

    ***
    -Daniel
    -----Original Message-----
    From: Jamey Kirby [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 10:13 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    Are you calling IoCompleteRequest()? You must do this yourself if you return
    STATUS_MORE_PROCESSING_REQUIRED.

    Jamey

    > -----Original Message-----
    > From: [email protected]
    > [mailto:[email protected]]On Behalf Of Nemiroff, Daniel
    > Sent: Thursday, May 11, 2000 10:11 AM
    > To: NT Developers Interest List
    > Subject: [ntdev] Driver Verifier error message
    >
    >
    > I'm getting the following DriverVerifier error message in the debugger:
    >
    > "An IRP dispatch handler has returned without passing down or completing
    > this Irp or someone forgot to return STATUS_PENDING."
    >
    > It appears that it's mad a me returning STATUS_MORE_PROCESSING_REQUIRED
    > after I call PoRequestPowerIrp(..). However, I'm following the
    > exact steps
    > specified in the DDK, below.
    >
    > FROM DDK:
    > 1) Set an IoCompletion routine in the system set-power IRP.
    > 2) Set up the IRP stack location for the next lower driver by
    > calling IoCopyCurrentIrpStackLocationToNext.
    > 3) Call PoCallDriver to pass the IRP to the next-lower driver.
    > 4) Propagate the status returned by PoCallDriver as the return value
    > of its DispatchPower routine.
    > In the IoCompletion routine, the driver sends a device set-power IRP as
    > follows:
    > 1) Inspect the IRP to get the requested system power state. Choose
    > an appropriate device power state for that system state.
    > 2) Call PoRequestPowerIrp to send an IRP_MN_SET_POWER for the device
    > power state determined in Step 1. The power policy owner must send the
    > device set-power request even if the device is already in that state.
    > 3) Specify a callback routine (CompletionFunction) in the call to
    > PoRequestPowerIrp and pass the system IRP in the Context area.
    > 4) Return STATUS_MORE_PROCESSING_REQUIRED from the IoCompletion
    > routine, so that the driver can finish processing the system set-power IRP
    > in the callback routine.
    >
    > Any ideas?
    >
    > Daniel
    >
    >
    > ---
    > You are currently subscribed to ntdev as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >


    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')



    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')

    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')



    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    DriverVerifier complains during the power-up sequence.

    I compared the toaster example with my power-up code path and it's
    functionally identical.

    Right after I return STATUS_MORE_PROCESSING_REQUIRED Verifier complains.
    Any ideas?

    Daniel

    -----Original Message-----
    From: Eliyas Yakub [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 11:37 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    Yep. You should also Walter Oney's book to get another perspective on how
    this thing works.

    -----Original Message-----
    From: Nemiroff, Daniel [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 11:24 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    Eliyas:

    Just looked at the Toaster/func sample and it's pretty strait forward.

    However, I've always been told that we have to handle PowerUp and PowerDown
    conditions differently.

    Is this true?

    Thanks,

    Daniel

    -----Original Message-----
    From: Eliyas Yakub [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 11:09 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    This stuff is pretty complex and DDK documentation is not very clear. The
    doc has not described several little steps that one needs to perform to
    avoid violating IRP rules. It just tells you what you need to conceptually.
    Not going into lot of details what you are doing wrong, I would suggest you
    to follow the function driver's power handling logic of toaster package. It
    shows in terms of real code what the doc is trying to explain in words. It
    will save your lot of time and energy.

    -Eliyas

    -----Original Message-----
    From: Nemiroff, Daniel [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 10:33 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    As I call IoCompleteRequest in the callback routine I set in
    PoRequestPowerIrp(..). DriverVerifier signals an error before it sends the
    DevicePower Irp I requested with PoRequestPowerIrp.

    The DDK states what to do in the callback routine set in PoRequestPowerIrp.
    I follow it to the letter:

    ***From the DDK***

    The callback routine must do the following:

    1) Call PoStartNextPowerIrp to start the next power IRP.
    2) Complete the system set-power IRP (IoCompleteRequest) with the status
    returned for the device set-power IRP.
    3) Return the status with which the set-power IRPs completed.

    ***
    -Daniel
    -----Original Message-----
    From: Jamey Kirby [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 10:13 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    Are you calling IoCompleteRequest()? You must do this yourself if you return
    STATUS_MORE_PROCESSING_REQUIRED.

    Jamey

    > -----Original Message-----
    > From: [email protected]
    > [mailto:[email protected]]On Behalf Of Nemiroff, Daniel
    > Sent: Thursday, May 11, 2000 10:11 AM
    > To: NT Developers Interest List
    > Subject: [ntdev] Driver Verifier error message
    >
    >
    > I'm getting the following DriverVerifier error message in the debugger:
    >
    > "An IRP dispatch handler has returned without passing down or completing
    > this Irp or someone forgot to return STATUS_PENDING."
    >
    > It appears that it's mad a me returning STATUS_MORE_PROCESSING_REQUIRED
    > after I call PoRequestPowerIrp(..). However, I'm following the
    > exact steps
    > specified in the DDK, below.
    >
    > FROM DDK:
    > 1) Set an IoCompletion routine in the system set-power IRP.
    > 2) Set up the IRP stack location for the next lower driver by
    > calling IoCopyCurrentIrpStackLocationToNext.
    > 3) Call PoCallDriver to pass the IRP to the next-lower driver.
    > 4) Propagate the status returned by PoCallDriver as the return value
    > of its DispatchPower routine.
    > In the IoCompletion routine, the driver sends a device set-power IRP as
    > follows:
    > 1) Inspect the IRP to get the requested system power state. Choose
    > an appropriate device power state for that system state.
    > 2) Call PoRequestPowerIrp to send an IRP_MN_SET_POWER for the device
    > power state determined in Step 1. The power policy owner must send the
    > device set-power request even if the device is already in that state.
    > 3) Specify a callback routine (CompletionFunction) in the call to
    > PoRequestPowerIrp and pass the system IRP in the Context area.
    > 4) Return STATUS_MORE_PROCESSING_REQUIRED from the IoCompletion
    > routine, so that the driver can finish processing the system set-power IRP
    > in the callback routine.
    >
    > Any ideas?
    >
    > Daniel
    >
    >
    > ---
    > You are currently subscribed to ntdev as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >


    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')



    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')

    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')



    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')

    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')
  • OSR_Community_User-35OSR_Community_User-35 Member Posts: 154
    The instructions you cited say your dispatch should propagate the
    status returned from the lower driver; but if the lower driver does
    not return STATUS_PENDING, but you are going to defer completion
    processing, maybe your dispatch must return STATUS_PENDING?

    -----------------------------------------------------------------------
    Dave Cox
    Hewlett-Packard Co.
    HPSO/SSMO (Santa Barbara)
    https://ecardfile.com/id/Dave+Cox


    -----Original Message-----
    From: Nemiroff, Daniel [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 1:27 PM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    DriverVerifier complains during the power-up sequence.

    I compared the toaster example with my power-up code path and it's
    functionally identical.

    Right after I return STATUS_MORE_PROCESSING_REQUIRED Verifier complains.
    Any ideas?

    Daniel

    -----Original Message-----
    From: Eliyas Yakub [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 11:37 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    Yep. You should also Walter Oney's book to get another perspective on how
    this thing works.

    -----Original Message-----
    From: Nemiroff, Daniel [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 11:24 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    Eliyas:

    Just looked at the Toaster/func sample and it's pretty strait forward.

    However, I've always been told that we have to handle PowerUp and PowerDown
    conditions differently.

    Is this true?

    Thanks,

    Daniel

    -----Original Message-----
    From: Eliyas Yakub [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 11:09 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    This stuff is pretty complex and DDK documentation is not very clear. The
    doc has not described several little steps that one needs to perform to
    avoid violating IRP rules. It just tells you what you need to conceptually.
    Not going into lot of details what you are doing wrong, I would suggest you
    to follow the function driver's power handling logic of toaster package. It
    shows in terms of real code what the doc is trying to explain in words. It
    will save your lot of time and energy.

    -Eliyas

    -----Original Message-----
    From: Nemiroff, Daniel [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 10:33 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    As I call IoCompleteRequest in the callback routine I set in
    PoRequestPowerIrp(..). DriverVerifier signals an error before it sends the
    DevicePower Irp I requested with PoRequestPowerIrp.

    The DDK states what to do in the callback routine set in PoRequestPowerIrp.
    I follow it to the letter:

    ***From the DDK***

    The callback routine must do the following:

    1) Call PoStartNextPowerIrp to start the next power IRP.
    2) Complete the system set-power IRP (IoCompleteRequest) with the status
    returned for the device set-power IRP.
    3) Return the status with which the set-power IRPs completed.

    ***
    -Daniel
    -----Original Message-----
    From: Jamey Kirby [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 10:13 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    Are you calling IoCompleteRequest()? You must do this yourself if you return
    STATUS_MORE_PROCESSING_REQUIRED.

    Jamey

    > -----Original Message-----
    > From: [email protected]
    > [mailto:[email protected]]On Behalf Of Nemiroff, Daniel
    > Sent: Thursday, May 11, 2000 10:11 AM
    > To: NT Developers Interest List
    > Subject: [ntdev] Driver Verifier error message
    >
    >
    > I'm getting the following DriverVerifier error message in the debugger:
    >
    > "An IRP dispatch handler has returned without passing down or completing
    > this Irp or someone forgot to return STATUS_PENDING."
    >
    > It appears that it's mad a me returning STATUS_MORE_PROCESSING_REQUIRED
    > after I call PoRequestPowerIrp(..). However, I'm following the
    > exact steps
    > specified in the DDK, below.
    >
    > FROM DDK:
    > 1) Set an IoCompletion routine in the system set-power IRP.
    > 2) Set up the IRP stack location for the next lower driver by
    > calling IoCopyCurrentIrpStackLocationToNext.
    > 3) Call PoCallDriver to pass the IRP to the next-lower driver.
    > 4) Propagate the status returned by PoCallDriver as the return value
    > of its DispatchPower routine.
    > In the IoCompletion routine, the driver sends a device set-power IRP as
    > follows:
    > 1) Inspect the IRP to get the requested system power state. Choose
    > an appropriate device power state for that system state.
    > 2) Call PoRequestPowerIrp to send an IRP_MN_SET_POWER for the device
    > power state determined in Step 1. The power policy owner must send the
    > device set-power request even if the device is already in that state.
    > 3) Specify a callback routine (CompletionFunction) in the call to
    > PoRequestPowerIrp and pass the system IRP in the Context area.
    > 4) Return STATUS_MORE_PROCESSING_REQUIRED from the IoCompletion
    > routine, so that the driver can finish processing the system set-power IRP
    > in the callback routine.
    >
    > Any ideas?
    >
    > Daniel
    >
    >
    > ---
    > You are currently subscribed to ntdev as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >


    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')



    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')

    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')



    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')

    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')



    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    You hit it on the head.

    In my initial System PowerIrp handler.

    Bad Code;
    return PoCallDriver(FdoDx->DeviceToSendIrpsTo, Irp);

    Good code;
    PoCallDriver(FdoDx->DeviceToSendIrpsTo, Irp);
    return STATUS_PENDING;

    daniel

    -----Original Message-----
    From: COX,DAVID (HP-Roseville,ex1) [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 1:59 PM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    The instructions you cited say your dispatch should propagate the
    status returned from the lower driver; but if the lower driver does
    not return STATUS_PENDING, but you are going to defer completion
    processing, maybe your dispatch must return STATUS_PENDING?

    -----------------------------------------------------------------------
    Dave Cox
    Hewlett-Packard Co.
    HPSO/SSMO (Santa Barbara)
    https://ecardfile.com/id/Dave+Cox


    -----Original Message-----
    From: Nemiroff, Daniel [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 1:27 PM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    DriverVerifier complains during the power-up sequence.

    I compared the toaster example with my power-up code path and it's
    functionally identical.

    Right after I return STATUS_MORE_PROCESSING_REQUIRED Verifier complains.
    Any ideas?

    Daniel

    -----Original Message-----
    From: Eliyas Yakub [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 11:37 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    Yep. You should also Walter Oney's book to get another perspective on how
    this thing works.

    -----Original Message-----
    From: Nemiroff, Daniel [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 11:24 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    Eliyas:

    Just looked at the Toaster/func sample and it's pretty strait forward.

    However, I've always been told that we have to handle PowerUp and PowerDown
    conditions differently.

    Is this true?

    Thanks,

    Daniel

    -----Original Message-----
    From: Eliyas Yakub [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 11:09 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    This stuff is pretty complex and DDK documentation is not very clear. The
    doc has not described several little steps that one needs to perform to
    avoid violating IRP rules. It just tells you what you need to conceptually.
    Not going into lot of details what you are doing wrong, I would suggest you
    to follow the function driver's power handling logic of toaster package. It
    shows in terms of real code what the doc is trying to explain in words. It
    will save your lot of time and energy.

    -Eliyas

    -----Original Message-----
    From: Nemiroff, Daniel [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 10:33 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    As I call IoCompleteRequest in the callback routine I set in
    PoRequestPowerIrp(..). DriverVerifier signals an error before it sends the
    DevicePower Irp I requested with PoRequestPowerIrp.

    The DDK states what to do in the callback routine set in PoRequestPowerIrp.
    I follow it to the letter:

    ***From the DDK***

    The callback routine must do the following:

    1) Call PoStartNextPowerIrp to start the next power IRP.
    2) Complete the system set-power IRP (IoCompleteRequest) with the status
    returned for the device set-power IRP.
    3) Return the status with which the set-power IRPs completed.

    ***
    -Daniel
    -----Original Message-----
    From: Jamey Kirby [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 10:13 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    Are you calling IoCompleteRequest()? You must do this yourself if you return
    STATUS_MORE_PROCESSING_REQUIRED.

    Jamey

    > -----Original Message-----
    > From: [email protected]
    > [mailto:[email protected]]On Behalf Of Nemiroff, Daniel
    > Sent: Thursday, May 11, 2000 10:11 AM
    > To: NT Developers Interest List
    > Subject: [ntdev] Driver Verifier error message
    >
    >
    > I'm getting the following DriverVerifier error message in the debugger:
    >
    > "An IRP dispatch handler has returned without passing down or completing
    > this Irp or someone forgot to return STATUS_PENDING."
    >
    > It appears that it's mad a me returning STATUS_MORE_PROCESSING_REQUIRED
    > after I call PoRequestPowerIrp(..). However, I'm following the
    > exact steps
    > specified in the DDK, below.
    >
    > FROM DDK:
    > 1) Set an IoCompletion routine in the system set-power IRP.
    > 2) Set up the IRP stack location for the next lower driver by
    > calling IoCopyCurrentIrpStackLocationToNext.
    > 3) Call PoCallDriver to pass the IRP to the next-lower driver.
    > 4) Propagate the status returned by PoCallDriver as the return value
    > of its DispatchPower routine.
    > In the IoCompletion routine, the driver sends a device set-power IRP as
    > follows:
    > 1) Inspect the IRP to get the requested system power state. Choose
    > an appropriate device power state for that system state.
    > 2) Call PoRequestPowerIrp to send an IRP_MN_SET_POWER for the device
    > power state determined in Step 1. The power policy owner must send the
    > device set-power request even if the device is already in that state.
    > 3) Specify a callback routine (CompletionFunction) in the call to
    > PoRequestPowerIrp and pass the system IRP in the Context area.
    > 4) Return STATUS_MORE_PROCESSING_REQUIRED from the IoCompletion
    > routine, so that the driver can finish processing the system set-power IRP
    > in the callback routine.
    >
    > Any ideas?
    >
    > Daniel
    >
    >
    > ---
    > You are currently subscribed to ntdev as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >


    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')



    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')

    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')



    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')

    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')



    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')

    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,752
    Perhaps you should run verifier against the toaster and then:

    if it passes go back and re-examine your claim that is functionally
    identical;

    if it fails ask Eliyas to provide a toaster sample that passes verify :-)


    Mark Roddy
    Windows 2000/NT Consultant
    Hollis Technology Solutions
    www.hollistech.com

    -----Original Message-----
    From: [email protected]
    [mailto:[email protected]]On Behalf Of Nemiroff, Daniel
    Sent: Thursday, May 11, 2000 4:27 PM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    DriverVerifier complains during the power-up sequence.

    I compared the toaster example with my power-up code path and it's
    functionally identical.

    Right after I return STATUS_MORE_PROCESSING_REQUIRED Verifier complains.
    Any ideas?

    Daniel

    -----Original Message-----
    From: Eliyas Yakub [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 11:37 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    Yep. You should also Walter Oney's book to get another perspective on how
    this thing works.

    -----Original Message-----
    From: Nemiroff, Daniel [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 11:24 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    Eliyas:

    Just looked at the Toaster/func sample and it's pretty strait forward.

    However, I've always been told that we have to handle PowerUp and PowerDown
    conditions differently.

    Is this true?

    Thanks,

    Daniel

    -----Original Message-----
    From: Eliyas Yakub [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 11:09 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    This stuff is pretty complex and DDK documentation is not very clear. The
    doc has not described several little steps that one needs to perform to
    avoid violating IRP rules. It just tells you what you need to conceptually.
    Not going into lot of details what you are doing wrong, I would suggest you
    to follow the function driver's power handling logic of toaster package. It
    shows in terms of real code what the doc is trying to explain in words. It
    will save your lot of time and energy.

    -Eliyas

    -----Original Message-----
    From: Nemiroff, Daniel [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 10:33 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    As I call IoCompleteRequest in the callback routine I set in
    PoRequestPowerIrp(..). DriverVerifier signals an error before it sends the
    DevicePower Irp I requested with PoRequestPowerIrp.

    The DDK states what to do in the callback routine set in PoRequestPowerIrp.
    I follow it to the letter:

    ***From the DDK***

    The callback routine must do the following:

    1) Call PoStartNextPowerIrp to start the next power IRP.
    2) Complete the system set-power IRP (IoCompleteRequest) with the status
    returned for the device set-power IRP.
    3) Return the status with which the set-power IRPs completed.

    ***
    -Daniel
    -----Original Message-----
    From: Jamey Kirby [mailto:[email protected]]
    Sent: Thursday, May 11, 2000 10:13 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Driver Verifier error message


    Are you calling IoCompleteRequest()? You must do this yourself if you return
    STATUS_MORE_PROCESSING_REQUIRED.

    Jamey

    > -----Original Message-----
    > From: [email protected]
    > [mailto:[email protected]]On Behalf Of Nemiroff, Daniel
    > Sent: Thursday, May 11, 2000 10:11 AM
    > To: NT Developers Interest List
    > Subject: [ntdev] Driver Verifier error message
    >
    >
    > I'm getting the following DriverVerifier error message in the debugger:
    >
    > "An IRP dispatch handler has returned without passing down or completing
    > this Irp or someone forgot to return STATUS_PENDING."
    >
    > It appears that it's mad a me returning STATUS_MORE_PROCESSING_REQUIRED
    > after I call PoRequestPowerIrp(..). However, I'm following the
    > exact steps
    > specified in the DDK, below.
    >
    > FROM DDK:
    > 1) Set an IoCompletion routine in the system set-power IRP.
    > 2) Set up the IRP stack location for the next lower driver by
    > calling IoCopyCurrentIrpStackLocationToNext.
    > 3) Call PoCallDriver to pass the IRP to the next-lower driver.
    > 4) Propagate the status returned by PoCallDriver as the return value
    > of its DispatchPower routine.
    > In the IoCompletion routine, the driver sends a device set-power IRP as
    > follows:
    > 1) Inspect the IRP to get the requested system power state. Choose
    > an appropriate device power state for that system state.
    > 2) Call PoRequestPowerIrp to send an IRP_MN_SET_POWER for the device
    > power state determined in Step 1. The power policy owner must send the
    > device set-power request even if the device is already in that state.
    > 3) Specify a callback routine (CompletionFunction) in the call to
    > PoRequestPowerIrp and pass the system IRP in the Context area.
    > 4) Return STATUS_MORE_PROCESSING_REQUIRED from the IoCompletion
    > routine, so that the driver can finish processing the system set-power IRP
    > in the callback routine.
    >
    > Any ideas?
    >
    > Daniel
    >
    >
    > ---
    > You are currently subscribed to ntdev as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >


    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')



    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')

    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')



    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')

    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')



    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > The instructions you cited say your dispatch should propagate the
    > status returned from the lower driver; but if the lower driver does
    > not return STATUS_PENDING, but you are going to defer completion
    > processing, maybe your dispatch must return STATUS_PENDING?

    As far as I remember the well-known rules:
    1) if you call IoCallDriver in dispatch routine, you a) must not touch the
    IRP
    after this - it can be already deallocated after all and b) you must return
    the
    status returned by IoCallDriver (which is the status the lower one's
    dispatch
    routine returned) to ensure correct propagation of STATUS_PENDING.
    2) if you do not do this, but queue the request to some queues in your
    driver
    for further processing (thus giving things others than the current thread a
    chance to touch the IRP) - you must call IoMarkIrpPending before queuing the
    IRP (before the thread will give the IRP to other code like DPCs) and you
    must return STATUS_PENDING.
    Forgetting to call IoMarkIrpPending will result in a fact that
    IoCompleteRequest will not queue the IopCompleteRequest APC (it will rely
    on IopSynchronousServiceTail to call IopCompleteRequest directly without
    any APCs, and IopSynchronousServiceTail will not do this because
    STATUS_PENDING was returned) - this will result in hung IRP and hung
    umode caller thread.
    Returning status other than STATUS_PENDING will force
    IopSynchronousServiceTail to call IopCompleteRequest directly as a function
    - and in BSOD of deallocating the same IRP twice (IopCompleteRequest will
    be called twice - both as a function and as an APC).
    Violating the _both_ rules in this case will result in IopCompleteRequest
    being called once (as a function, synchronously, from
    IopSynchronousServiceTail), but too early - maybe before
    IoCompleteRequest was called by the DPC or other asynchronous thing - a
    crash also.
    "Use IoMarkIrpPending if you return STATUS_PENDING, and vice versa" -
    this is the rule.
    "Do not return status other than STATUS_PENDING if you have not called
    IoCompleteRequest in the dispatch routine and have not handled the IRP to
    the lower driver" - this is another one.
    3) if you complete the IRP immediately in dispatch routine, than you can
    return status other than STATUS_PENDING. But AFAIK it is safe to write:
    IoMarkIrpPending(Irp);
    IoCompleteRequest(Irp, ...);
    return STATUS_PENDING:
    This seems to result only in slight performance penalty -
    IopCompleteRequest will fire correctly, but as an APC, not as a direct
    function call possible in this case.
    4) if your completion routine returns STATUS_SUCCESS (not
    STATUS_MORE_PROCESSING_REQUIRED - these are the only 2
    permitted returns from the completion routine), then it must contain the:
    if( Irp->PendingReturned )
    IoMarkIrpPending(Irp);
    Forgetting to do so is the same as forgetting the initial IoMarkIrpPending -
    this result in IopCompleteRequest never sent - a hung.

    Power IRPs have some special rules. This is the working code for the
    _function_ driver (running fine on Win98 at least):

    NTSTATUS MyDriverDispatchPower(...)
    {
    if( irpStack->MinorFunction == IRP_MN_SET_POWER )
    return MyDriverSetPowerState(Irp);
    PoStartNextPowerIrp(Irp);
    IoCopyCurrentIrpStackLocationToNext(Irp);
    return PoCallDriver(LowerDeviceObject, Irp);
    }

    NTSTATUS MyDriverSetPowerState(...)
    {
    // For Device power state change, all paths must finish with
    // PoStartNextPowerIrp/IoCompleteRequest or
    // PoStartNextPowerIrp/return PoCallDriver
    // PoSetPowerState must be called before this.
    // For Device shutdown, the hardware shutdown must be executed before
    // this.
    // For Device awaken, a completion routine (ordinary) must be registered
    // by IoSetCompletionRoutine and then the IRP will be passed down by
    // PoStartNextPowerIrp/return PoCallDriver
    // The completion routine will awaken the hardware and return
    // STATUS_SUCCESS.
    // For System power state change - if the state change is shutdown, then
    // shut down the hardware and do
    // PoStartNextPowerIrp/IoCompleteRequest sequence.
    // If the System state change is awaken, then do PoRequestPowerIrp
    // to the stack immediately and specify a completion routine
    // (_power_ completion routine, not ordinary one).
    // The power completion routine will call
    // PoStartNextPowerIrp/IoCompleteRequest sequence for the _original_
    // power IRP passed to it in Context parameter.
    }

    The working sequence for the _bus_ driver (for PDOs):
    - PoSetPowerState
    - PoStartNextPowerIrp
    - IoCompleteRequest

    AFAIK the problem is that IO/PnP manager maintains a special queue of
    power IRPs per each stack (or maybe even per each device object). This is
    done (maybe?) to support inrush power IRPs. And thus PoCallDriver and
    PoStartNextPowerIrp - to maintain the busy/free state of this queue.

    Max
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

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!
Kernel Debugging 13-17 May 2024 Live, Online
Developing Minifilters 1-5 Apr 2024 Live, Online
Internals & Software Drivers 11-15 Mar 2024 Live, Online
Writing WDF Drivers 20-24 May 2024 Live, Online