STOP 0x00000139 — KERNEL_SECURITY_CHECK_FAILURE
The kernel caught a data structure that had been corrupted — a list pointer, a stack cookie, a buffer bound — and stopped rather than continue.
What you see
Bluescreens at varying times. Parameter 1 identifies the class of check that failed: 3 is a corrupt LIST_ENTRY, 2 is a stack buffer overrun.
What is actually wrong
A driver writing out of bounds, or failing memory. This is a protection working as designed, so the useful question is always which driver.
Codes and articles
The fix
Rule out memory, then catch the driver
Repeated 0x139 bugchecks. Do the cheap test first — memory faults produce this readily and cost nothing to exclude.
Disable any memory overclock profile (XMP, DOCP, EXPO) and run at stock for a day.
A factory overclock that is marginally unstable produces corrupted structures, which is exactly what this check is designed to catch.
Run MemTest86 for four full passes from USB.
If memory is clean, open the dump and read the analysis.
!analyze -vCheck parameter 1. For 3 (corrupt LIST_ENTRY), dump the call stack to see whose list it was.
!analyze -v; kbEnable Driver Verifier against third-party drivers only, and be ready for the machine to bugcheck on purpose.
verifier /standard /driver.exclude ntoskrnl.exeRead the rollback step before running this — Verifier can leave a machine unbootable and the way out is Safe Mode or WinRE.
Use the machine until it crashes, analyse the new dump, then turn Verifier off.
verifier /reset
Reference
Related faults
Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.