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: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

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).aspxhttps:

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:>

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

To unsubscribe, visit the List Server section of OSR Online at http:>
— 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</http:></http:></http:></https:>

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&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>
> — 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</http:>

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&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>
> — 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
>
></http:>

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&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>
> — 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
>
></http:>

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).aspxhttps:

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:>

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

To unsubscribe, visit the List Server section of OSR Online at http:>
— 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</http:></http:></http:></https:>

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

Facepalm :slight_smile:

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

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

Do as Doron told you. He is right, the remove lock acquisition fails so you must not access the device extension.

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&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

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

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;
}

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: https:

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

To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>

Aren’t power IRPs serialized with PNP?

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

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: https:

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

To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>

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 ?

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: https:

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

To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>

Thank you for the response Doron.