Driver power state failure error occurs with ntoskrnl.exe.
Driver power state failure error occurs with ntoskrnl.exe.
Welcome to the forums, newcomer!
Clean install of Windows 10 & 11
Where did you obtain the installers for these operating systems?
Run the latest BIOS revision via MSI
What BIOS version is your motherboard using?
MOBO: MSI x670-P Pro
Is this the motherboard in your system?
PRO X670-P WIFI
PRO series boards, optimized with 14 Duet Rail Power System, DDR5 memory with Memory Boost, Lightning Gen5 M.2, Extended Heatsink, Double-sided M.2 Shield Frozr, Wi-Fi 6E, USB 3.2 Gen 2x2
www.msi.com
Updated all drivers and attempted to revert some to identify the issue
Could you explain the steps you took? Did you use DDU, then switch to elevated command to install the drivers?
Hey, thanks.
• The installers are sourced from the Microsoft Media Installation tool from their official website, I wouldn't download my OSes anywhere else.
Links:
Download Windows 11
Download Windows 10
• Bios version: 7D67v1A
PRO X670-P WIFI
PRO series motherboards, tuned for better performance by 14 Duet Rail Power System, DDR5 memory with Memory Boost, Lightning Gen5 M.2, Extended Heatsink, Double-sided M.2 Shield Frozr, Wi-Fi 6E, USB 3.2 Gen 2x2
www.msi.com
• Correct that is my motherboard.
To answer your last question, indeed I am using DDU, I uninstall the graphics drivers within safemode and then reinstall them within the regular windows environment, ensuring that my PC isn't connected to the network so it doesn't auto-download drivers from the internet, this issue persisted through the newest and oldest drivers available for my card.
Uninstalling any other drivers I've done through the method of using device manager, and or through their uninstaller tools (chipset) for example, currently they are all using their latest updates as well as firmwares. I've also tried a few older BIOS revision which didn't work thus I updated it back.
Since this error is so sporadic and as well time-based around the same timestamp as mentioned in my main post, I am hoping somebody can debug the dumps I left behind in my main post within the link of that google drive, there would be 4 dumps there with their corresponding BSOD, which of two are DRIVER_POWER_STATE_FAILURE
This issue persisted on my Windows 10 installation and Windows 11 installation right now, I have installed Windows 11 as people recommended to try it out to see if it would help my issues.
Hi!
I found another dump file recently, as the same crash type occurred once more. This time there were no errors, just a successful creation of the dump file. The process name remains ntoskernel.exe.
101223-4750-01.dmp
drive.google.com
I really wish someone could assist me with these dumps and help identify which device is failing on my PC. This isn't a software issue and it's progressively worsening.
First off (and before you have another BSOD) can you please copy the file C:\Windows\Memory.dmp to a temporary location (in a temp file perhaps) in case we need it later. That's the full kernel dump for the most recent BSOD, it will be overwritten if another BSOD occurs. The bugcheck for this BSOD is a DPC_WATCHDOG_VIOLATION bugcheck with an argument 1 value of 0x1, and they can only be fully debugged with a kernel dump. That's why I'm asking for it to be saved - although I may not need it.
The other four dumps you uploaded earlier point in two entirely different directions. One is easy to analyse and the other less so. First the easy one...
Two of your dumps are DRIVER_POWER_STATE_FAILURE bugchecks. These occur because a device took too long completing a power transition (from a low power idle state to a high power running state, or vice-versa). In the dump we get both the IRP (Interrupt Request Packet) of the failing power transition and the device object address of the failing device...
Code:
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: ffffcf01deb10050, Physical Device Object of the stack
Arg3: ffffa78848d97178, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
Arg4: ffffcf01e52748a0, The blocked IRP
We can use a sort of shorthand to display both the IRP and the device involved by using the !devstack command on the device object address in argument 2...
Code:
15: kd> !devstack ffffcf01deb10050
!DevObj !DrvObj !DevExt ObjectName
ffffcf01e52268d0 \Driver\partmgr ffffcf01e5226a20 InfoMask field not found for _OBJECT_HEADER at ffffcf01e52268a0
ffffcf01e53a1080 \Driver\disk ffffcf01e53a11d0 InfoMask field not found for _OBJECT_HEADER at ffffcf01e53a1050
ffffcf01e520fda0 \Driver\EhStorClassffffcf01e5217ba0 InfoMask field not found for _OBJECT_HEADER at ffffcf01e520fd70
> ffffcf01deb10050 \Driver\storahci ffffcf01deb101a0 Cannot read info offset from nt!ObpInfoMaskToOffset
!DevNode ffffcf01de9dc4e0 :
DeviceInst is "SCSI\Disk&Ven_&Prod_CT1000MX500SSD1\7&2ff5684&0&010000"
ServiceName is "disk"
At the top is a summary of the IRP. You can see that the drivers involved in the IRP are related to storage drives, so we know that the device failing the power transition is a storage drive. At the bottom is the key data from the device node (obtained via the device object). You can see that the device is a disk (Windows calls all HDD and SSD devices a disk) and that it's identity is CT1000MX500SSD1. That's a Crucial MX500 1TB SATA SSD.
These two dumps then suggest that there has been a problem with that SSD handling a power transition. That may indicate a problem with the drive, but it may also simply be that the drive has no power transition capability. Try setting the "Turn off hard disks" value to 0 in the power options. That will stop Windows trying to put them in a low power state.
The other two dumps - and probably the latest one too - point at a graphics problem. Two of these three dumps are VIDEO_MEMORY_MANAGEMENT_INTERNAL bugchecks with an argument 1 value of 0x17. That indicates that a graphics card command unexpectedly failed and for unknown reasons. Both dumps clearly show a graphics operation in progress and both show references to nvlddmkm.sys, your Nvidia graphics driver.
The problem here is going to be either a driver failure (in nvlddmkm.sys) or a graphics card hardware error. The version of nvlddmkm.sys that you're running dates from August 2023 and may not be current...
Code:
0: kd> lmDvmnvlddmkm
Browse full module list
start end module name
fffff800`690b0000 fffff800`6ca1f000 nvlddmkm (deferred)
Image path: nvlddmkm.sys
Image name: nvlddmkm.sys
Browse all global symbols functions data
Timestamp: Sat Aug 5 01:45:28 2023 (64CD7F88)
CheckSum: 0386F181
ImageSize: 0396F000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Information from resource tables:
Look first for an updated driver and download it. Also
download DDU
and use that tool to uninstall all traces of earlier graphics drivers (it will reboot the system) and then install the latest driver. See whether that helps.
The most recent dump is DPC_WATCHDOG_VIOLATION bugcheck with an argument 1 value of 0x1. This means that all the DPCs that were running collectively ran for too long (a DPC is a Deferred Procedure Call, they form the back-end of device interrupt processing and their code is part of the device drivers). As I've mentioned, we need a kernel dump to debug those fully, because the minidump only contains status for the failing processor.
That siad, and since we already suspect nvlddmkm.sys or the graphics card, the failing processor in this minidump is also a graphics operataion and it calls nvlddmkm.sys. Here's the call stack from that dump...
Code:
7: kd> knL
# Child-SP RetAddr Call Site
00 ffff9681`73df9c88 fffff801`0ec28859 nt!KeBugCheckEx
01 ffff9681`73df9c90 fffff801`0ec280c1 nt!KeAccumulateTicks+0x239
02 ffff9681`73df9cf0 fffff801`0ec26151 nt!KiUpdateRunTime+0xd1
03 ffff9681`73df9ea0 fffff801`0ec25b7a nt!KeClockInterruptNotify+0xc1
04 ffff9681`73df9f40 fffff801`0ecae6dc nt!HalpTimerClockInterrupt+0x10a
05 ffff9681`73df9f70 fffff801`0ee1489a nt!KiCallInterruptServiceRoutine+0x9c
06 ffff9681`73df9fb0 fffff801`0ee15107 nt!KiInterruptSubDispatchNoLockNoEtw+0xfa
07 fffffe08`44b0dd70 fffff801`5086c172 nt!KiInterruptDispatchNoLockNoEtw+0x37
08 fffffe08`44b0df08 fffff801`508825a0 nvlddmkm+0x9bc172
09 fffffe08`44b0df10 00000000`000007d2 nvlddmkm+0x9d25a0
0a fffffe08`44b0df18 fffffe08`00000000 0x7d2
0b fffffe08`44b0df20 00000000`00000653 0xfffffe08`00000000
0c fffffe08`44b0df28 fffff801`0ed21e54 0x653
0d fffffe08`44b0df30 00000000`00000050 nt!KiExitDispatcher+0xb4
0e fffffe08`44b0e2e0 ffffab82`ac53bb20 0x50
0f fffffe08`44b0e2e8 00000000`00000001 0xffffab82`ac53bb20
10 fffffe08`44b0e2f0 ffffab82`ac53bb20 0x1
11 fffffe08`44b0e2f8 00001ac0`00000001 0xffffab82`ac53bb20
12 fffffe08`44b0e300 ffffab82`add23202 0x00001ac0`00000001
13 fffffe08`44b0e308 00000001`00006c85 0xffffab82`add23202
14 fffffe08`44b0e310 00000000`0000000a 0x00000001`00006c85
15 fffffe08`44b0e318 fffff801`5086b9c3 0xa
16 fffffe08`44b0e320 00000002`caa10000 nvlddmkm+0x9bb9c3
17 fffffe08`44b0e328 00000000`00000000 0x00000002`caa10000
You can see nvlddmkm.sys being called repeatedly (which is normal) but you can also see a lot of garbage call addresses (the ones without symbols). I'm inclined to suspect that these garbage addresses are coming from nvlddmkm.sys (mostly because we already suspect it).
If I need toi look deeper into this dump I'll ask you to upload the saved kernel dump, buit we can hold off for now because I suspect that clean installing the latest Nvidia driver with DDU may solve this problem too.
I’m having trouble locating the memory.dmp file, isn’t it? It looks like it should be in the Windows folder. It seems to be missing now. I suspect this is what I’ve been guessing. Recently I received an RTX 4080 and started experiencing micro-stuttering in games right away. I’ve reinstalled the driver several times using both older and newer DDU versions, even trying it for the newest driver a few nights ago, but it still failed with the same video card BSOD yesterday and a DRIVER_FAILURE the day before. In my case, the SSD is old and possibly connected to the wrong port on my motherboard—it’s sitting on the ASMEDIA port. I’m not sure if this is the cause. I’ll back up its files right away and consider replacing it since it’s an aging device; having a bigger NVME drive would be better than keeping all my current storage.
Based on what you're suggesting and having tested several drivers with DDU each time, I recommend sending back the 4080 for RMA. I believe the issues lie with the card itself. Provide the dumps and note that you've tried various drivers using DDU as proof.
Your explanation about the SSD is logical. The 0x9F BSODs don't necessarily mean the drive will fail soon—unless the system logs show numerous bad block messages for that drive. Still, backing up is always a good idea. An NVMe drive would be significantly faster.
The absence of the memory.dmp file isn't critical here, but make sure your dump settings for 'Write debugging information' are set to 'Automatic memory dump'. Also, ensure the 'Overwrite any existing file' option is checked. This guarantees a kernel dump and a minidump are created, which is important because only one kernel dump is stored, so you don't need to worry about space constraints. There are other situations where a kernel dump is necessary to fully troubleshoot the problem.
Thank you for your thorough examination of the minidumps. I understand why you need this solution, as the problem has persisted for some time and is becoming more severe.
I plan to swap in a new NVME 4TB SATA SSD, using my Kingston Fury as the primary storage device—this drive appears to be around four months old, possibly the fastest one I own.
I’ll return the RTX 4080 and share any issues I encounter, noting that all my files are backed up in my Google Drive.
I’ll keep you informed throughout the process once I’m ready.
System's GPU has been swapped, but the old one remains for reference—it had some graphical issues and hasn't caused major stuttering yet. I’ll keep testing to see if the problem persists with this card. The crucial SSD stays disabled until I get a new NVME drive to replace the current SATA storage. I’ll post any BSODs in future updates if they happen.
Still awaiting a BSOD or black screen, though facing the same micro stutter problem as before, it seems just as severe as the 4080 situation. This issue appears similar to the other graphics cards and hasn't caused problems before with stuttering. I don't recall having them near artifacts at times. The power transitions that also impacted the SSD raise the possibility that the PSU might be the cause. This SSD has functioned well for years with a different PSU, and the PSU I currently use is the replacement for the 4080, which is around 6-7 weeks old. HWMonitor doesn't show unusual voltage readings sometimes—it's just a bit lower on the 12V and higher at times, but that seems normal. Checking Windows logs reveals nine instances of a Kernel 41 (63) power error, each generating a minidump for a BSOD, except four which never did. I haven't powered off the PC as before; I always put it to sleep because I remember black screens during cold bootups that prevented Windows from loading, causing the system to restart mid-boot. I've even started thinking about replacing the motherboard since I doubt the PSU is the root cause, but this is why I'm asking—could the PSU be responsible despite normal readings in HWMonitor? Or is my reasoning unrealistic?
That you're still having stuttering means that the graphics card was likely not the root cause. Also, the earlier dumps pointing in two different directions is (and was then) a concern. I don't believe in there being two separate problems at the same time, so these are problems are most likely linked somehow.
The error 41 message is written at startup, it only indicates that Windows wasn't shutdown properly the last time. It's got nothing to do with power, they chose that description (I assume) to indicate that the power went off before Windows had shutdown. That there were no dumps written suggests a hardware cause that crashed Windows in a way that the kernel didn't detect.
I feel sure that this is a hardware problem. One way to confirm that is to
start Windows in Safe Mode
. In Safe Mode only critical Windows components are loaded and (usually) no third-party drivers are loaded. It's a stripped-down minimal Windows system. Its only purpose is to see whether this stripped-down Windows system will crash or BSOD, if it does then you can be pretty certain that you have a hardware problem. Of course, if it won't crash in Safe Mode then it's a software problem and we have tools that will help us find out what.
In Safe Mode you won't be able to do any useful work. Many of your devices will not function properly (or at all) - your display will be low-res for example, because you'll be using only the Windows basic display driver. You do need to use the PC as much as you're able to in Safe Mode in order to try and make it crash or BSOD.
I would suggest that you start Windows in Safe Mode without networking at first because that loads no networking drivers. Then try Safe Mode with networking later on.