KERNEL_SECURITY_CHECK_FAILURE is bug check 0x139. The Windows kernel found one of its own critical data structures corrupted and halted the machine on purpose rather than carry on. A faulty or outdated driver causes most cases, particularly after a Windows feature update.
The name misleads people. It has nothing to do with antivirus, Secure Boot or an attack on your PC. It refers to the integrity checks the kernel runs on its own bookkeeping.
What the kernel actually caught
Microsoft’s reference for bug check 0x00000139 describes it as the kernel detecting the corruption of a critical data structure. The first parameter records which check failed: a stack buffer overrun, an invalid parameter passed to a function that treats bad input as fatal, a corrupted linked list.
The stop code names a symptom, not a culprit. Something wrote where it should not have and the kernel noticed afterwards, so working out what did the writing is the whole job. If you are seeing several different blue screens on one machine, the overview of every Windows stop code and what it means is a faster way to spot the pattern.
Work out which situation you are in
Match your case to a row and start there.
| When it started | Most likely cause | Start with |
|---|---|---|
| Days after a Windows feature update | Old driver carried over from the previous build | Fix 2 |
| Right after installing a driver, GPU, VPN or antivirus | That driver | Fix 1 |
| After adding RAM, or with XMP/EXPO enabled | Memory instability | Fix 4 |
| Random, plus slow file access or disk noise | Disk or file system errors | Fix 3 |
| Only during games or heavy load | Memory, power or thermals | Fix 4 |
| Every boot, before you reach the desktop | Any of the above | The recovery section |
Read the crash first
Three places hold evidence.
The blue screen. Some 0x139 crashes print a What failed: line naming a .sys file. Photograph it, because that one line often ends the investigation. There is more on reading these screens in the guide to a Windows Start button that stops responding.
Event Viewer. Press Win + R, type eventvwr.msc and open Windows Logs → System. Microsoft’s advice for this bug check is to look for critical errors in the same time window as the blue screen, and to check Device Manager for any device flagged with an exclamation mark.
Minidumps. Windows writes one per crash to C:WindowsMinidump. The timestamps alone tell you how often this happens and whether it clusters around one activity. Reliability Monitor shows the same as a timeline:
perfmon /relFix 1: roll back or remove the driver that changed
If a driver went in shortly before the crashes began, reverse that first. Open Device Manager, right-click the device, then Properties → Driver → Roll Back Driver. A greyed out button means Windows kept no previous package, so remove the current one instead.
From a Command Prompt opened with Run as administrator:
pnputil /enum-driversEach entry shows a published name in the form oem12.inf, the original filename, the provider and the driver date. To remove a package and detach it from the devices using it:
pnputil /delete-driver oem12.inf /uninstallGet the replacement from the hardware manufacturer or Windows Update. Third-party “driver updater” utilities are no shortcut: they match hardware IDs against generic databases and regularly install something newer but wrong for your model.
Fix 2: hunt the old driver a Windows upgrade left behind
This is the most common version of 0x139 and the one people miss. A feature update replaces the kernel but keeps your existing third-party drivers, so a driver built years ago now runs against a newer kernel. Low-level ones can mismanage exactly the sort of structure this bug check guards.
Run pnputil /enum-drivers again and read the Driver Version dates rather than the version numbers. Anything dated well before your Windows build deserves suspicion, especially these:
| Category | Typical examples |
|---|---|
| Storage controllers | Intel RST, old NVMe or RAID drivers |
| Network filter drivers | VPN clients, packet capture, bandwidth shapers |
| Virtual audio devices | Voice changers, virtual cables, old sound suites |
| Peripheral suites | RGB lighting, fan control, gaming mouse software |
| Security software | Antivirus and endpoint agents on old versions |
Uninstall the vendor’s software through Settings → Apps rather than deleting a .sys file by hand. Deleting driver files manually leaves a service pointing at nothing, which produces a machine that will not boot.
Fix 3: repair the system image and check the disk
Microsoft’s guidance is to run DISM before the System File Checker, because DISM supplies the clean files SFC then uses for repairs. As administrator:
DISM.exe /Online /Cleanup-image /Restorehealthsfc /scannowThen the disk. /f fixes logical errors and /r also locates bad sectors and recovers readable information:
chkdsk C: /f /rThe volume is in use, so Windows offers to run the check at the next restart. Say yes. Note the limit here: SFC only repairs protected Windows system files, never a third-party driver, so a clean result does not clear the driver theory.
Fix 4: test the memory properly
Bad RAM corrupts whatever sits at the wrong address, and the kernel’s integrity checks are often what catch it. Press Win + R, type mdsched.exe and let the built-in test run at reboot. A clean pass proves little, though. For a real answer, run MemTest86 from a USB stick overnight across several full passes. One error is a failure.
XMP and EXPO profiles are factory overclocks. A kit rated at its advertised speed is not guaranteed to reach it on your particular board and CPU, so set memory back to the JEDEC default in firmware and retest. If a test fails, retest with one stick installed at a time to find the bad module.
Fix 5: disable Fast Startup as a diagnostic
With Fast Startup enabled, shutting down does not fully shut down. Microsoft’s driver documentation explains that Windows saves the kernel memory image, including the loaded kernel-mode drivers, into Hiberfil.sys and reloads that file at the next boot instead of initialising everything from scratch. A driver that leaves a structure in a bad state is therefore restored in that bad state at every boot.
Turn it off under Control Panel → Hardware and Sound → Power Options → Choose what the power buttons do → Change settings that are currently unavailable, then untick Turn on fast startup (recommended).
This is a diagnostic, not a cure. If the crashes stop you have narrowed the fault, but you still have to find and replace the driver. Boots get slower, which is the trade.
Fix 6: Driver Verifier, only if you are stuck
Driver Verifier stress-tests drivers and crashes the machine deliberately the moment one breaks a rule. Microsoft is blunt about it: running Driver Verifier could cause the computer to crash, and it is meant for machines you use for testing and debugging. Make sure you can reach Safe Mode first, because that is where you will undo it.
Run verifier as administrator, choose standard settings, and select only non-Microsoft drivers. Any crash it produces names the offending driver in the dump. To switch it off:
verifier /resetIf it blue-screens before you reach the desktop
Interrupt the boot three times with the power button and Windows opens the recovery environment. Go to Troubleshoot → Advanced options → Startup Settings → Restart, then press 4 for Safe Mode. Uninstall the suspect driver or software from there, or use System Restore to return to a point before the change.
If the memory tests clean and the machine still crashes in Safe Mode, a clean reinstall of Windows becomes reasonable. Do it last. A reinstall on failing RAM buys you a fresh copy of the same crash.
Quick reference
| Symptom | Likely cause | Action |
|---|---|---|
Blue screen names a .sys file | That driver | Roll back or remove the package |
| Started after a feature update | Legacy driver, new kernel | pnputil /enum-drivers, check dates |
| Random crashes, XMP enabled | Memory instability | Disable XMP, run MemTest86 |
| Crashes only at boot | Kernel image restored at startup | Disable Fast Startup, retest |
| Slow disk, other file errors | Disk or file system | chkdsk C: /f /r |
| Nothing correlates | Unknown driver | Driver Verifier, standard settings |
Common questions
Is KERNEL_SECURITY_CHECK_FAILURE caused by a virus?
Rarely. The name refers to the kernel’s checks on its own data structures, not to security software or an attack. Microsoft documents it as corruption of a critical kernel data structure, usually from a driver. Malware can trigger it, so a full scan is worth running, but check drivers first.
Does this stop code mean my RAM is failing?
Sometimes. Faulty memory corrupts kernel data structures and produces bug check 0x139, but drivers cause far more cases. If the crashes are random rather than tied to one activity, or you run an XMP or EXPO memory profile, test the RAM properly before buying replacement parts.
Can I fix it without reinstalling Windows?
Usually yes. Most cases trace to a single driver, and rolling it back or deleting its package resolves them. Reinstalling only helps when the Windows image itself is damaged, and it will not help at all if the real fault is failing memory or a dying drive.
Why did it start right after a Windows update?
Feature updates replace the kernel but keep your existing third-party drivers. A driver written for an older Windows build can behave badly against the newer kernel, which is exactly what this bug check catches. Check the driver store for storage, network and audio drivers dated years before the upgrade.
Is it safe to keep using the PC while I troubleshoot?
For light use, yes, but back up your files first. Every blue screen is an unclean shutdown, and repeated unclean shutdowns risk file system damage on top of the original fault. If the machine crashes within minutes of booting, copy your data off in Safe Mode before going further.
Change one thing at a time and reboot between changes. This stop code has half a dozen plausible causes, and the only way to know which one you have is to leave everything else alone while you test each.
