What fails the security check
The kernel keeps checksums and invariants on its critical data structures, much like a bank reconciling its ledgers several times a second. Stop code 0x139 means one of those reconciliations came up wrong: a list pointer no longer points where it must, or a buffer's header no longer matches its contents. Windows stops deliberately at that point, because continuing with corrupted kernel state risks writing garbage across the disk.
What corrupts those structures is rarely mysterious. Memory that returns flipped bits under load — often an XMP or EXPO profile running past what the memory controller truly holds — is the leading cause. Drivers that write outside their buffers come second, GPU and antivirus drivers being the repeat offenders. Damaged system files and a failing SSD that serves corrupted reads fill out the list.
- Unstable RAM — XMP/EXPO profiles beyond what the CPU's memory controller really holds
- A buggy driver writing outside its buffer — GPU, antivirus and virtualization drivers are repeat offenders
- System files corrupted by a failed update or a sudden power cut
- A failing SSD returning corrupted data on read, visible in SMART attributes
- Aggressive undervolting or overclocking that flips bits under load
Testing memory and repairing files
Start with memory, because it is the most common cause and the cheapest to rule out. Launch mdsched.exe, restart when prompted and let the standard pass run; the verdict appears in Event Viewer under Windows Logs → System, from the source MemoryDiagnostics-Results. The standard pass catches only gross failures — so if crashes continue with clean results, disable XMP/EXPO in BIOS and test sticks one at a time before giving memory a clean bill.
Files come next, from an elevated Terminal: sfc /scannow verifies protected files against the component store, then DISM /Online /Cleanup-Image /RestoreHealth repairs the store itself if SFC could not fix everything, then chkdsk C: /f /r sweeps the disk surface at the next reboot. A GPU driver clean-reinstall rounds out the software side — download the latest package, remove the old one in Settings → Apps → Installed apps, and install fresh after a reboot.
Narrowing down a repeat offender
If the stop code survives all that, the crash is specific enough to name. The minidumps in C:\Windows\Minidump carry the failing address and the loaded-module list; WinDbg's !analyze -v command or a reader such as BlueScreenView turns them into a driver name, and that name ends the hunt. Software installed in the days before the crashes began deserves the first look — uninstalling it is both test and treatment.
The power tool of last resort is Driver Verifier (verifier /standard /all from an admin prompt), which makes suspicious drivers crash on their own bugs, loudly and immediately. It is deliberately dangerous: expect blue screens while it runs, and remember the exit — boot into Safe Mode and run verifier /reset to switch it off. Handled that way, Verifier flushes out a hiding driver within a day or two.
Questions and Answers
Is KERNEL_SECURITY_CHECK_FAILURE a sign of malware?
Rarely. The check catches corruption, not infection, and the causes are overwhelmingly hardware and drivers. A corrupting rootkit is possible but far down the list.
Can bad RAM cause KERNEL_SECURITY_CHECK_FAILURE?
Yes — it is the single most common cause. Run mdsched.exe, then disable XMP/EXPO and test sticks one at a time if crashes persist.
How do I stop KERNEL_SECURITY_CHECK_FAILURE at startup?
Boot into Safe Mode from WinRE (Startup Settings → press 4), uninstall whatever landed last, and run SFC and DISM from there — the crash rarely follows you in.
Know what is included before you buy.
The one-time 30-minute trial covers core tools. PRO-labelled features stay locked until a paid license is activated.
Read next
Write to us: [email protected]