Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
La KERNEL_SECURITY_CHECK_FAILURE comprobación de errores tiene un valor de 0x00000139 e indica que el kernel detecta los daños de una estructura de datos crítica.
Importante
Este artículo va dirigido a programadores. Si es un cliente que recibe 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 |
Reservado |
En la tabla siguiente se describen los posibles valores para el Parámetro 1.
| Parámetro 1 | Descripción |
|---|---|
0 |
Se sobrecarga un búfer basado en pila (infracción de /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++ está dañado y, a continuación, una llamada de método virtual intentó usar el puntero 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 está dañado (por ejemplo, una eliminación doble). Para obtener más información, consulte la siguiente sección de Causa. |
4 |
Reservado |
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. Esta comprobación de errores se debe a que la compilación de un controlador solo se ejecute en Windows 8 e intente cargar la imagen del controlador en una versión anterior de Windows. Para evitar el 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 |
Una entrada de RTL_BALANCED_NODE RBTree está dañada. |
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 el parámetro 1 tabla y un archivo de volcado de memoria, puede reducir la causa de muchas comprobaciones de errores de este tipo.
LIST_ENTRY los daños pueden ser difíciles de rastrear. Esta comprobación de errores indica que se introdujo una incoherencia en una lista vinculada doble (detectada cuando se agrega o quita un elemento de entrada de lista individual 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 del kernel, como un KEVENT (por ejemplo, la inicialización doble de un KEVENT mientras un subproceso sigue esperando 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 está dañado. A veces, el comprobador de controladores con un grupo especial puede ayudar a rastrear el culpable (si el objeto de sincronización dañado está en un bloque de grupo que ya está liberado).
- Un controlador ha dañado una KTIMER periódica. 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 es posible que sea necesario inspeccionar la tabla del temporizador con !timer (o caminar manualmente los vínculos de lista del temporizador) para identificar qué temporizador está dañado. A veces, el Comprobador de controladores con un grupo especial puede ayudar a rastrear al culpable (si el KTIMER dañado está en un bloque de grupo que ya está liberado).
- Un controlador no ha administrado una lista vinculada de estilo LIST_ENTRY interno. 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 liberó una estructura de datos que contiene un LIST_ENTRY sin quitar la estructura de datos de su lista correspondiente, lo que provoca que se detecten daños más adelante cuando se examina la lista después de reutilizar el bloque de grupo antiguo.
- Un controlador usó una lista de estilo LIST_ENTRY de forma 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 problemas de daños en la entrada de lista normalmente requiere el uso del depurador para recopilar otra información. Se deben examinar varios archivos de volcado para ver si el 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 hay eventos de nivel superior que se producen con el 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.
Compruebe el Visor de eventos del registro del sistema para ver otros mensajes de error que podrían ayudar a identificar el dispositivo o el controlador que está causando el error. 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 más información general sobre la solución de problemas, vea Analizar datos de pantalla azul de comprobación de errores.
Consulte también
Análisis de volcado de memoria mediante los depuradores de Windows (WinDbg)