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

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

IRP_MJ_POWER

Jamey_KirbyJamey_Kirby Member - All Emails Posts: 429
According to the WDK, a driver must not fail an IRP_MJ_POWER/IRP_MN_SET_POWER. My question is this: Does this include failing on acquiring a remlock? For example, if my IoAcquireRemoveLock() fails indicating the device is being removed, should I still pass the IRP down? Here is a generic WDM power dispatcher and completion handler I have thrown together:

static NTSTATUS PowerComplete(_In_ PDEVICE_OBJECT Device, _In_ PIRP Irp,
_Reserved_ PVOID Context) {
if (Irp->PendingReturned) {
IoMarkIrpPending(Irp);
}
register PFILTER_EXTENSION FilterExt = Device->DeviceExtension;
IoReleaseRemoveLock(&FilterExt->RemoveLock, Irp);
// Pre-VISTA power IRP is handled differently.
PIO_STACK_LOCATION CurrSl = IoGetCurrentIrpStackLocation(Irp);
if (CurrSl->Parameters.Power.Type == DevicePowerState) {
if ((CurrSl->MinorFunction == IRP_MN_QUERY_POWER) ||
(CurrSl->MinorFunction == IRP_MN_SET_POWER)) {
// Post XP/2003 this is a NOP.
PoStartNextPowerIrp(Irp);
}
}
return STATUS_SUCCESS;
UNREFERENCED_PARAMETER(Context);
}

static NTSTATUS PowerFilter(_In_ PDEVICE_OBJECT Device, _In_ PIRP Irp) {
PFILTER_EXTENSION FilterExt = Device->DeviceExtension;
PIO_STACK_LOCATION CurrSl = IoGetCurrentIrpStackLocation(Irp);
NTSTATUS Status = IoAcquireRemoveLock(&FilterExt->RemoveLock, Irp);
if (!NT_SUCCESS(Status)) {
Irp->IoStatus.Status = Status;
Irp->IoStatus.Information = 0;
// Pre-VISTA power IRP is handled differently.
if ((CurrSl->Parameters.Power.Type == SystemPowerState) &&
(CurrSl->MinorFunction == IRP_MN_QUERY_POWER)) {
// Post XP/2003 this is a NOP.
PoStartNextPowerIrp(Irp);
}
IoCompleteRequest(Irp, IO_NO_INCREMENT);
return Status;
}
// Pre-VISTA power IRP is handled differently.
if ((CurrSl->Parameters.Power.Type == SystemPowerState) &&
((CurrSl->MinorFunction == IRP_MN_QUERY_POWER) ||
(CurrSl->MinorFunction == IRP_MN_SET_POWER))) {
// Post XP/2003 this is a NOP.
PoStartNextPowerIrp(Irp);
}
IoCopyCurrentIrpStackLocationToNext(Irp);
IoSetCompletionRoutine(Irp, PowerComplete, NULL, TRUE, TRUE, TRUE);
// Post XP/2003 this calls IoCallDriver().
return PoCallDriver(FilterExt->TargetDevice, Irp);
}

Can I get into trouble for not passing down the power IRP. I've not seen any issues, but I was reading the WDK documentation last night on power IRPS, and I began to question my code.

-- Jamey

