Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All
Expand Minimize


The KERNEL_SECURITY_CHECK_FAILURE bug check has a value of 0x00000139. This bug check indicates that the kernel has detected the corruption of a critical data structure.

Important Info If You Have Received a STOP Code


If you received a blue screen error, or stop code, the computer has shut down abruptly to protect itself from data loss.

For information about how to recover from this error, see Resolving Blue Screen errors in Windows.


The following parameters are displayed on the blue screen.

1The type of corruption. For more information, see the following table.
2Address of the trap frame for the exception that caused the bug check
3Address of the exception record for the exception that caused the bug check


The following table describes possible values for Parameter 1.

Parameter 1Description
0A stack-based buffer has been overrun (legacy /GS violation).
1VTGuard instrumentation code detected an attempt to use an illegal virtual function table. Typically, a C++ object was corrupted, and then a virtual method call was attempted using the corrupted object's this pointer.
2Stack cookie instrumentation code detected a stack-based buffer overrun (/GS violation).
3A LIST_ENTRY was corrupted (for example, a double remove). For more information, see the following Cause section.
5An invalid parameter was passed to a function that considers invalid parameters fatal.
6The stack cookie security cookie was not properly initialized by the loader. This may be caused by building a driver to run only on Windows 8 and attempting to load the driver image on an earlier version of Windows. To avoid this problem, you must build the driver to run on an earlier version of Windows.
7A fatal program exit was requested.
8A array bounds check inserted by the compiler detected an illegal array indexing operation.
9A call to RtlQueryRegistryValues was made specifying RTL_QUERY_REGISTRY_DIRECT without RTL_QUERY_REGISTRY_TYPECHECK, and the target value was not in a trusted system hive.



Most causes of this bug check tend to be self explanatory and easy to diagnose. One exception is code 3, LIST_ENTRY corruption. This type of bug check can be difficult to track down and indicates that an inconsistency has been introduced into a doubly-linked list (detected when an individual list entry element is added to or removed from the list). Unfortunately, the inconsistency is not necessarily detected at the time when the corruption occurred, so some detective work may be necessary to identify the root cause.

Common causes of list entry corruption include:

  • A driver has corrupted a kernel synchronization object, such as a KEVENT (for example double initializing a KEVENT while a thread was still waiting on that same KEVENT, or allowing a stack-based KEVENT to go out of scope while another thread was using that KEVENT). This type of bug check typically occurs in nt!Ke* or nt!Ki* code. It can happen when a thread finishes waiting on a synchronization object or when code attempts to put a synchronization object in the signaled state. Usually, the synchronization object being signaled is the one that has been corrupted. Sometimes, Driver Verifier with special pool can help track down the culprit (if the corrupted synchronization object is in a pool block that has already been freed).
  • A driver has corrupted a periodic KTIMER. This type of bug check typically occurs in nt!Ke* or nt!Ki* code and involves signaling a timer, or inserting or removing a timer from a timer table. The timer being manipulated may be the corrupted one, but it might be necessary to inspect the timer table with !timer (or manually walking the timer list links) to identify which timer has been corrupted. Sometimes, Driver Verifier with special pool can help track down the culprit (if the corrupted KTIMER is in a pool block that has already been freed).
  • A driver has mismanaged an internal LIST_ENTRY-style linked list. A typical example would be calling RemoveEntryList twice on the same list entry without reinserting the list entry between the two RemoveEntryList calls. Other variations are possible, such as double inserting an entry into the same list.
  • A driver has freed a data structure that contains a LIST_ENTRY without removing the data structure from its corresponding list, causing corruption to be detected later when the list is examined after the old pool block has been reused.
  • A driver has used a LIST_ENTRY-style list in a concurrent fashion without proper synchronization, resulting in a torn update to the list.

In most cases, you can identify the corrupted data structure by walking the linked list both forward and backwards (the dl and dlb commands are useful for this purpose) and comparing the results. Where the list is inconsistent between a forward and backward walk is typically the location of the corruption. Since a linked list update operation can modify the list links of a neighboring element, you should look at the neighbors of a corrupted list entry closely, as they may be the underlying culprit.

Because many system components internally utilize LIST_ENTRY lists, various types of resource mismanagement by a driver using system APIs might cause linked list corruption in a system-managed linked list.



Send comments about this topic to Microsoft

© 2015 Microsoft