Another BSOD occurrence reported – driver system power failure possibly linked to ntoskrnl.exe
Another BSOD occurrence reported – driver system power failure possibly linked to ntoskrnl.exe
All decisions might hinge on performing a fresh setup. There are additional steps to consider before proceeding with a clean install. Just in case: https://forums. = = = = Which Bluetooth devices are present? I recommend turning off (or removing) the Bluetooth drivers if possible. Verify they aren’t being reinstalled or opened through Task Manager, Startup, Task Scheduler, or other programs. Run "dism" and "sfc /scannow" once more. Check whether the BSOD stops and if any installed Bluetooth devices function using standard drivers. If not, manually download, reinstall, and reconfigure the device’s Bluetooth drivers via the manufacturer’s official site. Avoid third-party tools or installers. Make sure the website you visit is genuinely from the manufacturer. A name like "Manufactuer X" in the URL doesn’t guarantee authenticity.
So yes, I completely reinstalled Windows from the official website onto a thumb drive. Still, the BSODs remain unresolved. Everything looks standard and basic (except for the driver reinstall), yet it keeps crashing. I’ve been using it without any issues before now. The only time it stops working was when I left it unattended for a while, which gives me my main clue so far. This is the only thing that’s stayed consistent throughout all the crashes. I looked into reliability monitor, and the only reliable sign was Microsoft GameInput showing "successful application installation" right before the crash. GameInput has remained stable across every incident. I wasn’t sure how a game controller input could cause such a problem, but if this is the issue, what steps would I take to fix it?
Tap "View technical details....." for Critical Events. Record any related error codes, warnings, or information as needed.
All the information I found under "Windows stopped working" matches what I expected. The other message just says "Windows shut down unexpectedly," which makes sense. Edit: GameInput remains the only event with useful data, showing the crash time aligned with a successful installation. It’s hard to believe all six crashes followed an update right before them. Edit 2: There’s also "WindowsPackageManagerServer.exe Stopped Working," though these seem to occur randomly. I’m unsure if they’re related to the crashes, but they’re still important enough to include here.
I see you have a 2x32GB DDR5 RAM kit installed, and even though it appears in the BIOS when reinstalling Windows, I'm wondering if this configuration is listed on your motherboard's support list. Since the gameinput package installer installs smoothly but crashes afterward, it makes me concerned that the system might be at risk if the RAM or the IMC isn't receiving a consistent voltage supply due to minor power fluctuations. 64GB kits of DDR5 are less established in BIOS settings compared to the more common 32GB or even the growing popularity of 48GB kits on DDR5 platforms. Of course, over time the 64GB option will become more stable with updated BIOS configurations, but it's not widely available yet.
This is likely as anything else. Though I couldn't for the life of me find the boards supported RAM, beyond it saying it could handle 64 gigs. But for now, I'm about to go out of town for a few days and won't be able to test the RAM or make any other changes until I'm back home.
Besides that though, an update. I haven't had any crashes for a whole 24 hours! I even purposely left the computer on overnight to see if I'd come back to another crash and it didn't. The only things I changed were doing a storage drive check using a CHKDSK /f /r /x command and setting the "GameInput" service to automatic instead of manual (I think I read that this would fix it somewhere). I actually think that one of those things fixed it, but I'll have to wait until I'm back home to fully make sure. But hey, no crashes! This is definitely an improvement. I just hope the previous crashes didn't cause any damage.
Well, now that I'm back home, I can confidently say one of those two things probably resolved the issue. I kept the computer running for another full day since I arrived, and it hasn't crashed at all—unlike before when it would crash multiple times. Now I'm using it for work without any problems. Maybe I just got lucky, but either way I'm really relieved. If this happens again, I'll probably replace the RAM or just ask here once more. Thanks to everyone who helped so far!
Apologies for not responding earlier, I've been having issues with my left eye and my ophthalmologist ordered me not to use the PC for at least 10 days(!) and then there were the holidays....
The issue seems sorted but I can confirm from the dumps that the issue was (is) with the 2TB Seagate Barracuda HDD. All the dumps show that a device failed to power up (from idle low power state to running normal power state). The dump also shows that the problem device was the Seagate HDD. Here's the key data from one of the dumps...
Code:
4: kd> !devnode ffffe403919a88a0
DevNode 0xffffe403919a88a0 for PDO 0xffffe403919c0050
Parent 0xffffe40391933a20 Sibling 0000000000 Child 0000000000
InstancePath is "SCSI\Disk&Ven_&Prod_ST2000DM008-2FR1\7&3611b6d6&0&010000"
ServiceName is "disk"
State = DeviceNodeStarted (0x30a)
Previous State = DeviceNodeEnumerateCompletion (0x30f)
StateHistory[15] = DeviceNodeEnumerateCompletion (0x30f)
StateHistory[14] = DeviceNodeEnumeratePending (0x30e)
StateHistory[13] = DeviceNodeStarted (0x30a)
StateHistory[12] = DeviceNodeEnumerateCompletion (0x30f)
StateHistory[11] = DeviceNodeEnumeratePending (0x30e)
StateHistory[10] = DeviceNodeStarted (0x30a)
StateHistory[09] = DeviceNodeEnumerateCompletion (0x30f)
StateHistory[08] = DeviceNodeEnumeratePending (0x30e)
StateHistory[07] = DeviceNodeStarted (0x30a)
StateHistory[06] = DeviceNodeStartPostWork (0x309)
StateHistory[05] = DeviceNodeStartCompletion (0x308)
StateHistory[04] = DeviceNodeStartPending (0x307)
StateHistory[03] = DeviceNodeResourcesAssigned (0x306)
StateHistory[02] = DeviceNodeDriversAdded (0x305)
StateHistory[01] = DeviceNodeInitialized (0x304)
StateHistory[00] = DeviceNodeUninitialized (0x301)
StateHistory[19] = Unknown State (0x0)
StateHistory[18] = Unknown State (0x0)
StateHistory[17] = Unknown State (0x0)
StateHistory[16] = Unknown State (0x0)
Flags (0x24000130) DNF_ENUMERATED, DNF_IDS_QUERIED,
DNF_NO_RESOURCE_REQUIRED, DNF_NO_LOWER_DEVICE_FILTERS,
DNF_NO_UPPER_DEVICE_FILTERS
CapabilityFlags (0x00402180) SilentInstall, RawDeviceOK,
WakeFromD3
Unknown flags 0x00400000
The InstancePath value of SCSI\Disk&Ven_&Prod_ST2000DM008-2FR1 identifies the Seagate drive as the problem. Notice at the bottom there that it's supposed to be able to wake from D3 state (idle low power) but the BSOD shows that it didn't.
Displaying the IRP managing the power transition also clearly shows that it's a disk drive problem...
Code:
4: kd> !irp ffffe4039bd388a0
Irp is active with 6 stacks 3 is current (= 0xffffe4039bd38a00)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
cmd flg cl Device File Completion-Context
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
>[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
0 e1 ffffe403919c0050 00000000 fffff80115498510-ffffe4039c0ac590 Success Error Cancel pending
\Driver\storahci CLASSPNP!ClasspPowerUpCompletion
Args: 00000000 00000001 00000001 00000000
[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
0 e1 ffffe4039c0ac050 00000000 fffff8011435ec60-00000000 Success Error Cancel pending
\Driver\disk partmgr!PmPowerCompletion
Args: 00000000 00000001 00000001 00000000
[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
0 e1 ffffe4039beee9a0 00000000 fffff8011112cf80-ffffe4039c046248 Success Error Cancel pending
\Driver\partmgr nt!PopRequestCompletion
Args: 00000000 00000001 00000001 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-ffffe4039c046248
Args: 00000000 00000000 00000000 00000000
You can see three drivers on the IRP queue - all power related. The bottom one ( \Driver\partmgr nt!PopRequestCompletion) is the one that's stuck waiting for the drive to power up.
The chkdsk may have found and fixed a bad sector or a glitch in the filesystem, but this may also be a drive controller issue. If this were mine I would ensure that all data on that drive was backed up at all times, and if this BSOD happens again I would replace the drive.
There is a workaround for this issue too that you may want to try. In your power profile, change the 'Turn off hard disk' setting to 0 minutes. This stops the HDDs from powering down, so this powering up problem should not happen again.
Oh, sorry about your eyes! I hope you're doing well. Also... you're probably joking, but I was really concentrating on my M.2s and forgot to mention the backup HDD I also had since I never use it. That was a big mistake on my part—I think it could have been fixed much sooner if I'd brought it up earlier! But wow, I'm impressed you figured out the real reason! This means GameInput wasn't the problem; it was actually the chkdsk that helped me! It also suggests the permanent solution should be as simple as swapping in a new HDD, rather than dealing with M.2s or RAM—which would be the best outcome honestly. Thanks a lot! I'm glad we have a clear explanation about why this kept happening. The drive is old, so maybe it's time to replace it anyway—perhaps with an SATA SSD as a nice upgrade!
Feel free to reach out. If the storage is outdated, I'd consider swapping it out. For backups only, an HDD would be preferable over an SSD. You don't require extremely fast read/write speeds for backups and restores, and relying on an SSD when it fails can lead to a complete loss. With an HDD, as long as the drive starts up, you typically can recover the data.