Comments

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,434
    On failure to acquire the remlock, it is acceptable to fail the power irp.

    -----Original Message-----
    From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
    Sent: Wednesday, April 5, 2017 10:17 AM
    To: Windows System Software Devs Interest List <xxxxx@lists.osr.com>
    Subject: [ntdev] IRP_MJ_POWER

    According to the WDK, a driver must not fail an IRP_MJ_POWER/IRP_MN_SET_POWER. My question is this: Does this include failing on acquiring a remlock? For example, if my IoAcquireRemoveLock() fails indicating the device is being removed, should I still pass the IRP down? Here is a generic WDM power dispatcher and completion handler I have thrown together:

    static NTSTATUS PowerComplete(_In_ PDEVICE_OBJECT Device, _In_ PIRP Irp,
    _Reserved_ PVOID Context) {
    if (Irp->PendingReturned) {
    IoMarkIrpPending(Irp);
    }
    register PFILTER_EXTENSION FilterExt = Device->DeviceExtension;
    IoReleaseRemoveLock(&FilterExt->RemoveLock, Irp);
    // Pre-VISTA power IRP is handled differently.
    PIO_STACK_LOCATION CurrSl = IoGetCurrentIrpStackLocation(Irp);
    if (CurrSl->Parameters.Power.Type == DevicePowerState) {
    if ((CurrSl->MinorFunction == IRP_MN_QUERY_POWER) ||
    (CurrSl->MinorFunction == IRP_MN_SET_POWER)) {
    // Post XP/2003 this is a NOP.
    PoStartNextPowerIrp(Irp);
    }
    }
    return STATUS_SUCCESS;
    UNREFERENCED_PARAMETER(Context);
    }

    static NTSTATUS PowerFilter(_In_ PDEVICE_OBJECT Device, _In_ PIRP Irp) {
    PFILTER_EXTENSION FilterExt = Device->DeviceExtension;
    PIO_STACK_LOCATION CurrSl = IoGetCurrentIrpStackLocation(Irp);
    NTSTATUS Status = IoAcquireRemoveLock(&FilterExt->RemoveLock, Irp);
    if (!NT_SUCCESS(Status)) {
    Irp->IoStatus.Status = Status;
    Irp->IoStatus.Information = 0;
    // Pre-VISTA power IRP is handled differently.
    if ((CurrSl->Parameters.Power.Type == SystemPowerState) &&
    (CurrSl->MinorFunction == IRP_MN_QUERY_POWER)) {
    // Post XP/2003 this is a NOP.
    PoStartNextPowerIrp(Irp);
    }
    IoCompleteRequest(Irp, IO_NO_INCREMENT);
    return Status;
    }
    // Pre-VISTA power IRP is handled differently.
    if ((CurrSl->Parameters.Power.Type == SystemPowerState) &&
    ((CurrSl->MinorFunction == IRP_MN_QUERY_POWER) ||
    (CurrSl->MinorFunction == IRP_MN_SET_POWER))) {
    // Post XP/2003 this is a NOP.
    PoStartNextPowerIrp(Irp);
    }
    IoCopyCurrentIrpStackLocationToNext(Irp);
    IoSetCompletionRoutine(Irp, PowerComplete, NULL, TRUE, TRUE, TRUE);
    // Post XP/2003 this calls IoCallDriver().
    return PoCallDriver(FilterExt->TargetDevice, Irp); }

    Can I get into trouble for not passing down the power IRP. I've not seen any issues, but I was reading the WDK documentation last night on power IRPS, and I began to question my code.

    -- Jamey

    ---
    NTDEV is sponsored by OSR

    Visit the list online at: <https://na01.safelinks.protection.outlook.com/?url=http://www.osronline.com/showlists.cfm?list=ntdev&amp;data=02|01|[email protected]|3651cbec5fec43307fee08d47c479497|72f988bf86f141af91ab2d7cd011db47|1|0|636270094259345179&amp;sdata=bZnTeM+IvtjOJfKFM9Wwn9WwjYxwp18vDwGeoDwLlVs=&amp;reserved=0&gt;

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at <https://na01.safelinks.protection.outlook.com/?url=http://www.osr.com/seminars&amp;data=02|01|[email protected]|3651cbec5fec43307fee08d47c479497|72f988bf86f141af91ab2d7cd011db47|1|0|636270094259345179&amp;sdata=s247NeZ8+TfymwLCXmxs0T1M3ln47NyS2zK5FG3OyYA=&amp;reserved=0&gt;

    To unsubscribe, visit the List Server section of OSR Online at <https://na01.safelinks.protection.outlook.com/?url=http://www.osronline.com/page.cfm?name=ListServer&amp;data=02|01|[email protected]|3651cbec5fec43307fee08d47c479497|72f988bf86f141af91ab2d7cd011db47|1|0|636270094259345179&amp;sdata=YFbwfEY7WV3LawYikbkB/yEL8QREcBoZ2Ev1lZPY5vc=&amp;reserved=0&gt;
    d
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    PowerFilter sets the IoStatus.Status to a failed status and returns that
    status but you can't fail this IRP if the systen power state is being set.

    "A driver must not fail a request to set the system power state."

    Read this page:

    https://msdn.microsoft.com/fr-fr/library/windows/hardware/ff551744(v=vs.85).aspx

    Remember that the remove lock is owned by your driver. If you can't acquire
    it than the game is over because your driver is processing an
    IRP_MN_REMOVE_DEVICE IRP. This later IRP cannot be failed and the driver is
    supposed to power down the device when the IRP is processed.

    So, if you can't acquire the remove lock, the device is being powered off.
    If the power IRP is sent at PASSIVE_LEVEL, you could wait for the
    IRP_MN_REMOVE_DEVICE to set an event when the device is powered off. This
    IRQL depends on what device object's flag the driver has set
    (DO_POWER_PAGABLE for PASSIVE_LEVEL or DO_POWER_INRUSH for DISPATCH_LEVEL).
    Le 5 avr. 2017 19:17, a écrit :

    > According to the WDK, a driver must not fail an
    > IRP_MJ_POWER/IRP_MN_SET_POWER. My question is this: Does this include
    > failing on acquiring a remlock? For example, if my IoAcquireRemoveLock()
    > fails indicating the device is being removed, should I still pass the IRP
    > down? Here is a generic WDM power dispatcher and completion handler I have
    > thrown together:
    >
    > static NTSTATUS PowerComplete(_In_ PDEVICE_OBJECT Device, _In_ PIRP Irp,
    > _Reserved_ PVOID Context) {
    > if (Irp->PendingReturned) {
    > IoMarkIrpPending(Irp);
    > }
    > register PFILTER_EXTENSION FilterExt = Device->DeviceExtension;
    > IoReleaseRemoveLock(&FilterExt->RemoveLock, Irp);
    > // Pre-VISTA power IRP is handled differently.
    > PIO_STACK_LOCATION CurrSl = IoGetCurrentIrpStackLocation(Irp);
    > if (CurrSl->Parameters.Power.Type == DevicePowerState) {
    > if ((CurrSl->MinorFunction == IRP_MN_QUERY_POWER) ||
    > (CurrSl->MinorFunction == IRP_MN_SET_POWER)) {
    > // Post XP/2003 this is a NOP.
    > PoStartNextPowerIrp(Irp);
    > }
    > }
    > return STATUS_SUCCESS;
    > UNREFERENCED_PARAMETER(Context);
    > }
    >
    > static NTSTATUS PowerFilter(_In_ PDEVICE_OBJECT Device, _In_ PIRP Irp) {
    > PFILTER_EXTENSION FilterExt = Device->DeviceExtension;
    > PIO_STACK_LOCATION CurrSl = IoGetCurrentIrpStackLocation(Irp);
    > NTSTATUS Status = IoAcquireRemoveLock(&FilterExt->RemoveLock,
    > Irp);
    > if (!NT_SUCCESS(Status)) {
    > Irp->IoStatus.Status = Status;
    > Irp->IoStatus.Information = 0;
    > // Pre-VISTA power IRP is handled differently.
    > if ((CurrSl->Parameters.Power.Type == SystemPowerState) &&
    > (CurrSl->MinorFunction == IRP_MN_QUERY_POWER)) {
    > // Post XP/2003 this is a NOP.
    > PoStartNextPowerIrp(Irp);
    > }
    > IoCompleteRequest(Irp, IO_NO_INCREMENT);
    > return Status;
    > }
    > // Pre-VISTA power IRP is handled differently.
    > if ((CurrSl->Parameters.Power.Type == SystemPowerState) &&
    > ((CurrSl->MinorFunction == IRP_MN_QUERY_POWER) ||
    > (CurrSl->MinorFunction == IRP_MN_SET_POWER))) {
    > // Post XP/2003 this is a NOP.
    > PoStartNextPowerIrp(Irp);
    > }
    > IoCopyCurrentIrpStackLocationToNext(Irp);
    > IoSetCompletionRoutine(Irp, PowerComplete, NULL, TRUE, TRUE, TRUE);
    > // Post XP/2003 this calls IoCallDriver().
    > return PoCallDriver(FilterExt->TargetDevice, Irp);
    > }
    >
    > Can I get into trouble for not passing down the power IRP. I've not seen
    > any issues, but I was reading the WDK documentation last night on power
    > IRPS, and I began to question my code.
    >
    > -- Jamey
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: showlists.cfm?list=ntdev>
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,434
    It won't be a set system set power irp as that is coordinated with the pnp state lock. It would be a query, set device power or wait wake request. All of which can fail

    Bent from my phone
    ________________________________
    From: xxxxx@lists.osr.com on behalf of Device Engineering Company
    Sent: Wednesday, April 5, 2017 11:58:37 AM
    To: Windows System Software Devs Interest List
    Subject: Re: [ntdev] IRP_MJ_POWER


    PowerFilter sets the IoStatus.Status to a failed status and returns that status but you can't fail this IRP if the systen power state is being set.

    "A driver must not fail a request to set the system power state."

    Read this page:

    https://msdn.microsoft.com/fr-fr/library/windows/hardware/ff551744(v=vs.85).aspx

    Remember that the remove lock is owned by your driver. If you can't acquire it than the game is over because your driver is processing an IRP_MN_REMOVE_DEVICE IRP. This later IRP cannot be failed and the driver is supposed to power down the device when the IRP is processed.

    So, if you can't acquire the remove lock, the device is being powered off. If the power IRP is sent at PASSIVE_LEVEL, you could wait for the IRP_MN_REMOVE_DEVICE to set an event when the device is powered off. This IRQL depends on what device object's flag the driver has set (DO_POWER_PAGABLE for PASSIVE_LEVEL or DO_POWER_INRUSH for DISPATCH_LEVEL).

    Le 5 avr. 2017 19:17, > a ?crit :
    According to the WDK, a driver must not fail an IRP_MJ_POWER/IRP_MN_SET_POWER. My question is this: Does this include failing on acquiring a remlock? For example, if my IoAcquireRemoveLock() fails indicating the device is being removed, should I still pass the IRP down? Here is a generic WDM power dispatcher and completion handler I have thrown together:

    static NTSTATUS PowerComplete(_In_ PDEVICE_OBJECT Device, _In_ PIRP Irp,
    _Reserved_ PVOID Context) {
    if (Irp->PendingReturned) {
    IoMarkIrpPending(Irp);
    }
    register PFILTER_EXTENSION FilterExt = Device->DeviceExtension;
    IoReleaseRemoveLock(&FilterExt->RemoveLock, Irp);
    // Pre-VISTA power IRP is handled differently.
    PIO_STACK_LOCATION CurrSl = IoGetCurrentIrpStackLocation(Irp);
    if (CurrSl->Parameters.Power.Type == DevicePowerState) {
    if ((CurrSl->MinorFunction == IRP_MN_QUERY_POWER) ||
    (CurrSl->MinorFunction == IRP_MN_SET_POWER)) {
    // Post XP/2003 this is a NOP.
    PoStartNextPowerIrp(Irp);
    }
    }
    return STATUS_SUCCESS;
    UNREFERENCED_PARAMETER(Context);
    }

    static NTSTATUS PowerFilter(_In_ PDEVICE_OBJECT Device, _In_ PIRP Irp) {
    PFILTER_EXTENSION FilterExt = Device->DeviceExtension;
    PIO_STACK_LOCATION CurrSl = IoGetCurrentIrpStackLocation(Irp);
    NTSTATUS Status = IoAcquireRemoveLock(&FilterExt->RemoveLock, Irp);
    if (!NT_SUCCESS(Status)) {
    Irp->IoStatus.Status = Status;
    Irp->IoStatus.Information = 0;
    // Pre-VISTA power IRP is handled differently.
    if ((CurrSl->Parameters.Power.Type == SystemPowerState) &&
    (CurrSl->MinorFunction == IRP_MN_QUERY_POWER)) {
    // Post XP/2003 this is a NOP.
    PoStartNextPowerIrp(Irp);
    }
    IoCompleteRequest(Irp, IO_NO_INCREMENT);
    return Status;
    }
    // Pre-VISTA power IRP is handled differently.
    if ((CurrSl->Parameters.Power.Type == SystemPowerState) &&
    ((CurrSl->MinorFunction == IRP_MN_QUERY_POWER) ||
    (CurrSl->MinorFunction == IRP_MN_SET_POWER))) {
    // Post XP/2003 this is a NOP.
    PoStartNextPowerIrp(Irp);
    }
    IoCopyCurrentIrpStackLocationToNext(Irp);
    IoSetCompletionRoutine(Irp, PowerComplete, NULL, TRUE, TRUE, TRUE);
    // Post XP/2003 this calls IoCallDriver().
    return PoCallDriver(FilterExt->TargetDevice, Irp);
    }

    Can I get into trouble for not passing down the power IRP. I've not seen any issues, but I was reading the WDK documentation last night on power IRPS, and I began to question my code.

    -- Jamey

    ---
    NTDEV is sponsored by OSR

    Visit the list online at: >

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at >

    To unsubscribe, visit the List Server section of OSR Online at >
    --- NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at
    d
  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 429
    I've read that page several times over, and thus I asked my question. I try
    to read before posting. It was just unclear how to handle this rare
    situation of not being able to grab the lock. I've never really encountered
    this issue, but I wanted to make sure my code would handle it properly if
    it is encountered.

    So, if I wait for the remove to complete, then what? By the time the remove
    has completed, my remlock is gone (the DE has been deleted), and there is
    no target to pass the request along to. Do I just complete the IRP with
    STATUS_SUCCESS, and don't try to acquire the lock again?

    Thanks for the feedback, it is helpful.

    -- Jamey




    On Wed, Apr 5, 2017 at 3:00 PM Device Engineering Company <
    xxxxx@gmail.com> wrote:

    > PowerFilter sets the IoStatus.Status to a failed status and returns that
    > status but you can't fail this IRP if the systen power state is being set.
    >
    > "A driver must not fail a request to set the system power state."
    >
    > Read this page:
    >
    >
    > https://msdn.microsoft.com/fr-fr/library/windows/hardware/ff551744(v=vs.85).aspx
    >
    > Remember that the remove lock is owned by your driver. If you can't
    > acquire it than the game is over because your driver is processing an
    > IRP_MN_REMOVE_DEVICE IRP. This later IRP cannot be failed and the driver is
    > supposed to power down the device when the IRP is processed.
    >
    > So, if you can't acquire the remove lock, the device is being powered off.
    > If the power IRP is sent at PASSIVE_LEVEL, you could wait for the
    > IRP_MN_REMOVE_DEVICE to set an event when the device is powered off. This
    > IRQL depends on what device object's flag the driver has set
    > (DO_POWER_PAGABLE for PASSIVE_LEVEL or DO_POWER_INRUSH for DISPATCH_LEVEL).
    > Le 5 avr. 2017 19:17, a écrit :
    >
    > According to the WDK, a driver must not fail an
    > IRP_MJ_POWER/IRP_MN_SET_POWER. My question is this: Does this include
    > failing on acquiring a remlock? For example, if my IoAcquireRemoveLock()
    > fails indicating the device is being removed, should I still pass the IRP
    > down? Here is a generic WDM power dispatcher and completion handler I have
    > thrown together:
    >
    > static NTSTATUS PowerComplete(_In_ PDEVICE_OBJECT Device, _In_ PIRP Irp,
    > _Reserved_ PVOID Context) {
    > if (Irp->PendingReturned) {
    > IoMarkIrpPending(Irp);
    > }
    > register PFILTER_EXTENSION FilterExt = Device->DeviceExtension;
    > IoReleaseRemoveLock(&FilterExt->RemoveLock, Irp);
    > // Pre-VISTA power IRP is handled differently.
    > PIO_STACK_LOCATION CurrSl = IoGetCurrentIrpStackLocation(Irp);
    > if (CurrSl->Parameters.Power.Type == DevicePowerState) {
    > if ((CurrSl->MinorFunction == IRP_MN_QUERY_POWER) ||
    > (CurrSl->MinorFunction == IRP_MN_SET_POWER)) {
    > // Post XP/2003 this is a NOP.
    > PoStartNextPowerIrp(Irp);
    > }
    > }
    > return STATUS_SUCCESS;
    > UNREFERENCED_PARAMETER(Context);
    > }
    >
    > static NTSTATUS PowerFilter(_In_ PDEVICE_OBJECT Device, _In_ PIRP Irp) {
    > PFILTER_EXTENSION FilterExt = Device->DeviceExtension;
    > PIO_STACK_LOCATION CurrSl = IoGetCurrentIrpStackLocation(Irp);
    > NTSTATUS Status = IoAcquireRemoveLock(&FilterExt->RemoveLock, Irp);
    > if (!NT_SUCCESS(Status)) {
    > Irp->IoStatus.Status = Status;
    > Irp->IoStatus.Information = 0;
    > // Pre-VISTA power IRP is handled differently.
    > if ((CurrSl->Parameters.Power.Type == SystemPowerState) &&
    > (CurrSl->MinorFunction == IRP_MN_QUERY_POWER)) {
    > // Post XP/2003 this is a NOP.
    > PoStartNextPowerIrp(Irp);
    > }
    > IoCompleteRequest(Irp, IO_NO_INCREMENT);
    > return Status;
    > }
    > // Pre-VISTA power IRP is handled differently.
    > if ((CurrSl->Parameters.Power.Type == SystemPowerState) &&
    > ((CurrSl->MinorFunction == IRP_MN_QUERY_POWER) ||
    > (CurrSl->MinorFunction == IRP_MN_SET_POWER))) {
    > // Post XP/2003 this is a NOP.
    > PoStartNextPowerIrp(Irp);
    > }
    > IoCopyCurrentIrpStackLocationToNext(Irp);
    > IoSetCompletionRoutine(Irp, PowerComplete, NULL, TRUE, TRUE, TRUE);
    > // Post XP/2003 this calls IoCallDriver().
    > return PoCallDriver(FilterExt->TargetDevice, Irp);
    > }
    >
    > Can I get into trouble for not passing down the power IRP. I've not seen
    > any issues, but I was reading the WDK documentation last night on power
    > IRPS, and I began to question my code.
    >
    > -- Jamey
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: <
    > http://www.osronline.com/showlists.cfm?list=ntdev>;
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
    > --- NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
    > on crash dump analysis, WDF, Windows internals and software drivers!
    > Details at To unsubscribe, visit the List Server section of OSR Online at
  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 429
    Do I even have to wait for the remove to complete? Can I just complete the
    IRP with STATUS_SUCCESS and keep on truckin'


    On Wed, Apr 5, 2017 at 3:56 PM Jamey Kirby wrote:

    > I've read that page several times over, and thus I asked my question. I
    > try to read before posting. It was just unclear how to handle this rare
    > situation of not being able to grab the lock. I've never really encountered
    > this issue, but I wanted to make sure my code would handle it properly if
    > it is encountered.
    >
    > So, if I wait for the remove to complete, then what? By the time the
    > remove has completed, my remlock is gone (the DE has been deleted), and
    > there is no target to pass the request along to. Do I just complete the IRP
    > with STATUS_SUCCESS, and don't try to acquire the lock again?
    >
    > Thanks for the feedback, it is helpful.
    >
    > -- Jamey
    >
    >
    >
    >
    > On Wed, Apr 5, 2017 at 3:00 PM Device Engineering Company <
    > xxxxx@gmail.com> wrote:
    >
    > PowerFilter sets the IoStatus.Status to a failed status and returns that
    > status but you can't fail this IRP if the systen power state is being set.
    >
    > "A driver must not fail a request to set the system power state."
    >
    > Read this page:
    >
    >
    > https://msdn.microsoft.com/fr-fr/library/windows/hardware/ff551744(v=vs.85).aspx
    >
    > Remember that the remove lock is owned by your driver. If you can't
    > acquire it than the game is over because your driver is processing an
    > IRP_MN_REMOVE_DEVICE IRP. This later IRP cannot be failed and the driver is
    > supposed to power down the device when the IRP is processed.
    >
    > So, if you can't acquire the remove lock, the device is being powered off.
    > If the power IRP is sent at PASSIVE_LEVEL, you could wait for the
    > IRP_MN_REMOVE_DEVICE to set an event when the device is powered off. This
    > IRQL depends on what device object's flag the driver has set
    > (DO_POWER_PAGABLE for PASSIVE_LEVEL or DO_POWER_INRUSH for DISPATCH_LEVEL).
    > Le 5 avr. 2017 19:17, a écrit :
    >
    > According to the WDK, a driver must not fail an
    > IRP_MJ_POWER/IRP_MN_SET_POWER. My question is this: Does this include
    > failing on acquiring a remlock? For example, if my IoAcquireRemoveLock()
    > fails indicating the device is being removed, should I still pass the IRP
    > down? Here is a generic WDM power dispatcher and completion handler I have
    > thrown together:
    >
    > static NTSTATUS PowerComplete(_In_ PDEVICE_OBJECT Device, _In_ PIRP Irp,
    > _Reserved_ PVOID Context) {
    > if (Irp->PendingReturned) {
    > IoMarkIrpPending(Irp);
    > }
    > register PFILTER_EXTENSION FilterExt = Device->DeviceExtension;
    > IoReleaseRemoveLock(&FilterExt->RemoveLock, Irp);
    > // Pre-VISTA power IRP is handled differently.
    > PIO_STACK_LOCATION CurrSl = IoGetCurrentIrpStackLocation(Irp);
    > if (CurrSl->Parameters.Power.Type == DevicePowerState) {
    > if ((CurrSl->MinorFunction == IRP_MN_QUERY_POWER) ||
    > (CurrSl->MinorFunction == IRP_MN_SET_POWER)) {
    > // Post XP/2003 this is a NOP.
    > PoStartNextPowerIrp(Irp);
    > }
    > }
    > return STATUS_SUCCESS;
    > UNREFERENCED_PARAMETER(Context);
    > }
    >
    > static NTSTATUS PowerFilter(_In_ PDEVICE_OBJECT Device, _In_ PIRP Irp) {
    > PFILTER_EXTENSION FilterExt = Device->DeviceExtension;
    > PIO_STACK_LOCATION CurrSl = IoGetCurrentIrpStackLocation(Irp);
    > NTSTATUS Status = IoAcquireRemoveLock(&FilterExt->RemoveLock, Irp);
    > if (!NT_SUCCESS(Status)) {
    > Irp->IoStatus.Status = Status;
    > Irp->IoStatus.Information = 0;
    > // Pre-VISTA power IRP is handled differently.
    > if ((CurrSl->Parameters.Power.Type == SystemPowerState) &&
    > (CurrSl->MinorFunction == IRP_MN_QUERY_POWER)) {
    > // Post XP/2003 this is a NOP.
    > PoStartNextPowerIrp(Irp);
    > }
    > IoCompleteRequest(Irp, IO_NO_INCREMENT);
    > return Status;
    > }
    > // Pre-VISTA power IRP is handled differently.
    > if ((CurrSl->Parameters.Power.Type == SystemPowerState) &&
    > ((CurrSl->MinorFunction == IRP_MN_QUERY_POWER) ||
    > (CurrSl->MinorFunction == IRP_MN_SET_POWER))) {
    > // Post XP/2003 this is a NOP.
    > PoStartNextPowerIrp(Irp);
    > }
    > IoCopyCurrentIrpStackLocationToNext(Irp);
    > IoSetCompletionRoutine(Irp, PowerComplete, NULL, TRUE, TRUE, TRUE);
    > // Post XP/2003 this calls IoCallDriver().
    > return PoCallDriver(FilterExt->TargetDevice, Irp);
    > }
    >
    > Can I get into trouble for not passing down the power IRP. I've not seen
    > any issues, but I was reading the WDK documentation last night on power
    > IRPS, and I began to question my code.
    >
    > -- Jamey
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: <
    > http://www.osronline.com/showlists.cfm?list=ntdev>;
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
    > --- NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
    > on crash dump analysis, WDF, Windows internals and software drivers!
    > Details at To unsubscribe, visit the List Server section of OSR Online at
    >
    >
  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 429
    I've updated PowerFilter like this:

    static NTSTATUS PowerFilter(_In_ PDEVICE_OBJECT Device, _In_ PIRP Irp) {
    PFILTER_EXTENSION FilterExt = Device->DeviceExtension;
    PIO_STACK_LOCATION CurrSl = IoGetCurrentIrpStackLocation(Irp);
    NTSTATUS Status = IoAcquireRemoveLock(&FilterExt->RemoveLock, Irp);
    if (!NT_SUCCESS(Status)) {
    Irp->IoStatus.Status = Status;
    Irp->IoStatus.Information = 0;
    // Pre-VISTA power IRP is handled differently.
    if (CurrSl->Parameters.Power.Type == SystemPowerState) {
    if (CurrSl->MinorFunction == IRP_MN_QUERY_POWER) {
    // Post XP/2003 this is a NOP.
    PoStartNextPowerIrp(Irp);
    }
    else if (CurrSl->MinorFunction == IRP_MN_SET_POWER) {
    // Can't fail a IRP_MN_SET_POWER for the system state.
    Irp->IoStatus.Status = STATUS_SUCCESS;
    Irp->IoStatus.Information = 0;
    }
    }
    IoCompleteRequest(Irp, IO_NO_INCREMENT);
    return Status;
    }
    // Pre-VISTA power IRP is handled differently.
    if ((CurrSl->Parameters.Power.Type == SystemPowerState) &&
    ((CurrSl->MinorFunction == IRP_MN_QUERY_POWER) ||
    (CurrSl->MinorFunction == IRP_MN_SET_POWER))) {
    // Post XP/2003 this is a NOP.
    PoStartNextPowerIrp(Irp);
    }
    IoCopyCurrentIrpStackLocationToNext(Irp);
    IoSetCompletionRoutine(Irp, PowerComplete, NULL, TRUE, TRUE, TRUE);
    // Post XP/2003 this calls IoCallDriver().
    return PoCallDriver(FilterExt->TargetDevice, Irp);
    }


    On Wed, Apr 5, 2017 at 4:04 PM Jamey Kirby wrote:

    > Do I even have to wait for the remove to complete? Can I just complete the
    > IRP with STATUS_SUCCESS and keep on truckin'
    >
    >
    > On Wed, Apr 5, 2017 at 3:56 PM Jamey Kirby wrote:
    >
    > I've read that page several times over, and thus I asked my question. I
    > try to read before posting. It was just unclear how to handle this rare
    > situation of not being able to grab the lock. I've never really encountered
    > this issue, but I wanted to make sure my code would handle it properly if
    > it is encountered.
    >
    > So, if I wait for the remove to complete, then what? By the time the
    > remove has completed, my remlock is gone (the DE has been deleted), and
    > there is no target to pass the request along to. Do I just complete the IRP
    > with STATUS_SUCCESS, and don't try to acquire the lock again?
    >
    > Thanks for the feedback, it is helpful.
    >
    > -- Jamey
    >
    >
    >
    >
    > On Wed, Apr 5, 2017 at 3:00 PM Device Engineering Company <
    > xxxxx@gmail.com> wrote:
    >
    > PowerFilter sets the IoStatus.Status to a failed status and returns that
    > status but you can't fail this IRP if the systen power state is being set.
    >
    > "A driver must not fail a request to set the system power state."
    >
    > Read this page:
    >
    >
    > https://msdn.microsoft.com/fr-fr/library/windows/hardware/ff551744(v=vs.85).aspx
    >
    > Remember that the remove lock is owned by your driver. If you can't
    > acquire it than the game is over because your driver is processing an
    > IRP_MN_REMOVE_DEVICE IRP. This later IRP cannot be failed and the driver is
    > supposed to power down the device when the IRP is processed.
    >
    > So, if you can't acquire the remove lock, the device is being powered off.
    > If the power IRP is sent at PASSIVE_LEVEL, you could wait for the
    > IRP_MN_REMOVE_DEVICE to set an event when the device is powered off. This
    > IRQL depends on what device object's flag the driver has set
    > (DO_POWER_PAGABLE for PASSIVE_LEVEL or DO_POWER_INRUSH for DISPATCH_LEVEL).
    > Le 5 avr. 2017 19:17, a écrit :
    >
    > According to the WDK, a driver must not fail an
    > IRP_MJ_POWER/IRP_MN_SET_POWER. My question is this: Does this include
    > failing on acquiring a remlock? For example, if my IoAcquireRemoveLock()
    > fails indicating the device is being removed, should I still pass the IRP
    > down? Here is a generic WDM power dispatcher and completion handler I have
    > thrown together:
    >
    > static NTSTATUS PowerComplete(_In_ PDEVICE_OBJECT Device, _In_ PIRP Irp,
    > _Reserved_ PVOID Context) {
    > if (Irp->PendingReturned) {
    > IoMarkIrpPending(Irp);
    > }
    > register PFILTER_EXTENSION FilterExt = Device->DeviceExtension;
    > IoReleaseRemoveLock(&FilterExt->RemoveLock, Irp);
    > // Pre-VISTA power IRP is handled differently.
    > PIO_STACK_LOCATION CurrSl = IoGetCurrentIrpStackLocation(Irp);
    > if (CurrSl->Parameters.Power.Type == DevicePowerState) {
    > if ((CurrSl->MinorFunction == IRP_MN_QUERY_POWER) ||
    > (CurrSl->MinorFunction == IRP_MN_SET_POWER)) {
    > // Post XP/2003 this is a NOP.
    > PoStartNextPowerIrp(Irp);
    > }
    > }
    > return STATUS_SUCCESS;
    > UNREFERENCED_PARAMETER(Context);
    > }
    >
    > static NTSTATUS PowerFilter(_In_ PDEVICE_OBJECT Device, _In_ PIRP Irp) {
    > PFILTER_EXTENSION FilterExt = Device->DeviceExtension;
    > PIO_STACK_LOCATION CurrSl = IoGetCurrentIrpStackLocation(Irp);
    > NTSTATUS Status = IoAcquireRemoveLock(&FilterExt->RemoveLock, Irp);
    > if (!NT_SUCCESS(Status)) {
    > Irp->IoStatus.Status = Status;
    > Irp->IoStatus.Information = 0;
    > // Pre-VISTA power IRP is handled differently.
    > if ((CurrSl->Parameters.Power.Type == SystemPowerState) &&
    > (CurrSl->MinorFunction == IRP_MN_QUERY_POWER)) {
    > // Post XP/2003 this is a NOP.
    > PoStartNextPowerIrp(Irp);
    > }
    > IoCompleteRequest(Irp, IO_NO_INCREMENT);
    > return Status;
    > }
    > // Pre-VISTA power IRP is handled differently.
    > if ((CurrSl->Parameters.Power.Type == SystemPowerState) &&
    > ((CurrSl->MinorFunction == IRP_MN_QUERY_POWER) ||
    > (CurrSl->MinorFunction == IRP_MN_SET_POWER))) {
    > // Post XP/2003 this is a NOP.
    > PoStartNextPowerIrp(Irp);
    > }
    > IoCopyCurrentIrpStackLocationToNext(Irp);
    > IoSetCompletionRoutine(Irp, PowerComplete, NULL, TRUE, TRUE, TRUE);
    > // Post XP/2003 this calls IoCallDriver().
    > return PoCallDriver(FilterExt->TargetDevice, Irp);
    > }
    >
    > Can I get into trouble for not passing down the power IRP. I've not seen
    > any issues, but I was reading the WDK documentation last night on power
    > IRPS, and I began to question my code.
    >
    > -- Jamey
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: <
    > http://www.osronline.com/showlists.cfm?list=ntdev>;
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
    > --- NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
    > on crash dump analysis, WDF, Windows internals and software drivers!
    > Details at To unsubscribe, visit the List Server section of OSR Online at
    >
    >
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,434
    See my response. The solution is being over engineered. Just fail the power irp if the remlock acquire fails.

    d

    From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jamey Kirby
    Sent: Wednesday, April 5, 2017 1:05 PM
    To: Windows System Software Devs Interest List
    Subject: Re: [ntdev] IRP_MJ_POWER

    Do I even have to wait for the remove to complete? Can I just complete the IRP with STATUS_SUCCESS and keep on truckin'


    On Wed, Apr 5, 2017 at 3:56 PM Jamey Kirby > wrote:
    I've read that page several times over, and thus I asked my question. I try to read before posting. It was just unclear how to handle this rare situation of not being able to grab the lock. I've never really encountered this issue, but I wanted to make sure my code would handle it properly if it is encountered.

    So, if I wait for the remove to complete, then what? By the time the remove has completed, my remlock is gone (the DE has been deleted), and there is no target to pass the request along to. Do I just complete the IRP with STATUS_SUCCESS, and don't try to acquire the lock again?

    Thanks for the feedback, it is helpful.

    -- Jamey




    On Wed, Apr 5, 2017 at 3:00 PM Device Engineering Company > wrote:

    PowerFilter sets the IoStatus.Status to a failed status and returns that status but you can't fail this IRP if the systen power state is being set.

    "A driver must not fail a request to set the system power state."

    Read this page:

    https://msdn.microsoft.com/fr-fr/library/windows/hardware/ff551744(v=vs.85).aspx

    Remember that the remove lock is owned by your driver. If you can't acquire it than the game is over because your driver is processing an IRP_MN_REMOVE_DEVICE IRP. This later IRP cannot be failed and the driver is supposed to power down the device when the IRP is processed.

    So, if you can't acquire the remove lock, the device is being powered off. If the power IRP is sent at PASSIVE_LEVEL, you could wait for the IRP_MN_REMOVE_DEVICE to set an event when the device is powered off. This IRQL depends on what device object's flag the driver has set (DO_POWER_PAGABLE for PASSIVE_LEVEL or DO_POWER_INRUSH for DISPATCH_LEVEL).
    Le 5 avr. 2017 19:17, > a écrit :
    According to the WDK, a driver must not fail an IRP_MJ_POWER/IRP_MN_SET_POWER. My question is this: Does this include failing on acquiring a remlock? For example, if my IoAcquireRemoveLock() fails indicating the device is being removed, should I still pass the IRP down? Here is a generic WDM power dispatcher and completion handler I have thrown together:

    static NTSTATUS PowerComplete(_In_ PDEVICE_OBJECT Device, _In_ PIRP Irp,
    _Reserved_ PVOID Context) {
    if (Irp->PendingReturned) {
    IoMarkIrpPending(Irp);
    }
    register PFILTER_EXTENSION FilterExt = Device->DeviceExtension;
    IoReleaseRemoveLock(&FilterExt->RemoveLock, Irp);
    // Pre-VISTA power IRP is handled differently.
    PIO_STACK_LOCATION CurrSl = IoGetCurrentIrpStackLocation(Irp);
    if (CurrSl->Parameters.Power.Type == DevicePowerState) {
    if ((CurrSl->MinorFunction == IRP_MN_QUERY_POWER) ||
    (CurrSl->MinorFunction == IRP_MN_SET_POWER)) {
    // Post XP/2003 this is a NOP.
    PoStartNextPowerIrp(Irp);
    }
    }
    return STATUS_SUCCESS;
    UNREFERENCED_PARAMETER(Context);
    }

    static NTSTATUS PowerFilter(_In_ PDEVICE_OBJECT Device, _In_ PIRP Irp) {
    PFILTER_EXTENSION FilterExt = Device->DeviceExtension;
    PIO_STACK_LOCATION CurrSl = IoGetCurrentIrpStackLocation(Irp);
    NTSTATUS Status = IoAcquireRemoveLock(&FilterExt->RemoveLock, Irp);
    if (!NT_SUCCESS(Status)) {
    Irp->IoStatus.Status = Status;
    Irp->IoStatus.Information = 0;
    // Pre-VISTA power IRP is handled differently.
    if ((CurrSl->Parameters.Power.Type == SystemPowerState) &&
    (CurrSl->MinorFunction == IRP_MN_QUERY_POWER)) {
    // Post XP/2003 this is a NOP.
    PoStartNextPowerIrp(Irp);
    }
    IoCompleteRequest(Irp, IO_NO_INCREMENT);
    return Status;
    }
    // Pre-VISTA power IRP is handled differently.
    if ((CurrSl->Parameters.Power.Type == SystemPowerState) &&
    ((CurrSl->MinorFunction == IRP_MN_QUERY_POWER) ||
    (CurrSl->MinorFunction == IRP_MN_SET_POWER))) {
    // Post XP/2003 this is a NOP.
    PoStartNextPowerIrp(Irp);
    }
    IoCopyCurrentIrpStackLocationToNext(Irp);
    IoSetCompletionRoutine(Irp, PowerComplete, NULL, TRUE, TRUE, TRUE);
    // Post XP/2003 this calls IoCallDriver().
    return PoCallDriver(FilterExt->TargetDevice, Irp);
    }

    Can I get into trouble for not passing down the power IRP. I've not seen any issues, but I was reading the WDK documentation last night on power IRPS, and I began to question my code.

    -- Jamey

    ---
    NTDEV is sponsored by OSR

    Visit the list online at: >

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at >

    To unsubscribe, visit the List Server section of OSR Online at >
    --- NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at
    --- NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at
    d
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > So, if I wait for the remove to complete, then what? By the time the
    remove has completed, my remlock is gone (the DE has been deleted), and
    there is no target to pass the request along to. Do I just complete the IRP
    with STATUS_SUCCESS, and don't try to acquire the lock again?

    > Do I even have to wait for the remove to complete? Can I just complete
    the IRP with STATUS_SUCCESS and keep on truckin'

    The device object is the one that is passed to your IRP_MJ_POWER handler so
    the device extension is valid until the handler returns. The
    IRP_MN_REMOVE_DEVICE could set va flag in the device extrension to inform
    that the device is powered off.

    Now you know at what IRQL these handlers run so you know if you can block
    or not.
  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 429
    Facepalm :)

    On Wed, Apr 5, 2017 at 4:16 PM Device Engineering Company <
    xxxxx@gmail.com> wrote:

    > > So, if I wait for the remove to complete, then what? By the time the
    > remove has completed, my remlock is gone (the DE has been deleted), and
    > there is no target to pass the request along to. Do I just complete the IRP
    > with STATUS_SUCCESS, and don't try to acquire the lock again?
    >
    > > Do I even have to wait for the remove to complete? Can I just complete
    > the IRP with STATUS_SUCCESS and keep on truckin'
    >
    > The device object is the one that is passed to your IRP_MJ_POWER handler
    > so the device extension is valid until the handler returns. The
    > IRP_MN_REMOVE_DEVICE could set va flag in the device extrension to inform
    > that the device is powered off.
    >
    > Now you know at what IRQL these handlers run so you know if you can block
    > or not.
    > --- NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
    > on crash dump analysis, WDF, Windows internals and software drivers!
    > Details at To unsubscribe, visit the List Server section of OSR Online at
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    I 'm assuming the I/O Manager is taking a reference on a device object
    before invoking a dispatch handler. Is that correct ?
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Do as Doron told you. He is right, the remove lock acquisition fails so you must not access the device extension.
  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 429
    Not sure what is going on here, but I did not get Doron's post in email. I
    checked online and saw it.

    Thanks Doron, it was my instinct that it was Ok to fail it.

    -- Jamey


    On Wed, Apr 5, 2017 at 4:56 PM wrote:

    > Do as Doron told you. He is right, the remove lock acquisition fails so
    > you must not access the device extension.
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: <
    > http://www.osronline.com/showlists.cfm?list=ntdev>;
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Yes me too. I thought this thread got to fast for me.

    But this is an interesting race condition.

    Your driver is actually behaving just like a removal device has been removed. This is explained in the DispatchPower MSDN page.

    https://msdn.microsoft.com/en-us/library/windows/hardware/ff543358(v=vs.85).aspx

    Sent from my Windows 10 phone
  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 429
    Doron, should I call PoStartNextPowerIrp() in the event of a failed remlock on the power IRP for IRP_MN_QUERY, or shoudl I just fail all power IRPs under this condition?

    NTSTATUS Status = IoAcquireRemoveLock(&FilterExt->RemoveLock, Irp);
    if (!NT_SUCCESS(Status)) {
    Irp->IoStatus.Status = Status;
    Irp->IoStatus.Information = 0;
    if ((CurrSl->Parameters.Power.Type == SystemPowerState) &&
    (CurrSl->MinorFunction == IRP_MN_QUERY_POWER)) {
    PoStartNextPowerIrp(Irp);
    }
    IoCompleteRequest(Irp, IO_NO_INCREMENT);
    return Status;
    }
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,434
    Technically yes. Pragmatically the API is a no-op since vista, perhaps xp

    Bent from my phone
    ________________________________
    From: xxxxx@lists.osr.com on behalf of xxxxx@gmail.com
    Sent: Wednesday, April 5, 2017 3:31:26 PM
    To: Windows System Software Devs Interest List
    Subject: RE:[ntdev] IRP_MJ_POWER

    Doron, should I call PoStartNextPowerIrp() in the event of a failed remlock on the power IRP for IRP_MN_QUERY, or shoudl I just fail all power IRPs under this condition?

    NTSTATUS Status = IoAcquireRemoveLock(&FilterExt->RemoveLock, Irp);
    if (!NT_SUCCESS(Status)) {
    Irp->IoStatus.Status = Status;
    Irp->IoStatus.Information = 0;
    if ((CurrSl->Parameters.Power.Type == SystemPowerState) &&
    (CurrSl->MinorFunction == IRP_MN_QUERY_POWER)) {
    PoStartNextPowerIrp(Irp);
    }
    IoCompleteRequest(Irp, IO_NO_INCREMENT);
    return Status;
    }


    ---
    NTDEV is sponsored by OSR

    Visit the list online at:

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at

    To unsubscribe, visit the List Server section of OSR Online at
    d
  • Alex_GrigAlex_Grig Member Posts: 3,238
    Aren't power IRPs serialized with PNP?
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,434
    That is correct

    Bent from my phone
    ________________________________
    From: xxxxx@lists.osr.com on behalf of Device Engineering Company
    Sent: Wednesday, April 5, 2017 1:46:21 PM
    To: Windows System Software Devs Interest List
    Subject: Re: [ntdev] IRP_MJ_POWER


    I 'm assuming the I/O Manager is taking a reference on a device object before invoking a dispatch handler. Is that correct ?

    --- NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at
    d
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,434
    No, only system set power. Device set power, wait wake, query power are all outside of the pnp lock.

    Bent from my phone
    ________________________________
    From: xxxxx@lists.osr.com on behalf of xxxxx@broadcom.com
    Sent: Wednesday, April 5, 2017 4:36:57 PM
    To: Windows System Software Devs Interest List
    Subject: RE:[ntdev] IRP_MJ_POWER

    Aren't power IRPs serialized with PNP?


    ---
    NTDEV is sponsored by OSR

    Visit the list online at:

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at

    To unsubscribe, visit the List Server section of OSR Online at
    d
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Thank you for the response Doron.

    Actually the remove lock acquisition failure signals the end of the game for device access (physical device and resources) but not for the device extension (from a dispatch handler). The IRP_MN_REMOVE_DEVICE handler powers the device off and saves the device's power strate in the device extension. The IRP_MN_SET_POWER handler could return this state to the PNP Manager rather than failing the IRP, no ?
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,434
    Sure. It does mean the end game for most of the state in the device extension though as the remove device will free up resouces

    Bent from my phone
    ________________________________
    From: xxxxx@lists.osr.com on behalf of xxxxx@gmail.com
    Sent: Wednesday, April 5, 2017 5:26:43 PM
    To: Windows System Software Devs Interest List
    Subject: RE:[ntdev] IRP_MJ_POWER

    Thank you for the response Doron.

    Actually the remove lock acquisition failure signals the end of the game for device access (physical device and resources) but not for the device extension (from a dispatch handler). The IRP_MN_REMOVE_DEVICE handler powers the device off and saves the device's power strate in the device extension. The IRP_MN_SET_POWER handler could return this state to the PNP Manager rather than failing the IRP, no ?

    ---
    NTDEV is sponsored by OSR

    Visit the list online at:

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at

    To unsubscribe, visit the List Server section of OSR Online at
    d
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Thank you for the response Doron.
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
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA