Cómo solucionar KERNEL SECURITY CHECK FAILURE en Windows 11

Qué es lo que no pasa la comprobación

El kernel mantiene sumas de control e invariantes sobre sus estructuras críticas, algo así como un banco que concilia sus libros varias veces por segundo. El código 0x139 significa que una de esas conciliaciones salió mal: un puntero de lista ya no apunta donde debe, o la cabecera de un búfer ya no coincide con su contenido. Windows se detiene a propósito, porque continuar con el estado del kernel corrompido arriesga escribir basura por todo el disco.

Lo que corrompe esas estructuras rara vez es un misterio. La memoria que devuelve bits invertidos bajo carga — muchas veces un perfil XMP o EXPO por encima de lo que el controlador de memoria aguanta de verdad — encabeza la lista. Los controladores que escriben fuera de sus búferes van segundos, con los de GPU y antivirus como reincidentes. Los archivos del sistema dañados y un SSD moribundo que sirve lecturas corrompidas completan la lista.

• RAM inestable — perfiles XMP/EXPO más allá de lo que el controlador de memoria de la CPU aguanta de verdad
• Un controlador con bugs que escribe fuera de su búfer — GPU, antivirus y virtualización son reincidentes
• Archivos del sistema corrompidos por una actualización fallida o un corte de luz repentino
• Un SSD moribundo que devuelve datos corrompidos al leer, visible en los atributos SMART
• Undervolt o overclock agresivos que voltean bits bajo carga

Probar la memoria y reparar los archivos

Empiece por la memoria: es la causa más común y la más barata de descartar. Lance mdsched.exe, reinicie cuando lo pida y deje correr la pasada estándar; el veredicto aparece en el Visor de eventos, en Registros de Windows → Sistema, origen MemoryDiagnostics-Results. La pasada estándar solo caza fallos groseros — si los fallos continúan con un resultado limpio, desactive XMP/EXPO en la BIOS y pruebe los módulos de uno en uno antes de dar a la memoria un veredicto de inocencia.

Los archivos van después, desde un «Símbolo del sistema (administrador)»: sfc /scannow coteja los archivos protegidos con el almacén de componentes, luego DISM /Online /Cleanup-Image /RestoreHealth repara el propio almacén si SFC no pudo con todo, y luego chkdsk C: /f /r recorre la superficie del disco en el siguiente reinicio. Una reinstalación limpia del controlador gráfico remata la parte de software: descargue el paquete más reciente, quite el viejo en Configuración → Aplicaciones → Aplicaciones instaladas e instale el nuevo tras reiniciar.

Acelerar al reincidente

Si el código de detención sobrevive a todo eso, el fallo ya es lo bastante específico para tener nombre. Los minidumps de C:\Windows\Minidump guardan la dirección del fallo y la lista de módulos cargados; WinDbg con !analyze -v o un lector como BlueScreenView los convierte en un nombre de controlador, y ese nombre pone fin a la caza. Al software instalado en los días previos al primer fallo le toca el primer interrogatorio: desinstalarlo es a la vez prueba y tratamiento.

La herramienta de último recurso es el Comprobador de controladores (verifier /standard /all desde una consola de administrador), que hace que los controladores sospechosos casquen con sus propios bugs, ruidosamente y al momento. Es peligrosa a propósito: cuente con pantallas azules mientras funciona y recuerde la salida — arranque en modo seguro y ejecute verifier /reset para apagarlo. Manejado así, Verifier saca a un controlador escondido en uno o dos días.

Preguntas y respuestas

Sigue leyendo

Todos los artículos · FAQ