Recently , I have encountered some difficult problem about POWER BSOD.
The output for !analyze -v is:
`0: kd> !analyze -v
DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000004, The power transition timed out waiting to synchronize with the Pnp
subsystem.
Arg2: 0000000000000258, Timeout in seconds.
Arg3: fffffa80045d3040, The thread currently holding on to the Pnp lock.
Arg4: fffff800070b2790, nt!TRIAGE_9F_PNP on Win7 and higher`
I do not know what does the “Pnp lock” mean.
What is the relation between “Pnp lock” and Power IRP ?
Looking forward to your help!
On Oct 29, 2018, at 7:03 PM, weilin_jiang wrote:
>
> Recently , I have encountered some difficult problem about POWER BSOD.
> …
> DRIVER_POWER_STATE_FAILURE (9f)
>
> A driver has failed to complete a power IRP within a specific time.
>
> Arguments:
>
> Arg1: 0000000000000004, The power transition timed out waiting to synchronize with the Pnp
> subsystem.
> I do not know what does the “Pnp lock” mean.
I think you can guess this, can’t you? During the power state change some driver was blocking PnP requests. Does this system have a driver that you wrote? Is it possible you block during transitions out of D0? This is saying some driver waiting 10 minutes, which is a hell of a long time.
—
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
If your driver is a KMDF driver be sure to read this article.
Peter
To track this down further you can run !pnplocks. This will show you which threads own PnP locks and thus are potentially stuck in PnP operations. Run !thread on the addresses and look at the stacks.
@Tim_Roberts said:
On Oct 29, 2018, at 7:03 PM, weilin_jiang wrote:
Recently , I have encountered some difficult problem about POWER BSOD.
…
DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000004, The power transition timed out waiting to synchronize with the Pnp
subsystem.
I do not know what does the “Pnp lock” mean.
I think you can guess this, can’t you? During the power state change some driver was blocking PnP requests. Does this system have a driver that you wrote? Is it possible you block during transitions out of D0? This is saying some driver waiting 10 minutes, which is a hell of a long time.
—
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
That is the Power IRP would be send to the driver after the driver processes the PnP IRP. However , the driver block the PnP IRP so that Power Manager can not send Power IRP to it .Finally, system call bugcheck after 10 minutes.
Am I right ?
@“Peter_Viscarola_(OSR)” said:
If your driver is a KMDF driver be sure to read this article.
Peter
Thanks, Peter. That is a WDM filter driver.
@“Scott_Noone_(OSR)” said:
To track this down further you can run !pnplocks. This will show you which threads own PnP locks and thus are potentially stuck in PnP operations. Run !thread on the addresses and look at the stacks.
This is minidump has no more information.
In fact, I do not know the relation between PnP(such start/remove device) and Power IRP.
How does a driver, such as bus or filter driver, process PnP/Power IRP ?
It seem that the different driver type process these IRP differently.
Where can I get more informaion about PnP and Power IRP ?
I have some confusion about synchronization between PnP and Power IRP.
The left column in the below picture is the PnP IRP which is related to Power IRP.
from Sysnative Forums… (path removed by mods, due to VERY badly incorrect information referenced at the link)
You’re asking good questions, but ones that are difficult to answer…at least for me… without giving you a 3 hour lecture on how PnP and Power work in WDM. This is perhaps THE best reason to use WDF.
You get a 9F when you hold a power IRP too long. This is typically because you’re delaying a power state change while some set of I/O requests complete… and all those requests don’t complete in time.
Just FYI… there is a great deal of horribly incorrect information in that article you referenced. There are some interesting practical points… but his underlying architectural stuff is frighteningly bad (for example, he says that bus drivers and filter drivers are the only types of drivers that process power IRPs… yikes!).
I hope that helps,
Peter
weilin_jiang wrote:
In fact, I do not know the relation between PnP(such start/remove device) and Power IRP.
How does a driver, such as bus or filter driver, process PnP/Power IRP ?
As a general rule, filter drivers pass power IRPs along without
processing them. In each driver stack, one driver is designated as the
“power policy owner”. That driver is responsible for power IRPs; the
others just pass them through.
Bus drivers are often the power policy owners for their own device (that
is, a USB host controller driver is the power policy owner for the USB
host controller), but not for their child devices.
Filter drivers might use PnP requests to manage their own lifetime, but
there’s little reason for them to block. Bus drivers have more PnP work
to do, since they have to manage their sub-devices.
I have some confusion about synchronization between PnP and Power IRP.
I’m not sure why you are confused. In the typical driver, there is no
need for synchronization between PnP and power IRPs. The two sets of
operations are relatively independent. This is especially true in KMDF,
which manages the ugliness for you.
@weilin_jiang said:
This is minidump has no more information.
A minidump is useless in tracking this down. You need at least a kernel summary dump.
@Tim_Roberts said:
Bus drivers are often the power policy owners for their own device (that
is, a USB host controller driver is the power policy owner for the USB
host controller), but not for their child devices.
Bus drivers have more PnP work to do, since they have to manage their sub-devices.
For 2,
I know the Bus drivers must unplug the sub-devices and process the un-completed IRP .
These viewpoints above I said is from USBIP project.
But, in the USBIP project, I think the project is not the policy owner because I do not see any code as a “device power policy owner”,
such as call the PoRequestPowerIrp(this functon used to send a device power IRP to a device) function.
Who is the device power policy owner ?
For 1,
Why are Bus drivers a power policy owner ?
In the USBIP project, the virtual bus driver(FDO) just pass its power IRP to next lower driver.
For the child device’s(PDO) power IRP, the virtual bus driver simply completes it .
@“Peter_Viscarola_(OSR)” said:
You’re asking good questions, but ones that are difficult to answer…at least for me… without giving you a 3 hour lecture on how PnP and Power work in WDM. This is perhaps THE best reason to use WDF.
You get a 9F when you hold a power IRP too long. This is typically because you’re delaying a power state change while some set of I/O requests complete… and all those requests don’t complete in time.
Just FYI… there is a great deal of horribly incorrect information in that article you referenced. There are some interesting practical points… but his underlying architectural stuff is frighteningly bad (for example, he says that bus drivers and filter drivers are the only types of drivers that process power IRPs… yikes!).
I hope that helps,
Peter
Thanks for your correction, Peter.
I think the WDF has no help to filter driver for processing power IRP.n
I think the WDF has no help to filter driver for processing power IRP
I think you’re mistaken, but I don’t think that’s really relevant in any case.
If you have a 9F blue screen, the issue is (he said, repeating himself) that you’re holding an IRP too long during a Power operation. Concentrate on that. I’m not sure why we are talking about bus drivers and PnP. You’ve got a filter. You’re apparently holding an IRP in progress. This is apparently delaying a power IRP. Go find and fix that, and you’re done.
If you’re a filter, why are you even hand,king power IRPs. If you’re not the PPO (and you shouldn’t ne) just pass them through.
@“Peter_Viscarola_(OSR)” said:
I think the WDF has no help to filter driver for processing power IRP
I think you’re mistaken, but I don’t think that’s really relevant in any case.
If you have a 9F blue screen, the issue is (he said, repeating himself) that you’re holding an IRP too long during a Power operation. Concentrate on that. I’m not sure why we are talking about bus drivers and PnP. You’ve got a filter. You’re apparently holding an IRP in progress. This is apparently delaying a power IRP. Go find and fix that, and you’re done.
If you’re a filter, why are you even hand,king power IRPs. If you’re not the PPO (and you shouldn’t ne) just pass them through.
Actually , I write a disk filter driver which just pass power IRP to next lower driver.
Now, the system crash in some other drivers but the disk filter driver has so wide rage of influence that I must to know whether every BSOD is relative to the disk filter driver.