Disabling C-states resolved the freezes... now what?
Disabling C-states resolved the freezes... now what?
System Specifications
CPU: Ryzen 3950x
Motherboard: TUF GAMING X570-PLUS (WI-FI)
Memory: 2x16GB G.Skill Trident Z Neo Series DDR4 3600
Storage:
- 1x Samsung 970 EVO Plus SSD 2TB
- 1x Samsung 980 SSD 500GB
GPU: GeForce GTX 1080 Ti
Power Supply: Corsair RMx Series RM850x
Operating System: Windows 10 on 2TB SSD, Linux Mint on 500GB SSD
- NO overclocking
Recent Troubles
Over the past few months, my system frequently freezes to a fixed screen, requiring a reset. This typically happens on the lock screen. When I disconnect and reconnect the monitors, the display fails to restart. I recently added a second SSD for Linux Mint installation. The issue appears across Windows, Linux, and even in the BIOS interface.
I can identify the freeze occurring around the clock display time, thanks to the ability to track the exact second. However, reviewing the system logs shows no relevant activity or data near the freezing moment.
Attempted Solutions Without Success:
- Updated BIOS
- Reinstalled and reverted GPU drivers
- Updated and upgraded DP firmware for the GPU
- Replaced GPU with new unit
- Reseated GPU
- Swapped PS cables to CPU
- Ran a full memory test (7 passes) with no errors
The only resolution was disabling C-States in the BIOS. After this change, the system has remained operational for over five days without issues or overheating.
Now I’m trying to understand the root cause and explore further steps to enhance stability. The hardware was assembled within the last 14 months; all components are new except the GPU, making an RMA a viable option if any part is defective.
Any guidance or assistance would be highly appreciated!
C-States represent the gradual reductions during idle periods, functioning as sleep modes. C0 remains active, while C1 through C3 correspond to initial sleep phases, including features like the lock screen and screen savers where the CPU remains engaged but non-essential tasks are paused. C4 and C5 initiate a more comprehensive shutdown, halting nearly all operations except for essential functions such as Windows timers and further lowering voltage levels. C6 and above enter deep sleep, effectively suspending even timer functions.
The issue likely lies with the power supply unit, which can manage these voltage changes, whereas the real cause is probably a software conflict—programs attempting to run but failing, leading to an infinite loop that locks the system. Malware may be responsible, as dormant entries periodically check for malware presence; removal or deletion triggers a refresh download or installation process.
The most challenging part is identifying the problematic code. You must disable services, allow the PC to enter sleep, attempt to resume operation, and repeat this for any additional programs that auto-start, such as added lock screens, update scripts, or driver updaters.
Oh man, this sounds like it’ll be absolute hell to debug! Do you have any recommendations on how to handle it?
Begin with a solid malware scan. A virus check would be beneficial as well. Next, examine the list of programs you've installed. Certain applications such as Adobe, Photoshop, or Java are generally safe. You should focus on less common options, like driver updaters. Then execute ccleaner and its built-in registration tool using default settings (opting to save a copy). Additionally, visit the Asus website to update the motherboard-specific drivers package.
OS is software. When you start the pc, you'll be running post and bios which has its own drivers etc that it needs in order to make the hardware work. Then the OS takes over, loads up the registry, sorts itself out as far as drivers, startup services, programs etc, go.
So Windows and Linux are seperate, have their own advanced drivers and procedures. But. That's just bios/OS. It's not any programs or drivers installed that operate under either OS. You'd need 2x seperate entirely installations, so the windows does not see anything used by Linux and vice versa. Like haveing 2 seperate installs of Adobe, not 1 installed Adobe used by either.
As long as there is any shared programming, what affects one install can affect the other. Also Windows and Linux (or any of its Distros) are different. It's not uncommon for software or hardware to run butter smooth in Linux and run like 80grit sandpaper in windows, or vice versa.
I’m curious about how the freezing appears in both OSes. As you mentioned, Windows doesn’t detect anything used by Linux, and vice versa. So a bug on Windows shouldn’t cause freezing on Linux, and vice versa. Does this pattern suggest the problem is likely hardware-related, or am I misunderstanding?
Run a test by unplugging one SSD data cord and letting the remaining OS load on its own. Observe if it freezes. Repeat the process in reverse. This will help identify if the issue is common across both, such as a shared library, program, or driver that isn't fully compatible. Also check the Event History and critical errors for any missing or problematic entries.