BthPS3: BthPS3.sys DRIVER_POWER_STATE_FAILURE restoring from hibernate - Windows 10/11
BthPS3 version v2.0.144 Windows 11 version 22000.100 Had a DRIVER_POWER_STATE_FAILURE after restoring from Hibernate
WinDBG log as follows:
Microsoft (R) Windows Debugger Version 10.0.21349.1004 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\Minidump\072521-27953-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*C:\Symbols*https://msdl.microsoft.com/download/symbols
Symbol search path is: srv*C:\Symbols*https://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 10 Kernel Version 22000 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Edition build lab: 22000.1.amd64fre.co_release.210604-1628
Machine Name:
Kernel base = 0xfffff806`7da00000 PsLoadedModuleList = 0xfffff806`7e629600
Debug session time: Sat Jul 24 21:13:06.253 2021 (UTC - 4:00)
System Uptime: 0 days 2:58:38.079
Loading Kernel Symbols
...............................................................
................................................................
................................................................
................................................................
.................
Loading User Symbols
Loading unloaded module list
........................
For analysis of this file, run !analyze -v
nt!KeBugCheckEx:
fffff806`7de129b0 48894c2408 mov qword ptr [rsp+8],rcx ss:0018:ffffb70f`58a8f6a0=000000000000009f
7: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an IRP for too long a time
Arg2: ffffb88a95fe5a70, Physical Device Object of the stack
Arg3: ffffb70f58a8f6d0, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
Arg4: ffffb88abb075010, The blocked IRP
Debugging Details:
------------------
*** WARNING: Unable to verify timestamp for BthPS3.sys
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 3999
Key : Analysis.DebugAnalysisManager
Value: Create
Key : Analysis.Elapsed.mSec
Value: 14693
Key : Analysis.Init.CPU.mSec
Value: 983
Key : Analysis.Init.Elapsed.mSec
Value: 603378
Key : Analysis.Memory.CommitPeak.Mb
Value: 90
Key : WER.OS.Branch
Value: co_release
Key : WER.OS.Timestamp
Value: 2021-06-04T16:28:00Z
Key : WER.OS.Version
Value: 10.0.22000.1
TAG_NOT_DEFINED_202b: *** Unknown TAG in analysis list 202b
BUGCHECK_CODE: 9f
BUGCHECK_P1: 3
BUGCHECK_P2: ffffb88a95fe5a70
BUGCHECK_P3: ffffb70f58a8f6d0
BUGCHECK_P4: ffffb88abb075010
DRVPOWERSTATE_SUBCODE: 3
DRIVER_OBJECT: ffffb88a80632e10
IMAGE_NAME: BthPS3.sys
MODULE_NAME: BthPS3
FAULTING_MODULE: fffff8069a6f0000 BthPS3
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXPNP: 1 (!blackboxpnp)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: System
STACK_TEXT:
ffffb70f`58a8f698 fffff806`7dfc2ca7 : 00000000`0000009f 00000000`00000003 ffffb88a`95fe5a70 ffffb70f`58a8f6d0 : nt!KeBugCheckEx
ffffb70f`58a8f6a0 fffff806`7dfc2bc1 : ffffb88a`89eac208 00000000`00000080 ffffb70f`58a8f9f8 ffffb70f`58a8f9f0 : nt!PopIrpWatchdogBugcheck+0xdf
ffffb70f`58a8f710 fffff806`7dc12824 : 00000000`00000000 ffffb88a`00000001 ffffb70f`00000000 ffffb88a`00000002 : nt!PopIrpWatchdog+0x31
ffffb70f`58a8f760 fffff806`7dc10e14 : 00000000`00000000 00000000`00000000 00000000`00000000 fffff806`7aa52648 : nt!KiProcessExpiredTimerList+0x204
ffffb70f`58a8f890 fffff806`7de168fe : 00000000`00000000 ffff8101`9fdd6180 ffff8101`9fde2240 ffffb88a`86bbd080 : nt!KiRetireDpcList+0x714
ffffb70f`58a8fb40 00000000`00000000 : ffffb70f`58a90000 ffffb70f`58a89000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x9e
STACK_COMMAND: .thread ; .cxr ; kb
FAILURE_BUCKET_ID: 0x9F_3_IMAGE_BthPS3.sys
OS_VERSION: 10.0.22000.1
BUILDLAB_STR: co_release
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {328a30da-bacc-a428-20ed-22a427c03a3c}
Followup: MachineOwner
---------
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 3
- Comments: 33 (19 by maintainers)
Can you guys that add nothing to the issue stop spamming/whining? Its annoying when you‘re subscribed here.
Oof, looking at the code again with a few months break is an experience… Like “who wrote this… oh, right, it was me…”
Work to tackle this has started on the branch
nefarius/issue/DRIVER_POWER_STATE_FAILURE-fixThe plan is to remove chunks of legacy verbose sections with DMF, especially the child device creation and lifetime handling. The underlying issue is, that currently upon power down for sleep/hibernation the controller gets disconnected, but it also destroys the
WDFDEVICEof the PDO, which then is not available after wake-up and the request sent to it is orphaned and triggers the crash when the kernel watchdog runs and finds it.The plan is to rewrite the child handling code with modern substitutes and change the behaviour on power down to keep the device and resume it when the user wakes up the machine and connects the controller again.
This sounds simple on paper but will require a fair bit of work and testing, but it’s the way to go, so stay tuned 😉
I am aware 🙂 It’s an issue independent from OS (version) and I’ll look into it when there’s time, I kindly don’t need more notifications about this thread 😉
Found the issue. Will need a bit of rework to address it fully but we’re getting there 😌
Aye, it’s on the Roadmap. For 2022. I hope. 😬 So much to do lately it’s crazy.
Seriously, people, what do you expect posting the same thing over and over again? That I magically get more time to work on the fix? If anything, now it will take longer 😒
still waiting for the fix, my laptop bsod a couple of times:) i thought my windows/other devices on my laptop making the bsod happen.
Yes, it’s a known issue. As a workaround make sure to disconnect your controllers before you send the machine to sleep.
The behaviour is pretty consistent to reproduce, connect controller, send PC to sleep, wake it up, almost exactly 10 minutes later (Windows Kernel Watchdog Timer) the BSOD happens.
I haven’t had the time to look into it yet so simply watch this issue’s progress and I don’t need anymore “happens to me too” comments for the time being, thank you 😛
Just had this too