Another crash log showing a power failure issue with the driver system, specifically linked to ntoskrnl.exe.
Another crash log showing a power failure issue with the driver system, specifically linked to ntoskrnl.exe.
This problem might just come from having a clean restart. But before you start over, here are some other things to do: make sure what Bluetooth devices you have. My advice? Turn those drivers off or remove them if they aren't needed. Then check where they started running by looking at Task Manager under Startup, Task Scheduler, or another program list. Run "dism" and "sfc /scannow" again. See if the blue screen keeps coming up. If so, test if your Bluetooth drivers work with generic drivers instead. If not, go to the official manufacturer's site yourself and download, reinstall, and set them up the right way. Don't use any random third-party tools or installers. Also make sure you're on the real manufacturer's website because a fake URL might look like it has their name in it but isn't actually theirs.
Okay so I went ahead and did a total wipe of Windows by downloading a fresh copy from Microsoft and putting it on my USB drive. Even though the blue screen errors are still showing up after everything is set back to default except for the newest drivers, things keep crashing. I have no idea how to fix this anymore. Honestly, at first I didn't notice any crashes because I was always using the computer when they happened. It's only recently that it has crashed while sitting idle for a long time now. That's my best shot before throwing away the hard drive. Here is a screenshot of what is left after I refreshed the PC, but I'm down to just one drive: https://drive.google.com/file/d/1XCZDCn1...sp=sharing EDIT: Wait, now that I think about it, if this is what broke me, I will probably laugh and cry. I checked the reliability monitor app, but one thing stayed true for every single crash: "Microsoft GameInput" kept showing a "successful installation" right before everything went wrong. I thought no way a game controller input could cause a system failure, even though sometimes things go wrong that we don't expect. If this *is* the problem, how do I actually fix it?
This is all I could find, under "Windows stopped working". The other one just says "Windows shut down unexpectedly", which... duh. Edit: As for the informational events, GameInput is still the only informational event with any relevant data, aka the time of the crash being the same as the time as GameInput had a "successful application installation". I seriously can't see that as a coincidence that all 6ish of my crashes have had GameInput update immediately before them. Edit 2: Oh, and there's "WindowsPackageManagerServer.exe Stopped Working", but these happen seemingly at random. Idk if they have anything to do with the crashes, but they seem important nonetheless so I'm putting an example of it here.
Hey OP, I see you have a RAM kit of 2x32GB sticks set to DDR5. Even though it runs fine by default from your BIOS as you said when reinstalling Windows, is this memory actually supported for your specific motherboard? GameInput just keeps installing and then crashes every time, making me think the power supply might be unstable because minor voltage spikes could hurt both the RAM or the integrated memory controller (IMC). 64GB kits of DDR5 aren't as well-tested in BIOS settings like the usual 32GB sticks or even newer 48GB options that are gaining popularity on DDR5 boards. Sure, it might mature later with better BIOS support, but right now they're just not common yet.
This probably works fine for anything else too. Even though I couldn't figure out if it works with RAM bigger than 64 gigabytes, that's what it said on the box. But right now I'm going away for a few days and won't be able to test the RAM or make any other changes until I come back home anyway. Besides that, here is good news: I haven't had any crashes for twenty-four hours straight! Even though I left the computer running overnight to see if it would crash later and it didn't. The only things I changed were checking my hard drive with a special command called CHKDSK/f/r/x and setting the "GameInput" service from manual to automatic (I thought that might fix it somewhere). Actually, I think one of those two fixes what caused it, but I will wait until I come back home to be sure. But hey, no crashes! This is definitely better than before. Just hope the old crashes didn't break anything inside my computer.
Okay now that I'm home, I can tell one of those two things probably fixed it. I ran the computer for another full 24 hours since I've been home and I haven't had a single crash, whereas before I'd have multiple crashes. Now I'm using it for work, no issues at all. Maybe I just bad lucked it, but either way I'm very relieved. If it starts happening again, I'll likely try replacing the ram or just asking here again. Thanks to everyone who has 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! Hope you feel better too. But seriously... are you kidding me? I was really focused on my M.2 drives and forgot to mention the backup HDD I kept because I never used it. That's a huge mistake on my part; if I had told you sooner, we could have fixed this much faster. Wow! I'm amazed you actually found the real cause! That means GameInput wasn't the problem, but rather that chkdsk saved me. It also means the permanent fix is super easy: just grab a new hard drive instead of an M.2 or even RAM, which sounds like the best outcome for sure. Thanks so much for having a definitive answer about why this kept happening. The drive is pretty old, so maybe I should just replace it anyway—maybe with a SATA SSD as a nice treat!
You are more than welcome to come in. If the drive is old, I would swap it out. If it's a backup-only drive, I'd switch it for a standard hard disk instead of an SSD. You don't need crazy read or write speeds just for backing up and getting things back; when an SSD breaks down, that's always a total failure. But with an HDD, as long as the spinning parts are working, you can still pull most data off even if it fails.