How to Fix the KERNEL_SECURITY_CHECK_FAILURE Blue Screen on Windows 11

The KERNEL_SECURITY_CHECK_FAILURE stop code (bug check 0x00000139) fires when the Windows kernel detects that a critical data structure has been corrupted.

Microsoft's debugger documentation is blunt about what that means: a security check ran, the check failed, and the system halted because it could no longer trust its own memory. The corruption almost always comes from a misbehaving driver, failing RAM, or NTFS damage on the system disk. Below is a methodical path to the culprit instead of reinstalling Windows and hoping.

Key takeaways

• 0x139 is the kernel catching memory corruption in a protected structure (a common one is a KEVENT being double-initialized by a sloppy driver).
• A recently installed or updated driver is the single most frequent trigger, especially graphics, audio, and kernel-level anti-cheat.
• SFC and DISM repair the corrupt-system-file path; run them before touching hardware.
• If software repairs do not hold, suspect bad RAM or NTFS corruption on the boot drive.
• Reading the minidump in WinDbg turns guesswork into a named module.

The three causes, ranked

Almost every 0x139 traces to one of three roots. This is where to spend your time, in order:

Cause	How common	Tell-tale sign	Primary fix
Bad / updated driver	Most cases	Crash stops in Safe Mode; started after an update	Roll back or clean-reinstall driver
Corrupt system files	Common	SFC finds and repairs violations	SFC + DISM
Bad RAM	Less common	Random crashes, also in Safe Mode	MemTest86 overnight
NTFS / failing disk	Less common	SFC and DISM error out mid-run	chkdsk C: /f /r, then check SSD health

First: can you reach the desktop?

Your route depends on whether Windows boots.

• If the crash is intermittent and you can log in, work through the steps below normally.
• If you are stuck in a boot loop, force three failed boots to trigger the Automatic Repair environment (WinRE), then use Troubleshoot > Advanced options to reach Safe Mode, Command Prompt, and Startup Repair.

Step 1: Boot into Safe Mode

Safe Mode loads only Microsoft's signed core drivers. If the crashes stop there, a third-party driver or startup app is responsible.

1. From WinRE, choose Advanced options > Startup Settings > Restart.
2. Press 5 or F5 for Safe Mode with Networking.

A stable Safe Mode session strongly points at a driver rather than a CPU or motherboard fault.

The logic here is worth understanding because it shapes everything you do next. Safe Mode deliberately loads the bare minimum: Microsoft's own signed drivers and nothing third-party. If 0x139 stops appearing the moment you are in Safe Mode, you have just eliminated the two scariest possibilities, failing RAM and a dying disk, almost entirely, because those would corrupt memory regardless of which drivers are loaded. What is left is a third-party driver or a startup program, which is both the most common cause and the easiest to fix. Conversely, if the blue screen still fires in Safe Mode, you should pivot quickly to hardware testing rather than chasing drivers, because a crash that survives Safe Mode is telling you the problem is below the software layer. This single test, run early, can save you hours of updating drivers that were never the cause.

Step 2: Repair system files

Corrupt system files are a common, easily fixed cause. From an elevated Command Prompt:

sfc /scannow

If SFC reports it could not repair everything, fix the component store first, then re-run it:

dism /online /cleanup-image /restorehealth
sfc /scannow

If you reached this through the same NTFS-corruption symptoms others report, also schedule a disk check (covered in Step 5). The SFC/DISM pair is the backbone of most Windows repair workflows and also appears in our guide to the CRITICAL_PROCESS_DIED blue screen.

Step 3: Read the minidump to name the module

Let Windows tell you which driver corrupted memory instead of updating everything blindly.

1. Install WinDbg from the Microsoft Store (part of the Windows SDK debugging tools).
2. Open the newest dump in C:\Windows\Minidump\.
3. Run !analyze -v.
4. Read the MODULE_NAME and IMAGE_NAME lines. If the same driver appears across two or three dumps, you have your suspect.

Step 4: Update or roll back the offending driver

Armed with a module name, or a yellow warning icon in Device Manager:

• Update any flagged device. Prioritize graphics, storage, network, and chipset drivers, pulled from the hardware vendor rather than a third-party updater.
• If the BSODs began right after a driver update, open the device's Properties > Driver tab and click Roll Back Driver.
• Uninstall anything low-level installed around when the crashes started: overclocking utilities, RGB control apps, VPN clients, and games with kernel-mode anti-cheat are repeat offenders.

Step 5: Test memory and disk

If repairs and driver work do not stop the crashes, the corruption is physical.

• Run Windows Memory Diagnostic: press Win + R, type mdsched.exe, and choose to restart and test. For a thorough pass, run MemTest86 from a USB stick overnight. Any error means a failing module.
• Check the boot disk: run chkdsk C: /f /r from an elevated prompt (it schedules on the next reboot). Persistent NTFS corruption that SFC cannot clear often traces to a failing SSD.

Step 6: Undo a recent Windows update

A buggy quality update can introduce 0x139. Open Settings > Windows Update > Update history > Uninstall updates, remove the most recent update, and restart. From WinRE the same option lives under Advanced options > Uninstall Updates. If the timing lines up with the crashes, this often resolves it in one step. For broader update-failure troubleshooting, see our walkthrough on Windows 11 update error 0x80073712 and 0x800f0993.

Frequently asked questions

Does this error always mean my hardware is failing?

No. Most cases are software: a bad driver or corrupt system files, both fixable without opening the case. Hardware is the cause when the crash survives a clean SFC/DISM run, a driver review, and a Safe Mode test.

Can a game cause KERNEL_SECURITY_CHECK_FAILURE?

Yes. Titles with kernel-level anti-cheat install drivers that run at the highest privilege. If one of those drivers misbehaves, it can corrupt a kernel structure and trigger 0x139. Update or reinstall the game and its anti-cheat component.

Why do SFC and DISM say they cannot repair anything?

When the underlying problem is NTFS corruption or a failing disk, SFC and DISM may fail mid-run or report errors they cannot fix. Run chkdsk C: /f /r first, then re-run the repair commands.

Where are the crash dumps stored?

Minidumps default to C:\Windows\Minidump\, one .dmp per crash. A full kernel dump, if enabled, is C:\Windows\MEMORY.DMP. Open either in WinDbg and run !analyze -v.

What to do right now

If your PC is crashing on 0x139, run this in order and do not jump to a reinstall:

• Boot into Safe Mode with Networking; if it is stable there, the cause is almost certainly a driver.
• Run sfc /scannow, then dism /online /cleanup-image /restorehealth, then sfc /scannow again.
• Open the newest file in C:\Windows\Minidump\ with WinDbg and run !analyze -v to name the module.
• Update or roll back the named driver, prioritizing graphics, storage, network, and kernel-mode anti-cheat.
• If crashes persist, run MemTest86 from USB overnight and chkdsk C: /f /r to rule out bad RAM and a failing disk.
• Only after all that, consider uninstalling the most recent Windows quality update if the timing matches.

Quick recap

Confirm it is software by booting Safe Mode, repair files with SFC and DISM, then read a minidump in WinDbg to name the driver and update or roll it back. If crashes persist, test RAM with MemTest86 and the disk with chkdsk, the two physical causes behind a stubborn 0x139.