Repost from Reddit. These are things I found out:
- RAM profile settings have no effect. I'm waiting for thermal paste to test CPU voltage and frequency adjustment as a solution.
- 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.
- Epic Game Store app causes even more BSODs. Almost no problems with Steam.
- Neither SFC, CHKDSK, nor DISM solves any problems. This is also not a RAM problem at all. Clean OS install doesn't solve it.
- Switching power profile in Windows power settings from AMD balanced to Microsoft balanced makes the OS slightly more stable. Slightly.
- 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.
- 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...