What is

Unknown status / error value


Could be also:



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.


This topic is for programmers. If you are a customer who has received a blue screen error code while using your computer, see Troubleshoot blue screen errors.


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

The following table describes possible values for Parameter 1.

Parameter 1 Description
0 A stack-based buffer has been overrun (legacy /GS violation).
1 VTGuard 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.
2 Stack cookie instrumentation code detected a stack-based buffer overrun (/GS violation).
3 A LIST_ENTRY was corrupted (for example, a double remove). For more information, see the following Cause section.
4 Reserved
5 An invalid parameter was passed to a function that considers invalid parameters fatal.
6 The 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.
7 A fatal program exit was requested.
8 A array bounds check inserted by the compiler detected an illegal array indexing operation.
9 A 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.
10 Indirect call guard check detected invalid control transfer.
11 Write guard check detected invalid memory write.
12 An attempt was made to switch to an invalid fiber context.
13 An attempt was made to assign an invalid register context.
14 The reference count for an object is invalid.
18 An attempt was made to switch to an invalid jmp_buf context.
19 An unsafe modification was made to read-only data.
20 A cryptographic self-test failed.
21 An invalid exception chain was detected.
22 A cryptographic library error occurred.
23 An invalid call was made from within DllMain.
24 An invalid image base address was detected.
25 An unrecoverable failure was encountered while protecting a delay load import.
26 A call was made to an unsafe extension.
27 A deprecated service was invoked.
28 An out of bounds buffer access was detected.
29 An RTL_BALANCED_NODE RBTree entry has been corrupted.
37 An out of range switch jumptable entry was invoked.
38 A longjmp was attempted to an invalid target.
39 An export suppressed call target couldn't be made a valid call target.


Using the parameter 1 table, and a dump file, it is possible to narrow down the cause for many bug checks of this type.

LIST_ENTRY corruption can be difficult to track down and this bug check, 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.


Determining the cause of this issues typically requires the use of the debugger to gather additional information. Multiple dump files should be examined to see if this stop code has similar characteristics, such as the code that is running when the stop code appears.

For more information, see Crash dump analysis using the Windows debuggers (WinDbg), Using the !analyze Extension and !analyze.

Use the event log to see if there are higher level events that occur leading up to this stop code.

These general troubleshooting tips may be helpful.

  • If you recently added hardware to the system, try removing or replacing it. Or check with the manufacturer to see if any patches are available.

  • If new device drivers or system services have been added recently, try removing or updating them. Try to determine what changed in the system that caused the new bug check code to appear.

  • Check the System Log in Event Viewer for additional error messages that might help pinpoint the device or driver that is causing the error. For more information, see Open Event Viewer. Look for critical errors in the system log that occurred in the same time window as the blue screen.

  • Look in Device Manager to see if any devices are marked with the exclamation point (!). Review the events log displayed in driver properties for any faulting driver. Try updating the related driver.

  • Run a virus detection program. Viruses can infect all types of hard disks formatted for Windows, and resulting disk corruption can generate system bug check codes. Make sure the virus detection program checks the Master Boot Record for infections.

  • For additional general troubleshooting information, see Blue Screen Data.

See also

Crash dump analysis using the Windows debuggers (WinDbg)

Analyzing a Kernel-Mode Dump File with WinDbg

About “What is” service

Many of users are faced with the problem of interpreting errors that occur during the work of operating systems. In some cases, the operating system reports that an error has occurred and displays only an integer error code value. Often it is difficult to even roughly understand the cause of the error from the information given out. Our “what is” service contains a database of errors in Windows, Linux, Macos and Solaris operating systems. The database contains tens of thousands of values. In most cases, the online service will be able to help with the definition of the short name of the error and its detailed description.


Current version of service supports following types of error and status codes:

NTSTATUSMany kernel-mode standard driver routines and driver support routines use the NTSTATUS type for return values. Additionally, drivers provide an NTSTATUS-typed value in an IRP’s IO_STATUS_BLOCK structure when completing IRPs. The NTSTATUS type is defined in Ntdef.h, and system-supplied status codes are defined in Ntstatus.h.
Win32 errorWin32 error codes MUST be in the range 0x0000 to 0xFFFF, although Win32 error codes can be used both in 16-bit fields (such as within the HRESULT type specified in section 2.1) as well as 32-bit fields. Most values also have a default message defined, which can be used to map the value to a human-readable text message; when this is done, the Win32 error code is also known as a message identifier.
HRESULTHRESULT is a data type used in Windows operating systems, and the earlier IBM/Microsoft OS/2 operating system, to represent error conditions, and warning conditions.
The original purpose of HRESULTs was to formally lay out ranges of error codes for both public and Microsoft internal use in order to prevent collisions between error codes in different subsystems of the OS/2 operating system.
HRESULTs are numerical error codes. Various bits within an HRESULT encode information about the nature of the error code, and where it came from.
HRESULT error codes are most commonly encountered in COM programming, where they form the basis for a standardized COM error handling convention.
HTTP Status CodeHypertext Transfer Protocol (HTTP) response status codes. Status codes are issued by a server in response to a client’s request made to the server. It includes codes from IETF Request for Comments (RFCs), other specifications, and some additional codes used in some common applications of the HTTP. The first digit of the status code specifies one of five standard classes of responses. The message phrases shown are typical, but any human-readable alternative may be provided.
errnoInteger value, which is returned by system calls and some library functions in the event of an error to indicate what went wrong. errno is defined by the ISO C standard to be a modifiable lvalue of type int, and must not be explicitly declared; errno may be a macro. errno is thread-local; setting it in one thread does not affect its value in any other thread.
Kern ReturnApple Kernel return codes.
Ipp StatusThe IppStatus constant enumerates the status values returned by the Intel IPP functions, indicating
whether the operation is error-free.
Types of error and status codes

Source code

The service is based on the open source library AllStat. Its sources are available on our git server. We will be grateful for your participation in the finalization of the library and ideas for the development of the service. You can also download ErrorLookup libraries and utilities from our site.