KERNEL_SECURITY_CHECK_FAILURE (bug check 0x139) means the Windows kernel checked one of its own critical data structures, found it corrupted and stopped the PC rather than keep running on damaged data. Despite the name, it’s usually not an attack. Most often it’s a buggy or incompatible kernel driver, occasionally bad memory.
The catch with this code is that the check fires when the damage is discovered, not when it happened. The module running at the moment of the crash can be an innocent bystander, so you identify the culprit by comparing several crashes, not just the last one.
Quickest split: if it started right after you installed or updated something that runs at kernel level (security software, a VPN, virtualization or hardware utilities), start there. If nothing changed and other stop codes are appearing too, test the RAM first.
Try these first
- Uninstall or update whatever was installed the day the crashes started (Reliability Monitor shows it).
- Remove third-party antivirus or VPN software with the vendor’s removal tool and retest; on a company-managed PC, ask whoever manages security first.
- Roll back a driver that just changed: Device Manager > Properties > Driver > Roll Back Driver.
- Turn off XMP/EXPO memory profiles or any overclock and see whether the crashes stop.
- Note Parameter 1 in Reliability Monitor’s crash details and look it up in the table below.
What bug check 0x139 actually means
Windows and modern drivers are built with integrity checks: stack cookies that detect buffer overruns, guards on linked lists, bounds checks on arrays. When one of these fails inside the kernel, Windows raises 0x139 immediately, because continuing on corrupted kernel data could cause worse damage or be exploited.
Bug check 0x139 parameter 1 tells you which check failed. You’ll find it as Parameter 1 in Reliability Monitor or Arg1 in WinDbg’s !analyze -v output; our blue screen of death guide shows both methods. Both show it in hex, while Microsoft’s table below uses decimal, so 10 appears as a and 14 as e.
| Parameter 1 | Check that failed | What it points to |
|---|---|---|
| 0 or 2 | Stack buffer overrun (/GS stack cookie) | A driver wrote past the end of a buffer. Update or remove the module in the dump. |
| 1 | Illegal virtual function table (VTGuard) | A corrupted object inside a driver. |
| 3 | Corrupted LIST_ENTRY, such as an item removed twice | A driver mishandled a linked list, timer or event. The culprit may not be the module on screen. This is the case Microsoft documents in most detail. |
| 5 | Invalid parameter passed to a function that treats it as fatal | A driver bug. |
| 6 | Stack security cookie never initialized by the loader | A driver that doesn’t match the running Windows version. Microsoft’s example is a driver built only for a newer Windows release loaded on an older one, rare on a current build. Update or remove the module in the dump. |
| 8 | Array bounds check failed | A driver indexed outside an array. |
14 (shown as e) | Invalid object reference count | A reference-counting bug in a driver, typically releasing an object more times than it acquired it. |
| Any other value | Less common checks, such as 10, shown as a (indirect call guard) | Microsoft’s 0x139 reference (see Sources) lists them all. The approach is the same: find the third-party module in the dumps. |
Every one of these is a defect in kernel code, which is why the fix is about finding and replacing a driver, unless faulty or overclocked memory corrupted the structures these checks protect.
Why the driver named in the crash may be innocent
With parameter 1 = 3, the corruption is caught the next time Windows adds or removes an item from the damaged list, which can be long after the faulty driver did the damage. Microsoft describes the typical scenarios: a driver frees memory that still sits on a list, initializes a synchronization event twice while another thread is waiting on it, or corrupts a periodic timer. In the event and timer cases, the crash typically fires inside Windows’ own code, in functions starting with nt!Ke or nt!Ki.
So don’t stop at IMAGE_NAME. Collect three or more dumps from C:\Windows\Minidump and compare them:
- A third-party module appears in every STACK_TEXT, even when the blamed module differs: that’s your lead.
- Every dump blames
ntoskrnl.exein timer or event functions: a driver is corrupting kernel objects, and Driver Verifier (below) is the tool to catch it. - Dumps show unrelated modules and other stop codes appear too: test memory before anything else.
For each suspect, lmvm plus the module name shows the file’s path and timestamp (and its version when the dump includes it), which usually tells you which product installed it.
Common causes and how to confirm each
| Situation | Likely cause | How to confirm | Fix |
|---|---|---|---|
| Started after installing or updating security, VPN, backup or virtualization software | That product’s kernel filter or network driver | Its driver appears in the dumps; crashes stop in Safe Mode | Update to a version that supports your Windows build, or remove it with the vendor’s cleanup tool |
| Started when Memory integrity was turned on (by you, an update or policy) | A driver that isn’t compatible with memory integrity | Windows Security > Device security > Core isolation details shows it on, and crashes began the same day | Update or remove that driver rather than leaving Memory integrity off; on a managed PC, the admin controls the policy |
| Crashes during games, or on a PC with RGB lighting, fan-control or tuning software | Anti-cheat, RGB, fan-control or tuning tools, many of which load kernel drivers | Their driver shows in the dumps; crashes stop after uninstalling the tool | Update or uninstall the tool, and set any CPU or GPU tuning it applied back to default |
| Started after a Windows feature update | A driver or utility that doesn’t support the new build | lmvm shows a third-party driver dated well before the update | Install the PC maker’s current driver; remove software the vendor no longer supports |
| Software was uninstalled but crashes continue | A leftover driver still loading at boot | Listed by pnputil /enum-drivers or Autoruns with no matching program | Remove the orphaned package (next section) |
| Crashes only with a dock, USB device or adapter connected | That device’s driver | A day without the device is crash-free | Update the device’s driver and firmware |
| Random timing, different modules, other stop codes | Faulty RAM or unstable memory settings | Memory test errors, or crashes stop with XMP/EXPO off | Run memory at default settings; replace the failing module |
Security software deserves extra attention: its kernel drivers hook into file, network and process activity, and uninstalling it from Settings can leave them behind, so use the vendor’s removal tool. On a home PC, Microsoft Defender Antivirus should switch back on by itself once the product is gone; confirm it under Windows Security > Virus & threat protection so the PC isn’t left unprotected.
On a company-managed PC, don’t strip out the security agent yourself. Business endpoint products often have tamper protection, so removal needs a token or policy change from whoever runs the security console. If several PCs started crashing after the same agent update, fix it once for the whole office. If your business needs a managed replacement, see our endpoint protection service.
If 0x139 crashes Windows at startup
If 0x139 hits before or just after sign-in, you can still remove the driver from outside Windows. Interrupt startup twice to reach the recovery environment, then open Troubleshoot > Advanced options:
- Startup Settings > Restart, then press 4 for Safe Mode. If it stays up, uninstall the most recent security, VPN or utility software, or roll back the driver that changed.
- Uninstall Updates or System Restore, if the crashes began the day of an update or a driver install.
- Command Prompt, if Safe Mode crashes too: disk encryption and some security drivers load even in Safe Mode, so remove the driver offline.
Remove a driver package offline
The Windows drive often has a different letter here, so run dir D:\Windows, then try C: and E:, until you find it. If it’s encrypted and won’t open, add your 48-digit recovery key, dashes included, to the end of manage-bde -unlock D: -RecoveryPassword.
- Run
dism /Image:D:\ /Get-Drivers. By default it lists only third-party packages, with published name (oemNN.inf), original file name, provider and date. - Match the provider or file name to the product you suspect.
- Run
dism /Image:D:\ /Remove-Driver /Driver:oemNN.infwith that published name, close the window and choose Continue.
Microsoft warns that removing a boot-critical driver package can leave Windows unable to start, so leave storage controller, chipset and disk encryption packages alone. If the suspect isn’t listed, it was probably installed as a service rather than a driver package; use System Restore or get help rather than editing the offline registry. If the PC keeps landing on the repair screen instead, use our automatic repair loop guide.
Rather have a technician sort it out?
With your approval, a technician can review your crash dumps remotely, trace parameter 1 and the faulting module to the software behind it, and update or remove that driver while you watch. A GoProIT technician can connect remotely, with your permission, and fix it while you watch. $59 per fix, Mon–Fri 8am–8pm ET.
Clean out old and orphaned kernel drivers
PCs that have been through several Windows upgrades often carry drivers from software that’s long gone. Three ways to find them:
- Core isolation. In Windows Security > Device security > Core isolation details, if Memory integrity can’t be turned on, Windows lists the incompatible drivers blocking it. Old drivers on that list are good suspects.
- pnputil.
pnputil /enum-driversin an administrator terminal lists every third-party driver package with its published name (oemNN.inf), original file name, provider and date. - Autoruns from Microsoft Sysinternals (download it only from Microsoft). Its Drivers tab lists the drivers set to load, and the Options menu can hide Microsoft and Windows entries so third-party ones stand out. Unticking an entry disables it and can be undone, unlike deleting it, but leave storage, chipset and disk encryption drivers ticked: Windows may not start without them, and then you can’t undo the change from inside Windows.
To remove a package you’ve positively identified, run pnputil /delete-driver oemNN.inf /uninstall with the real file name. Create a restore point first, and never remove storage controller, chipset or disk encryption drivers this way: Windows may not start without them.
Use Driver Verifier when the dumps don’t agree
When dumps keep blaming Windows’ own timer and event code, Microsoft notes that Driver Verifier with Special Pool can sometimes catch the culprit, when the corrupted object sits in memory a driver has already freed. Standard settings include Special Pool. Microsoft advises against verifying many drivers at once with Special Pool, so select one or a few third-party suspects.
Driver Verifier crashes the PC on purpose when it finds a fault, and Microsoft says to run it only on computers used for testing and debugging. On a work PC, back up first, have your BitLocker recovery key, runverifier /bootmode resetonbootfailso it switches itself off if Windows can’t start, and know how to reach Safe Mode so you can runverifier /resetthere. Our blue screen of death guide, linked above, has the full Driver Verifier steps.
A crash caught this way usually names the driver, under a different stop code such as DRIVER_VERIFIER_DETECTED_VIOLATION (0xC4), PAGE_FAULT_IN_FREED_SPECIAL_POOL (0xCC) or DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL (0xD5). Remove or update that driver, then run verifier /reset and restart.
Memory and firmware checks
Do these when dumps point in different directions, or when other stop codes show up alongside 0x139:
- Load default memory settings: turn off XMP or EXPO profiles and any CPU or memory overclock in the BIOS/UEFI setup.
- Run Windows Memory Diagnostic (
mdsched.exe) with the Extended test mix, which can take hours; any error means a bad module or slot. Our memory management blue screen guide covers the settings, testing one module at a time and why a clean pass isn’t proof. - Update the BIOS from the PC maker’s support site. Keep a laptop on AC power and don’t restart or power off during the update: an interrupted firmware update can leave the PC unable to start. Suspend BitLocker first so the update doesn’t trigger a recovery prompt, have the key ready from your BitLocker recovery key location, and confirm BitLocker protection is back on afterward.
When it’s hardware, and when to stop
When 0x139 is hardware-related, it’s usually memory, or a memory or CPU overclock that isn’t stable. Treat it as hardware when:
- A memory test reports any error, or the crashes stop only when a particular module is removed.
- Crashes continue in Safe Mode and none of the dumps shows a third-party module. Disk encryption and some security drivers still load in Safe Mode, so a Safe Mode crash with one of them in the stack is still a software problem.
- A clean Windows install with no extra software still crashes.
Stop and get help if the crashes prevent you from backing up, or if the suspect driver belongs to disk encryption or storage software, where a wrong removal can leave the PC unable to start. If the cause is a software driver rather than failing memory, and Windows stays up long enough to connect, this is a typical $59 remote fix: with your approval, a technician reviews the dumps, tracks down the driver and updates or removes it while you watch. Failing RAM has to be replaced in person. Here’s how remote support works.
Common questions
Is kernel security check failure a virus or a hack?
Usually not. The name refers to the kernel’s own integrity checks, not to antivirus. A check fails because a driver corrupted a kernel data structure, usually through a bug. Malware that installs kernel drivers can trigger it, and Microsoft’s own troubleshooting steps include a virus scan, so run a full Microsoft Defender scan, but start with recently installed or updated drivers and the module named in the crash dumps.
Can bad RAM cause kernel security check failure?
Yes, though less often than a driver. Faulty memory or an unstable XMP/EXPO profile can flip bits in the very structures these checks protect. The giveaway is inconsistency: different modules in each dump, and other stop codes such as MEMORY_MANAGEMENT or IRQL_NOT_LESS_OR_EQUAL mixed in. Set memory back to default speeds and run an extended memory test.
Why did kernel security check failure start after a Windows update?
A feature update replaces the kernel but keeps your third-party drivers, and a driver that ran fine on the old build can fail the new build’s checks. Look in the dumps for a security, VPN, virtualization or hardware-utility driver dated well before the update, then update it to a version that supports your build or remove it. For 10 days after a feature update, Settings > System > Recovery > Go back is also an option.
What do I do if kernel security check failure happens at startup?
Let Windows reach the recovery environment, or force it by interrupting startup twice. Choose Troubleshoot, Advanced options, Startup Settings, Restart, then press 4 or F4 for Safe Mode. In Safe Mode, uninstall recently added security, VPN or utility software and roll back recent drivers. If Safe Mode also crashes, try Uninstall Updates or System Restore from the same menu, or remove the driver package offline with DISM.
Will SFC, DISM or chkdsk fix kernel security check failure?
Usually not. SFC and DISM repair Microsoft’s own system files and component store, and chkdsk repairs the file system, while 0x139 is usually a third-party driver or a memory fault that none of them touch. They are still worth running when the dumps name a Microsoft driver other than ntoskrnl.exe, when crashes began after an interrupted update, or when disk errors show up too. Run DISM’s RestoreHealth before sfc /scannow.
Should I reset Windows to fix kernel security check failure?
Only as a last resort. If the culprit is a driver installed by the PC maker’s utilities or by Windows Update, it can come straight back after a reset. Identify the driver from the dumps first. A reset makes sense when you can’t find a pattern, hardware tests pass and the PC carries years of leftover software. Back up first: Keep my files still removes your installed apps, and Remove everything erases your files too.