Access violations across three unrelated game engines traced to one degrading i9-14900HX

This failure class gets misfiled as software because of the exception code. 0xc0000005 is STATUS_ACCESS_VIOLATION, the fault a process takes when it touches memory it should not ^[2]. A pointer corrupted by the hardware faults the same way a pointer bug in source does. The dev.to log describes Vmin Shift Instability as sustained operation at elevated voltage physically degrading the silicon, so the chip needs progressively more voltage to compute correctly than it is being given, and the result is random, spreading memory corruption under load ^[8].

The distribution separates the two readings. On this machine the faulting modules were UnityPlayer.dll in Vampire Survivors, lua51.dll in Intravenous 2 and pathogenic.exe in Pathogenic, three binaries sharing nothing but the CPU beneath them ^[2]. Windows components went down with them: Task Manager, Desktop Window Manager, the Antimalware Service and LockApp ^[4]. OCCT crashed and then took the kernel with it, bugcheck 0x3B carrying the same 0xc0000005 code ^[3].

Intel's official position, as quoted in the writeup, is that mobile chips like the 14900HX "are not exposed to the same issue" as the desktop 13900K and 14900K ^[10]. The author answers that with a case on Intel's own community forum involving the same i9-14900HX, with the same clean RAM, driver and BIOS results, the same worsening crash pattern and the same resolution ^[11]. The part is mobile Raptor Lake Refresh, the silicon family behind the desktop crashing saga ^[9].

All of this telemetry comes from one machine. ThrottleStop showed VID between 1.4387 V and 1.4868 V, temperatures of 95 to 98 C, and PROCHOT lit the entire time ^[12]. The writeup cites roughly 1.55 V as Intel's danger threshold and plots a 1.4 to 1.55 V band ^[13]. The peak sat 0.0632 V under that threshold ^[1], inside the band, on a laptop that had stopped launching games ^[19]. For those numbers to mean anything on another machine you need the same conditions: a mobile 13th or 14th-gen part, a crash rate that climbs over weeks instead of arriving at once ^[19], VID in that band under light load, and an empty WHEA-Logger. WHEA reports only what the CPU itself flags, and non-ECC laptop RAM cannot report its own errors ^[7], so neither an empty log nor a clean MemTest86 pass clears the hardware ^[6].

Nothing in the mitigation touches voltage directly. Capping power forces lower clocks, and lower clocks force lower voltage, and voltage is what degrades the silicon ^[17]. The settings are PL1 at 80 W and PL2 at 100 W on ThrottleStop's TPL screen with Disable Controls left checked ^[14], leaving the short-window ceiling 25 percent above the sustained one ^[2]. Boost goes off through powercfg with PERFBOOSTMODE set to 0 ^[15]. Both the AC and DC value indexes are written and both target SCHEME_CURRENT, so the setting follows the active power plan and holds on battery ^[3]. VID was stable afterwards ^[18]. The writeup does not measure what the caps cost in throughput.

The author calls the result "a workaround, not a repair" ^[16]: the caps remove the condition that degrades the silicon, but nothing here recovers margin already lost ^[8]. One laptop and one forum thread do not establish how common this is across mobile Raptor Lake Refresh. What they give a fleet owner is a cheap discriminator, since reading VID under load takes a ThrottleStop install run as administrator and a few minutes of light CPU work ^[20].