Comprobación de errores 0x139: KERNEL_SECURITY_CHECK_FAILURE
La comprobación de errores KERNEL_SECURITY_CHECK_FAILURE tiene un valor de 0x00000139. Esta comprobación de errores indica que el kernel ha detectado daños en una estructura de datos crítica.
Importante
Este artículo va dirigido a programadores. Si es un cliente que ha recibido un código de error de pantalla azul mientras usa el equipo, consulte Solución de errores de pantalla azul.
Parámetros de la comprobación de errores 0x139 KERNEL_SECURITY_CHECK_FAILURE
| Parámetro | Descripción |
|---|---|
| 1 | Tipo de daños. Para más información, vea la tabla siguiente. |
| 2 | Dirección del marco de captura de la excepción que provocó la comprobación de errores |
| 3 | Dirección del registro de excepciones de la excepción que provocó la comprobación de errores |
| 4 | Reserved |
En la tabla siguiente se describen los posibles valores para el Parámetro 1.
| Parámetro 1 | Descripción |
|---|---|
| 0 | Se ha saturado un búfer basado en pila (infracción /GS heredada). |
| 1 | El código de instrumentación de VTGuard detectó un intento de usar una tabla de funciones virtuales no válida. Normalmente, un objeto de C++ estaba dañado y, a continuación, se intentó llamar a un método virtual mediante el puntero this de este objeto dañado. |
| 2 | El código de instrumentación de cookies de pila detectó una saturación de búfer basada en pila (infracción /GS). |
| 3 | Un LIST_ENTRY estaba dañado (por ejemplo, una eliminación doble). Para obtener más información, consulte la siguiente sección de Causa. |
| 4 | Reserved |
| 5 | Se pasó un parámetro no válido a una función que considera que los parámetros no válidos son irrecuperables. |
| 6 | El cargador no inicializó correctamente la cookie de seguridad de cookies de pila. Esto puede deberse a que se ha compilado un controlador para que solo funcione en Windows 8 y se ha intentado cargar la imagen del controlador en una versión anterior de Windows. Para evitar este problema, debe compilar el controlador para que se ejecute en una versión anterior de Windows. |
| 7 | Se solicitó una salida de programa irrecuperable. |
| 8 | Una comprobación de límites de matriz insertada por el compilador detectó una operación de indexación de matriz no válida. |
| 9 | Se realizó una llamada a RtlQueryRegistryValues que especificaba RTL_QUERY_REGISTRY_DIRECT sin RTL_QUERY_REGISTRY_TYPECHECK y el valor de destino no estaba en un subárbol del sistema de confianza. |
| 10 | La comprobación de protección de llamada indirecta detectó una transferencia de control no válida. |
| 11 | La comprobación de protección de escritura detectó una escritura de memoria no válida. |
| 12 | Se ha intentado cambiar a un contexto de fibra no válido. |
| 13 | Se ha intentado asignar un contexto de registro no válido. |
| 14 | El número de referencia para un objeto no es válido. |
| 18 | Se ha intentado cambiar a un contexto jmp_buf no válido. |
| 19 | Se ha realizado una modificación no segura en los datos de solo lectura. |
| 20 | No se pudo realizar la prueba automática criptográfica. |
| 21 | Se ha detectado una cadena de excepción no válida. |
| 22 | Se ha producido un error en la biblioteca criptográfica. |
| 23 | Se ha realizado una llamada no válida desde DllMain. |
| 24 | Se detectó una dirección base de imagen no válida. |
| 25 | Se ha encontrado un error irrecuperable al proteger una importación de carga retrasada. |
| 26 | Se ha realizado una llamada a una extensión no segura. |
| 27 | Se ha invocado un servicio en desuso. |
| 28 | Se ha detectado un acceso al búfer fuera de los límites. |
| 29 | Se ha dañado una entrada de RBTree RTL_BALANCED_NODE. |
| 37 | Se ha invocado una entrada jumptable del conmutador fuera del intervalo. |
| 38 | Se ha intentado un longjmp con un destino no válido. |
| 39 | Un destino de llamada eliminado de exportación no se pudo convertir en un destino de llamada válido. |
Causa
Con la tabla del parámetro 1 y un archivo de volcado, es posible restringir la causa de muchas comprobaciones de errores de este tipo.
El daño en LIST_ENTRY puede ser difícil de rastrear y esta comprobación de errores indica que se ha introducido una incoherencia en una lista doblemente vinculada (detectada cuando se agrega o quita un elemento de entrada de lista individual a la lista o se quita de la lista). Desgraciadamente, la incoherencia no se detecta necesariamente en el momento en que se produce el daño, por lo que puede ser necesario cierto trabajo de investigación para identificar la causa raíz.
Entre las causas comunes de daños en la entrada de lista se incluyen las siguientes:
- Un controlador ha dañado un objeto de sincronización de kernel, como un KEVENT (por ejemplo, la inicialización doble de un KEVENT mientras un subproceso todavía estaba esperando en ese mismo KEVENT o permitiendo que un KEVENT basado en pila salga del ámbito mientras otro subproceso estaba usando ese KEVENT). Este tipo de comprobación de errores se produce normalmente en el código nt!Ke* o nt!Ki*. Puede ocurrir cuando un subproceso termina de esperar a un objeto de sincronización o cuando el código intenta colocar un objeto de sincronización en el estado señalado. Normalmente, el objeto de sincronización que se señala es el que se ha dañado. A veces, el Comprobador de controladores con un grupo especial puede ayudar a rastrear el causante (si el objeto de sincronización dañado está en un bloque de grupo que ya se ha liberado).
- Un controlador ha dañado un KTIMER periódico. Este tipo de comprobación de errores se produce normalmente en el código nt!Ke* o nt!Ki* e implica la señalización de un temporizador o la inserción o eliminación de un temporizador de una tabla de temporizadores. El temporizador que se está manipulando puede ser el dañado, pero puede ser necesario inspeccionar la tabla del temporizador con !timer (o recorrer manualmente los vínculos de lista del temporizador) para identificar qué temporizador se ha dañado. A veces, el Comprobador de controladores con un grupo especial puede ayudar a rastrear el causante (si el KTIMER dañado está en un bloque de grupo que ya se ha liberado).
- Un controlador ha administrado incorrectamente una lista vinculada interna de estilo LIST_ENTRY. Un ejemplo típico sería llamar a RemoveEntryList dos veces en la misma entrada de lista sin reinsertar la entrada de lista entre las dos llamadas RemoveEntryList. Otras variaciones son posibles, como la inserción doble de una entrada en la misma lista.
- Un controlador ha liberado una estructura de datos que contiene una LIST_ENTRY sin quitar la estructura de datos de su lista correspondiente, lo que provoca daños que se detectarán más adelante cuando se examine la lista después de volver a usar el bloque de grupo antiguo.
- Un controlador ha usado una lista de estilo LIST_ENTRY de manera simultánea sin una sincronización adecuada, lo que da lugar a una actualización rasgada a la lista.
En la mayoría de los casos, puede identificar la estructura de datos dañada al recorrer la lista vinculada hacia delante y hacia atrás (los comandos dl y dlb son útiles para este propósito) y comparar los resultados. Donde la lista es incoherente entre un recorrido hacia delante y hacia atrás suele ser la ubicación de los daños. Dado que una operación de actualización de lista vinculada puede modificar los vínculos de lista de un elemento vecino, debe examinar detenidamente los vecinos de una entrada de lista dañada, ya que pueden ser el culpable subyacente.
Dado que muchos componentes del sistema usan internamente listas de LIST_ENTRY, varios tipos de administración incorrecta de recursos por parte de un controlador que usan las API del sistema pueden provocar daños en una lista vinculada administrada por el sistema.
Solución
Determinar la causa de estos problemas normalmente requiere el uso del depurador para recopilar información adicional. Se deben examinar varios archivos de volcado para ver si este código de detención tiene características similares, como el código que se ejecuta cuando aparece el código de detención.
Para obtener más información, consulte Análisis de volcado de memoria mediante los depuradores de Windows (WinDbg), Uso de la extensión !analyze y !analyze.
Use el registro de eventos para ver si se producen eventos de nivel superior que conducen a este código de detención.
Estas sugerencias generales de solución de problemas pueden resultar útiles.
Si ha agregado recientemente hardware al sistema, intente quitarlo o reemplazarlo. O bien, póngase en contacto con el fabricante para ver si hay revisiones disponibles.
Si recientemente se han agregado nuevos controladores de dispositivo o servicios del sistema, pruebe a quitarlos o actualizarlos. Intente determinar qué es lo que ha cambiado en el sistema que ha provocado que aparezca el nuevo código de comprobación de errores.
Consulte el registro del sistema en el Visor de eventos para ver otros mensajes de error que puedan ayudarle a identificar el dispositivo o controlador que provoca el error. Para obtener más información, consulte Apertura del visor de eventos. Busque en el registro del sistema errores críticos que se hayan producido en la misma ventana de tiempo que la pantalla azul.
Busque en el Administrador de dispositivos para ver si algún dispositivo está marcado con el signo de exclamación (!). Revise el registro de eventos que se muestra en las propiedades del controlador en busca de algún dispositivo con errores. Pruebe a actualizar el controlador relacionado.
Ejecute un programa de detección de virus. Los virus pueden infectar todos los tipos de discos duros formateados para Windows, y los daños en los discos resultantes pueden generar códigos de comprobación de errores del sistema. Asegúrese de que el programa de detección de virus comprueba el registro de arranque maestro para detectar infecciones.
Para obtener información adicional sobre la solución de problemas generales, consulte Análisis de los datos de la comprobación de errores de la pantalla azul.
Vea también
Análisis de volcado de memoria mediante los depuradores de Windows (WinDbg)