Check for faulty cores that lead to game crashes on Intel 13th/14th generation systems
Check for faulty cores that lead to game crashes on Intel 13th/14th generation systems
To evaluate your 13th or 14th generation processor, run a stress test using Windows Subsystem for Linux and a Gentoo image. This process will individually test each p-core, which typically takes around an hour on a 14900k. You’ll notice the 'bad' cores failing quickly in practice.
Download the provided Gentoo stage3 image from the specified link. Launch PowerShell with admin rights, modify paths to match your Windows account.
Enable the necessary WSL features and install Gentoo. Once set up, use the command line to run the stress test on individual CPU pairs, adjusting the affinity settings to isolate performance issues. This helps determine whether the problem lies within a specific core or elsewhere in the system.
This topic seems connected to the idea of being isolated or hidden.
The challenge stems from pairing hyper-threading with high-boost frequencies. Adjusting motherboard power caps halts boosts during full-core tasks, while single-core work doesn’t overload both threads on the same core. The real issue arises when only two or three threads run simultaneously and end up sharing a p-core, which prevents the limits from functioning. This scenario occurs infrequently but can be triggered by prolonged testing sessions—possibly spanning several hours to expose a flaw. Running cores sequentially accelerates failure detection. The problem appears linked to "compiler-like" workloads, especially when compiling shaders for games. During this test, I employed bootstrapped GCC due to its intensive compilation process (about an hour) and the necessity of verifying compiler consistency twice. This approach also identifies subtle CPU errors that wouldn’t trigger a crash. I’m utilizing WSL2 with Gentoo, which bundles all required GCC tools in one package and simplifies setup compared to traditional environments like Visual Studio. A key advantage is the virtual machine environment, reducing the chance of Windows crashes or reboots.
It's not possible to intentionally cause crashes during compilation on Windows. However, using WSL2 can add complexity, so exploring a more straightforward approach for debugging would be helpful.
- you can gather everything required for testing at once. - you can remove the test setup with one command (wsl --unregister gentoo). - if it crashes, it usually stops the VM, preventing a hard crash of Windows or BSOD and avoiding a reboot. Setting up Visual Studio might be more complicated just to run a test, and MingGW/Cygwin also seems to require more effort.
Additional checks reveal that simply evaluating individual p-cores with two hyper-threads and then aggregating them isn’t sufficient for stability verification. It appears you should evaluate in sets of four as well. For instance: MAKEOPTS="-j9" taskset -c 0-7 emerge -1 gcc MAKEOPTS="-j9" taskset -c 8-15 emerge -1 gcc To assess the first four p-cores and the final four in a four-core group. If a complete multi-core workload generates roughly 400W with no power caps, then four p-cores each handling two threads would consume about 200W, staying below the 253W threshold, meaning power restrictions won’t prevent them from overheating under load.