A full log of how we tracked down universal 0xc0000005 access-violation crashes across totally unrelated games to Intel’s “Vmin Shift Instability” on an i9-14900HX — and the two settings that stopped it.
Laptop: ASUS ROG Strix SCAR 16 (G634JZR)
CPU: Intel Core i9-14900HX
GPU: RTX 4080
BIOS: G634JZR.322
OS: Windows 11, build 26200
The short version
Cap CPU power in ThrottleStop. TPL screen → Long Power PL1 clamp = 80, Short Power PL2 clamp = 100 (watts), Disable Controls stays checked → Apply → OK → Turn On → Save.
Disable CPU boost in Windows power settings. Admin Command Prompt:
powercfg /setacvalueindex SCHEME_CURRENT SUB_PROCESSOR PERFBOOSTMODE 0
powercfg /setdcvalueindex SCHEME_CURRENT SUB_PROCESSOR PERFBOOSTMODE 0
powercfg /setactive SCHEME_CURRENT
This is a workaround, not a repair — see the last section before you assume you’re done.
The symptom
Games started crashing with exception code 0xc0000005 (STATUS_ACCESS_VIOLATION) — first occasionally, then constantly, eventually on launch. The tell that this wasn’t a game problem: it hit completely unrelated engines with nothing in common except the hardware underneath them.
Game Engine / faulting module Exception
Vampire Survivors UnityPlayer.dll (Unity) 0xc0000005
Intravenous 2 lua51.dll (embedded Lua 5.1) 0xc0000005
Pathogenic pathogenic.exe 0xc0000005
OCCT (stress test) — crashed, then full kernel BSOD Bugcheck 0x3B, code 0xc0000005
Alongside the game crashes, unrelated core Windows processes started dying at random: Task Manager, Desktop Window Manager, the Antimalware Service, LockApp — 78 critical events logged in Reliability Monitor in a single day, after weeks of a completely clean history.
Not every crash here is the same bug
One title, Zero Sievert, was also crashing constantly — but with a different code, 0x80000003 (STATUS_BREAKPOINT), which is a known engine-level bug in that game’s GameMaker Studio 2 runtime, unrelated to this issue. If your crash code doesn’t say c0000005, this writeup probably isn’t your fix.
What we ruled out first
Before landing on the real cause, we spent real time eliminating the usual suspects. If you’re mid-diagnosis yourself, here’s what didn’t matter in this case:
RAM tested clean across multiple full passes (MemTest86)
WHEA-Logger
in Event Viewer was empty — though note this only reports what the CPU itself flags, and non-ECC laptop RAM can’t self-report errors, so this doesn’t clear RAM on its own
GPU driver was already the latest version
BIOS was already the latest version
Steam file integrity verified on every affected game
Shader cache cleared and rebuilt repeatedly
All overlays (Discord, GeForce, RTSS) disabled
Windows Memory Integrity / Core Isolation toggled off
Malware scans clean
What eventually broke the case open was watching live sensor data during a crash, not another round of file/driver checks.
The actual cause: Vmin Shift Instability
This CPU is a mobile Raptor Lake Refresh part — the same silicon family behind Intel’s well-publicized 13th/14th-gen desktop crashing saga. The mechanism is called Vmin Shift Instability: sustained operation at elevated voltage physically degrades the silicon over time, so the chip needs progressively more voltage to compute correctly than it’s actually being given — producing exactly this kind of random, spreading memory corruption under load.
Intel’s official position is that mobile chips like the 14900HX “are not exposed to the same issue” as desktop 13900K/14900K parts. A case on Intel’s own community forum, involving the same i9-14900HX, directly contradicts that — same clean RAM/driver/BIOS results, same progressively-worsening crash pattern, resolved the same way described below.
How to confirm it on your own machine
Install ThrottleStop (run it as Administrator) and watch the VID reading on the main screen while gaming or during a light CPU load. Ours climbed into a range Intel itself treats as a danger zone, with PROCHOT (thermal/power throttle) lit the entire time.
VID observed
1.4387 – 1.4868 V
Temp during spikes
95 – 98 °C
Intel danger threshold
~1.55 V
After fix applied
stable
1.4868V observed
danger zone (1.4–1.55V)
1.0V
1.6V
Peak VID measured on this system, plotted against the danger band cited by Intel and by other affected 14900HX owners.
The fix, step by step
1 — Cap CPU power with ThrottleStop
Lowering the power ceiling forces lower clocks, which forces lower voltage — the actual thing damaging the chip.
- Download ThrottleStop, right-click it → Run as administrator (required — its power-limit controls silently fail without elevation).
- Click TPL (bottom row of the main window).
- Next to Long Power PL1, set the Clamp value to 80.
- Next to Short Power PL2, check its Clamp box and set the value to 100.
- Leave Disable Controls checked — this is what lets the clamp actually override the stock 175W limit.
- Click Apply, then OK. On the main window: Turn On, then Save so it reapplies on every launch.
Keep it running
ThrottleStop has to stay open (minimized is fine) for the cap to hold. Closing it removes the limit.
2 — Disable CPU boost in Windows power settings
“Processor performance boost mode” is hidden from the Power Options UI by default on current Windows builds. Set it directly from an elevated Command Prompt instead of hunting for it in Control Panel:
powercfg /setacvalueindex SCHEME_CURRENT SUB_PROCESSOR PERFBOOSTMODE 0
powercfg /setdcvalueindex SCHEME_CURRENT SUB_PROCESSOR PERFBOOSTMODE 0
powercfg /setactive SCHEME_CURRENT
0 = Disabled. No restart required — test a game immediately after running these.
Result
sfc /scannow, which had previously failed partway through with “Windows Resource Protection could not perform the requested operation,” completed cleanly end to end after both changes. Every previously-affected game ran through extended sessions with no crashes.
Diagnostic log
For anyone comparing notes on a similar case, here’s the actual sequence, in order:
Day 1
Battery report shows brief, unexplained switches from AC to battery mid-session, draining at ~90–100W in under 15 minutes each — laptop working overtime to supply power gaming draws.
Day 1, evening
Reliability Monitor logs 78 critical events in one day (previously flat for weeks): OCCT stress test fails repeatedly, Task Manager and Desktop Window Manager crash, then a full kernel BSOD — bugcheck 0x3B (SYSTEM_SERVICE_EXCEPTION) carrying the same 0xc0000005 code as the game crashes.
Day 2
New, never-before-installed games crash identically on first launch — ruling out per-game save/cache corruption. Three unrelated engines (Unity, a Lua-scripted custom engine, GameMaker) all fail the same way.
Day 2
sfc /scannow fails at 39%; DISM /RestoreHealth hangs; DISM /ScanHealth fails with Error 1726 / RPC failure. The CBS log shows the servicing worker process silently dying mid-scan — the same “process dies under sustained load” signature as everything else.
Day 2
Live ThrottleStop monitoring during normal use shows VID climbing to 1.4868V with PROCHOT active at 96–98°C — independently matching a documented Intel Vmin Shift case on the same CPU.
Day 2, resolved
ThrottleStop PL1/PL2 cap + Processor Performance Boost Mode disabled. sfc /scannow completes cleanly; longest crash-free session since the issue began.
This is a workaround, not a repair
Capping power and disabling boost reduces the voltage enough to avoid triggering the fault — it does not undo the degradation already in the silicon. This CPU is soldered to the motherboard, so there’s no user-serviceable swap the way there is on a desktop.
If your laptop is still under warranty, the practical next step is a support ticket with your OEM (not Intel directly), citing:
The exact CPU model and the term “Vmin Shift Instability”
Intel’s own published advisory on the issue (linked below)
Live VID/PROCHOT readings if you can capture your own — a screenshot of ThrottleStop mid-crash is hard to argue with
Sources
Vmin Shift Instability Issue — Two Affected Systems (i9-14900HX & Core 9 270H) — Intel Community
Intel® Core™ 13th and 14th Gen Desktop Processor Vmin Shift Instability Issue – Latest Information — Intel official advisory
Intel 13th/14th Gen CPU Instability: 0x12F and RMA Guide