The PC exhibits unusual BSOD behavior upon awakening after component swaps.
The PC exhibits unusual BSOD behavior upon awakening after component swaps.
Hello everyone! Apologies if some parts are hard to understand, English is not my first language, I'll be happy to clarify whatever's misunderstood.
For context, I already know the culprit is the OS because I was able to rule it out thanks to a secondary SSD, but I'm making this thread just to see if my main Windows 11 install is fixable, or if there's no other way to solve this but with a clean install, which would be heavily inconvenient for me at this time.
I had a RTX 2080S, and a Ryzen 7 5800X paired with 32GB of DDR4-3600 RAM in an ASUS ROG STRIX B550-E motherboard. Due to a few economic needs last year, I had to sell both the GPU and CPU I was using, and then I replaced them with a Ryzen 5 5600G.
At the moment I swapped these components out, I had two separate installs of Windows 10, on two separate SSDs. One is my main system which I'm using right now, and the other one is just a clean install with a few tools, more like a "sandbox" or "testing" system. As of today, they're both upgraded (not clean installed) to Windows 11, with no issues.
The day I installed the 5600G processor, the "BSOD when waking from sleep" problem began to happen in my main system, however it does
not
happen in my "sandbox" system. Note that both OS were running with the same 2080S/5800X combo before, but only my main system is showing this issue right now.
The day I swapped hardware I also removed old drivers with DDU, chipset drivers, and anything AMD related I could find on both systems, they're both running the same driver versions, however one has this issue and the other one doesn't.
I have resorted to using Hibernate in my main system, but end up missing the speedy boot times that Suspend gave me, and I find it weird that it works just fine in my other, empty system, which leads me to believe that the only way of solving this would be to clean install Windows 11 in my main SSD.
Here's a picture of the BSOD in question, so you can see why I call it "abnormal". The system hangs completely, and I have to force restart it.
The error code (consistently, doesn't change from reboot to reboot) reads "CRITICAL_PROCESS_DIED", and it's important to note that the BSOD doesn't appear every time I try to wake up the PC from sleep, most of the times it's just a black screen with the same result, a completely frozen system that won't boot up. Keyboard lights up (but doesn't react to caps lock), motherboard RGB lights are cycling and the Dr.Debug LED shows the CPU temperature, but other than that, either there's a BSOD or a black screen and it doesn't boot up.
In my "sandbox" system, none of this happens, the PC boots up from sleep as normal.
Any help will be greatly appreciated, thanks in advance. I hope I didn't forget any important details. Honourable mention to
@Colif
since he may be able to help in this case, I found out about him while trying other steps mentioned in other threads here, to no avail, since I haven't been able to resolve my issue.
I was curious about how your name came to be...
Follow option one on the provided link and then proceed with the next steps:
Small memory dumps - Windows will generate a small memory dump during a BSOD, creating a file in C:\Windows\Minidump after the next crash.
Open Windows File Explorer
Go to C:\Windows\Minidump
Move the mini-dump files onto your Desktop
Avoid using Winzip; use Windows' built-in feature instead
Select the files on your Desktop, right-click and choose 'Send to' - Compressed (zipped) folder
Upload the zip file to the Cloud (OneDrive, Dropbox, etc.)
Share a link to the zip file so we can review it together.
Why were chipset drivers removed even though you still have the same motherboard? Have you reinstalled them since? They might be useful.
Critical process failures are mainly Windows-related errors. While many BSODs can be caused by drivers, this one appears to stem from Windows itself.
This approach may not work, but it’s worth a shot:
Search for PowerShell and open it with admin privileges
Paste the following command into the window:
Repair-WindowsImage -Online -RestoreHealth
Press Enter
Then type SFC /scannow
Press Enter
Restart your PC if SFC fixes any issues, as some repairs need a restart to take effect
The first command cleans files that SFC uses and updates system files.
SFC = System File Checker. The first command runs DISM -
https://docs.microsoft.com/en-us/windows...windows-11
If you successfully update to Windows 11 without errors, it’s possible the issue was resolved. It could also be related to the SSD itself.
What brand is the problematic drive?
Hello and thank you for your prompt response! I apologize for the confusion, but what I intended to convey is that I removed the previous versions and installed the latest updates.
Regarding the steps you outlined:
After repairing WindowsImage, here are the outcomes.
Following the sfc scannow, these results were observed.
The minidump file isn't being generated, even after I've repeated the blue screen replication multiple times and my settings are properly set up.
Prior to attempting the BSOD, I cleared the Event Viewer history and, after restarting post-BSOD, I discovered this event as the cause of the failed dump. However, the event immediately following it states:
"Volume C: (\Device\HarddiskVolume2) is healthy. No action is needed."
Both drives are Western Digital NVMe M.2 SSDs, model WD_BLACK SN750. One is 500GB (the main system), and the other is 2TB (a sandbox version in a smaller 60GB partition).
Here are screenshots from CrystalDiskInfo for both drives.
500GB
2TB
If this were the drive, wouldn't it show additional signs of trouble? So far, everything has functioned perfectly regarding Windows features. There have been no slowdowns, no random crashes, and no file corruption—just this single issue with the Windows sleep feature, which began after I swapped the CPU and replaced the GPU.
As mentioned before, I used Sleep every day before making those changes, and the drive performed without issues when paired with my 5800X/2080S combo.
It's also worth noting that I completed a full memtest86 test, as I read online that the BSOD might relate to RAM. The test ran successfully with no errors, using four 8GB Corsair Vengeance RGB Pro sticks at 3600mhz CL16.
I hope you've noticed this pattern with the minidump issue, so I can actually generate and analyze one...
Thanks a lot
You might want to test it on both storage options, just to confirm:
https://support-en.wd.com/app/answers/de...rn-digital
It seems the dumps aren’t being created.
Have you adjusted the page file size? That could be a contributing factor.
The drive where the page file is stored might be the issue—another possibility...
Recreating the page file could resolve the problem.
Navigate to settings/system/about, then click Device specifications, select Advanced System settings, choose Performance, click Settings, then Advanced tab.
Under Virtual memory, click Change...
Uncheck automatically manage paging file for all drives.
Click OK, then apply and restart your PC.
After restarting, repeat these steps until the automatic management option is enabled again for all drives.
So I installed the utility, I was already comfortable with it but hadn't used it recently. Both SSDs had the newest firmware, and I performed both short and long S.M.A.R.T tests on my C: drive, which showed no issues.
I also followed the steps to recreate the page file, selected the top box "automatically manage all drives," unchecked it, chose no paging file, clicked set, restarted, and then restarted again.
It caught my notice that when I disabled the paging file option, it displayed "Total paging file size for all drives: 0mb." However, when I re-enabled it, the size remained unchanged at 1792MB, suggesting it wasn't recreating a new one but using the existing one.
After completing all these steps, I ran another BSOD, and the PC restarted automatically. When I checked C:\Windows for the Minidump folder, I found the same result—no folder, event ID 161 in Event Viewer: "Dump file creation failed due to error during dump creation."
I'm still puzzled about this situation.
To successfully capture dump files all the required conditions need to be met.
The page file should reside on the same drive as your operating system.
It must be configured as "system managed."
System crash/recovery options should be set to "Automatic memory dump."
Any existing file box must be checked.
The dump file path must match %SystemRoot%\MEMORY.DMP.
Windows Error Reporting (WER) service should be in MANUAL mode.
User account control must be active.
Other factors that might block dumps include:
SSD drives with outdated firmware do not generate dumps (update the drive firmware).
Cleaner programs such as Ccleaner can remove dump files—avoid running them until resolved.
Faulty RAM may stop data from being saved to a file upon restart, so test your RAM if necessary.
Or it might have been made just to match the required size.
Ubuysa understands BSOD better than I do; if we manage to generate dumps, we could make progress.
1. We simply recreated the page file without making changes.
2. Yes, it is... and it was.
3. I believe he followed my minidump instructions, which is a link for 10, but I think it still functions in 11:
https://www.tenforums.com/tutorials/5560...-bsod.html
4. Where should we adjust this?
5. The folder where the minidump is stored is similar, just in a different location.
Windows Error Reporting – To locate it, right-click Start, select Run..., type services.msc and press Enter, scroll to the bottom to find Windows Error Reporting, then check its startup type.
UAC – https://learn.microsoft.com/en-us/mem/in...ac-windows
1. We just verified that.
2. Good idea, I didn’t consider CCleaner.
3. Consider running memtest86 on each RAM stick individually, one at a time, up to four passes. Only zero errors should be recorded; any higher indicates a possible cause for the BSOD. Replace or remove RAM sticks with errors. The memtest is designed as a bootable USB so you don’t need Windows to execute it.
Did you reinstall CMOS after swapping the CPU? It can sometimes assist, particularly if the RAM still retains timing settings from the previous processor.
Items 3, 4 and 5 all occur in the same conversation (Start-up and Recovery).
Minidumps are pulled from the complete memory dump (in the paging file) and consistently end up at C:\Windows\Minidump, this location is where a kernel dump will be saved. Occasionally we require kernel dumps, so it's important to understand their destination.
I verified the first seven points as you described; the only missing item was UAC, which I had disabled previously. However, it didn’t affect the outcome. The same issue is occurring in Event Viewer, where it’s failing to create a dump without a clear reason—just an error message saying "Dump file creation failed due to error during dump creation."
We confirmed the firmware on the SSD, as Colif mentioned. I also don’t use any cleaning software; I learned some time ago to avoid such applications. In a previous post, I mentioned running a full memtest86 lasting about four hours and thirteen passes with no problems. I’ll try it again and let you know the results!
I reset the CMOS after swapping CPUs because I had an undervolt setting with the 5800X. I thought it was best to completely wipe the CMOS when changing hardware, as with the 5600G I’m not running any undervolt or overclocked settings. The BIOS currently has its default configurations.
Regarding the RAM test, please correct me if I’m wrong. A faster way to rule out a RAM problem would be to run memtest86 on a single 8GB stick in one slot, and then see if the system boots normally when using Sleep mode.