Fix KERNEL_SECURITY_CHECK_FAILURE Windows 11
Short answer first: KERNEL_SECURITY_CHECK_FAILURE, bug check 0x00000139, means Windows detected that a critical kernel data structure had been corrupted, and shut down before that corruption could spread or be exploited. In most of the dumps I've seen this in, the corruption traces back to a driver — a GPU driver, a kernel-level anti-cheat component, a security or backup filter, or occasionally a virtualization driver — not to malware and not, most of the time, to failing RAM. That last part surprises people, because "security check failure" sounds like an infection. It almost never is.
What the error actually means
Per Microsoft's bug check reference, 0x139 fires when the kernel's internal consistency checks catch damage to a data structure it relies on — commonly a corrupted doubly linked list (a LIST_ENTRY structure) or a failed Control Flow Guard (CFG) check. CFG is a security mitigation that verifies indirect function calls jump to a legitimate target; when it catches a call jumping somewhere it shouldn't, that's exactly the kind of thing this bugcheck exists to stop cold rather than let execute. The four bugcheck parameters identify which check failed and where, but pinning down which driver caused the corruption in the first place is genuinely hard even for someone reading the dump directly — Microsoft's own documentation admits this kind of corruption isn't always caught at the moment it happens, so you're often looking at the symptom a few steps downstream of the actual bug.
That's the honest complication with this bugcheck: it names where things broke, not always who broke them. Which is why the checks below matter more here than for most BSODs — you're building circumstantial evidence, not reading a smoking gun off the screen.
Symptom, check, and fix
| What you see | Confirming check | Fix |
|---|---|---|
| Crash names a GPU driver module (nvlddmkm.sys, amdkmdag.sys, igdkmd64.sys) | Check driver version against the vendor's current release; note if it changed recently | Clean reinstall with DDU, current version from the vendor, not Windows Update's |
| You play games with kernel-level anti-cheat (Vanguard, EAC, BattlEye) | Check whether crashes only happen while that specific game/anti-cheat is running | Update the anti-cheat via the game's own updater; check the vendor's known-issues page |
| Third-party antivirus, VPN, or backup software installed | Clean boot with Selective Startup to see if disabling it stops the crashes | Update it, or temporarily remove it to confirm before reinstalling current version |
| No specific driver named, crash is generic | Driver Verifier targeting non-Microsoft drivers to force a marginal one to surface | Update or remove whatever Verifier's resulting dump identifies |
| Started after adding or removing RAM, or after months of stability | Windows Memory Diagnostic in extended mode, or MemTest86 overnight | Reseat, isolate, and replace the failing stick if the diagnostic reports errors |
Myths and mistakes worth clearing up
"Security check failure" means I have malware
It doesn't, at least not directly. The name refers to the kernel's own internal integrity checks — Control Flow Guard and similar mitigations — catching corrupted data before it causes worse damage. It's Windows' security architecture doing its job, not evidence of an infection. Run a scan if you have reason to suspect one for other reasons, but don't treat this bugcheck alone as proof.
"It's always bad RAM"
Bad memory is a real, documented cause of this bugcheck, because corrupted RAM can scramble the exact kernel data structures CFG and linked-list checks are watching. But in the crash reports and dumps I've actually looked at, a driver is implicated more often than memory — GPU drivers and kernel-level anti-cheat especially. Test memory as one of your checks, not as the first assumption you act on.
"Reinstalling Windows will fix it for good"
A clean install often stops the crashes short-term because it removes whatever third-party driver or kernel-mode utility was causing the corruption. That's not the same as fixing the underlying cause. If you reinstall your usual software — including that same anti-cheat game or GPU driver version — without addressing the specific culprit, you're likely to see it return within weeks.
"Driver Verifier is dangerous, don't touch it"
It's a legitimate, Microsoft-built diagnostic tool, and it's specifically useful here because 0x139 dumps are hard to attribute without help. It will make your system crash more often while it's active — that's the point, it's forcing a marginal driver to fail faster so you get a name in the resulting dump. Set a System Restore point first, run it for a day or two targeting non-Microsoft drivers, and turn it back off once you have an answer:
verifier /standard /all
:: after reproducing the crash and reviewing the dump
verifier /resetIf Verifier makes the system crash before you can log in normally, boot into Safe Mode or the Windows Recovery Environment and run verifier /reset from an elevated Command Prompt there. This is expected behavior on a genuinely marginal driver, not a sign you broke something.
"If it only happens in one game, it's not a real system problem"
Kernel-level anti-cheat drivers (Vanguard, Easy Anti-Cheat, BattlEye) run with the same privilege as any other kernel-mode driver, and a bug in one of them produces exactly this bugcheck the same way a bad GPU driver does. If the crash only ever happens with one specific game running, check that game's own support channels and anti-cheat vendor pages for known issues before assuming it's your hardware. It's every bit as much a "real" cause as a GPU driver bug — it's just easy to dismiss because it's tied to a single application.
Fixing it, in order
Start with Windows Update, including optional driver updates, and check for a documented known-issue rollback if the crashes started right after a specific cumulative update — search that KB number on support.microsoft.com before doing anything manual. If a GPU driver is implicated, do a clean removal with Display Driver Uninstaller in Safe Mode, then install the current version straight from the vendor's site. If a specific game or anti-cheat is implicated, update through the game's own launcher rather than a generic driver update tool. If third-party antivirus or backup software is running, a clean boot will tell you quickly whether it's involved. Only after those checks come back clean should you reach for Driver Verifier to surface an unnamed driver, and only after that should you run Windows Memory Diagnostic or MemTest86 to check the hardware angle.
If everything above is clean and the crashes persist, the corruption may be tied to intermittently failing RAM that a single diagnostic pass didn't catch — run MemTest86 overnight rather than the faster Windows tool, since transient errors sometimes only appear after hours of sustained testing.
Where this points next
If you land on a GPU driver or anti-cheat component as the cause here, it's worth knowing that the same driver corruption family shows up under different bugcheck names depending on exactly what got corrupted and how — the same underlying bug can surface as 0x139 one time and a different stop code the next, since it depends on which check catches the damage first. If you're chasing recurring crashes that keep changing bugcheck codes but keep naming the same driver, that's a strong signal to stop treating each blue screen as a separate mystery and focus entirely on that one component.