Recurring ntoskrnl.exe crashes and BSODs on a new PC with random BugCheck causes and different drivers - help needed!

Still crashing after February 9, 2021—KB4601319 (OS Builds 19041.804 and 19042.804) update.

Later update: even more unstable than before

Repost from Reddit. These are things I found out:

1. RAM profile settings have no effect. I'm waiting for thermal paste to test CPU voltage and frequency adjustment as a solution.
2. The problem usually happens when watching movies via YouTube, or from HDD with MPC-HC. The only game that crashed the OS for me was Minecraft with metric ton of mods - it's both CPU and memory heavy. I played KSP 1.10.1 with metric ton of mods with no problems.
3. Epic Game Store app causes even more BSODs. Almost no problems with Steam.
4. Neither SFC, CHKDSK, nor DISM solves any problems. This is also not a RAM problem at all. Clean OS install doesn't solve it.
5. Switching power profile in Windows power settings from AMD balanced to Microsoft balanced makes the OS slightly more stable. Slightly.
6. The type/value of bugcheck error related to ntoskrnl, as far as I can tell, doesn't really matter. I did a bit debugging on the memory dumps Windows provides. It looks like ntoskrnl.exe messes up some data stored either in cache or in RAM. Usually some register data is missing from the dump. This data corruption happens on kernel level causing CPU/system to loose track of which program has which memory reserved, what interrupts are set up, and where code execution should go after tripping one or returning from Interrupt Service Routine, data structures get mangled. Dumps indicate that web browser is usually the victim, sometimes Steam app or EGS app, on rare occasions a driver gets chewed up too. I neither have skills nor source code to solve this problem.
7. The suggestion that locking CPU clock might fix it points to the way clock boosting is managed by OS. I think the problem is caused by the way OS is handling the clock change. I think it goes like this (it's my idea supported only by my imagination and knowledge developed while programming 8-bit microcontrollers):

• Kernel registers a need for some clock boosting or throttling back.
• Kernel sends command to the hardware. It doesn't stop normal code execution.
• Hardware changes the clock and VCore accordingly. This happens between two clock cycles.
• If this happens while CPU is fetching data between cache and RAM or between cache and registers, data gets sometimes mangled due to sudden voltage change.
• This causes execution of current opcode command to go wrong. CPU detects problem, throws an error and halts normal code execution. It switches to Kernel Interrupt Service Routine for that error.
• Kernel ISR can't recover from data mangling, throws a bugcheck error and dumps memory.
• On reboot the clock and voltage is reset.

Locking the clock causes hardware to ignore any clock change commands from Kernel. BIOS updates for some motheboards probably include a fix - hardware waits for completion of opcode command execution, locks the CPU, changes the clock and voltage, resumes. The way we do it with microcontrollers.

Mind you, this is only my theory, and I have no proof to support it.

For now the only solution is to lock the clock, update everything, including BIOS, and hope that M$ will fix their kernel-level software, as the solutions provided in firmware/drives provided by manufacturers are just workarounds for the root cause.

If anyone wants, I can provide more minidumps and memdumps I collected since reinstalling the OS...

Okay, switching power plan to the one with max performance worked, for now at least. No BSODs, no random freezes. It increases CPU clocks and adjusts voltages to provide performance, of course. But it also doesn't changes them back to eco mode, or at least changes them much less.

Other things that help:

1. When installing Nvidia GPU drivers, choosing advanced mode, "Clean install" and installing only graphics driver and PhysX driver decreases number of BSODs.
2. Clock locking works, and one can lock them at any frequency, not only base one. Temperature/cooling is the limiting factor. W10 can't mess up frequency switchover when it can't bypass BIOS/Chipset lock.
3. Changing CPU to different model might work for some. CPUs are not created equal, it's the nature of manufacturing process. The spread of parameters can be quite wide. Just google for "BC547 datasheet" (it's a common bipolar transistor) and check the "DC Voltage gain" parameter - it differs from unit to unit, despite the fact entire batch is made on a single silicon die the size of small plate. And CPU transistors are much, much smaller in size than this common single transistor.

I was considering a downgrade to Windows 7 too, as this issue is only on Win10, and I have licence for both.

I'll keep you informed.

Some people have the same problems with Intel CPUs. So I think the issue is platform-agnostic. I am sure it stems from the way Windows 10 changes clocks and voltages for CPU on the kernel level...

My system was stable for about 2,5 days. Then I've got another Windows Update and everything went downhill, to the point that I had 6 BSODs and crashes in 2 hours. Then I went and switched my power plan to max power one (don't know proper English name, as my OS is in Polish). No crashes since, still testing and waiting...