Solucionar SYSTEM_THREAD_EXCEPTION_NOT_HANDLED Win 10/11
Respuesta breve: Lee la línea bajo la cara triste de la pantalla azul. 'What failed:' nombra un archivo .sys, y ese nombre es el controlador que falló: nvlddmkm.sys es de NVIDIA, atikmdag.sys es de AMD, los archivos Netwtw son de Wi-Fi Intel. Si Windows aún llega al escritorio, revierte ese controlador en el Administrador de dispositivos (Revertir al controlador anterior, en la pestaña Controlador). Si no arranca, entra en Modo seguro sin iniciar sesión —mantén Mayús y haz clic en Reiniciar, o interrumpe el arranque tres veces hasta que se abra la Reparación automática— y quítalo ahí. Cuando no se nombra ningún controlador, ejecuta DISM y luego SFC en un Símbolo del sistema como administrador.
Lee la letra pequeña antes de reiniciar. Bajo la cara con el ceño fruncido, pasada la línea SYSTEM_THREAD_EXCEPTION_NOT_HANDLED, Windows suele imprimir una más: “What failed: nvlddmkm.sys” o algún otro nombre de archivo terminado en .sys. Ese nombre es todo el diagnóstico. Identifica el controlador que lanzó una excepción que nadie capturó, y casi todo lo de abajo no es más que actuar sobre el nombre que hayas visto. Si la máquina se reinicia antes de que puedas leerlo, o vuelve directa a la pantalla azul, salta a la sección de Modo seguro y vuelve luego.
Lee primero el nombre del archivo
El código de detención por sí solo solo te dice la categoría: falló un controlador en modo kernel. El nombre del archivo te dice el sospechoso. La telemetría de fallos de Microsoft lleva dos décadas culpando a los controladores de la mayoría de los errores de detención de Windows, con una cifra cercana al 70%, y este error en concreto se inclina hacia los controladores más que la mayoría.
Cuando la pantalla pasa de golpe y se reinicia sola, desactiva el reinicio automático para que el siguiente fallo se quede quieto: pulsa Win+R, ejecuta sysdm.cpl, pestaña Opciones avanzadas, Configuración de Inicio y recuperación, y desmarca “Reiniciar automáticamente”. Ahora la pantalla azul te espera. Que no se nombre ningún controlador —un “What failed” en blanco o sin segunda línea— cambia el plan, y ese caso tiene su propia sección casi al final.
Esto es lo que apuntan los nombres más comunes:
- nvlddmkm.sys — el controlador de pantalla de NVIDIA, y el nombre que ve la mayoría. Encaja con que NVIDIA tenga cerca de tres cuartas partes de las GPU en la encuesta de hardware de Steam.
- atikmdag.sys o atikmpag.sys — gráficos AMD/ATI.
- dxgmms2.sys o dxgkrnl.sys — la capa de gráficos DirectX. Son archivos del propio Windows, pero la excepción casi siempre se remonta al controlador de la GPU que hay debajo, así que trátalo como un problema de gráficos.
- Netwtw04.sys, Netwtw06.sys, Netwtw10.sys — Wi-Fi Intel.
- iaStorA.sys o iaStorAC.sys — el controlador de almacenamiento (Rapid Storage) de Intel.
- Ntfs.sys — la excepción a la regla. Este apunta al sistema de archivos y al disco que hay debajo, no a un controlador de fabricante, y se inclina hacia el lado del hardware. Si ese es tu nombre, haz las comprobaciones de disco como harías con un error kernel data inpage en lugar de perseguir una actualización de controlador.
Cualquier nombre desconocido, pega el archivo exacto más la palabra “controlador” en un buscador: la mayoría de los nombres .sys son lo bastante únicos como para identificar el dispositivo en un solo resultado. Gráficos, red y almacenamiento cubren la inmensa mayoría de todos modos.

Si Windows aún arranca
A mucha gente este fallo le ocurre de forma intermitente —bien durante una hora, luego un parpadeo y reinicio— y entre medias llega al escritorio. Esa es la versión fácil, porque puedes trabajar con normalidad.
Lo primero que haces depende del momento: ¿los fallos empezaron justo después de algún cambio? Una actualización del controlador gráfico, un Windows Update que cambió un controlador de madrugada, una pieza de hardware nueva. Si es así, el nuevo controlador es el sospechoso principal y conviene ir hacia atrás, no hacia delante. Abre el Administrador de dispositivos (clic derecho en Inicio, Administrador de dispositivos), expande la categoría que señalaba el nombre —Adaptadores de pantalla para nvlddmkm o atikmdag, Adaptadores de red para Netwtw—, clic derecho en el dispositivo, Propiedades, pestaña Controlador. Revertir al controlador anterior reinstala la versión que tenías antes del problema.

Si Revertir está atenuado, Windows no guardó el paquete antiguo y no puedes retroceder así. Entonces toca una reinstalación limpia: desinstala el dispositivo con “Eliminar el software de controlador de este dispositivo” marcado, reinicia y deja que Windows ponga un controlador básico, o mejor, instala la versión actual directamente del fabricante —NVIDIA, AMD o Intel— en lugar de dejar que Windows Update te dé uno genérico. La guía para actualizar controladores explica cómo hacerlo de forma limpia, incluido eliminar antes por completo el paquete gráfico antiguo, que en las GPU importa más que en nada.
Windows Update puede deshacer esto por ti sin avisar, y eso pilla a la gente: a menudo vuelve a instalar el mismo controlador defectuoso en el siguiente análisis, y al día siguiente ya estás fallando otra vez. Si los fallos vinieron de un controlador de Windows Update, la reversión solo aguanta si impides que se reinstale: la herramienta “Mostrar u ocultar actualizaciones” de Microsoft oculta esa actualización concreta para que no vuelva.
¿No sabes cuándo empezaron en realidad los fallos? El Monitor de confiabilidad lo dibuja en una línea de tiempo. Busca “confiabilidad” en Inicio, abre Ver historial de confiabilidad, y las equis rojas se alinean con lo que se instaló ese mismo día: un controlador, una actualización, una aplicación. Es una lectura más rápida que el Visor de eventos para la única pregunta de “qué cambió justo antes de que esto empezara”.
Un nombre de gráficos que solo falla bajo carga —un juego, una exportación de vídeo, varios monitores despertando— merece una segunda mirada como tiempo de espera del controlador de pantalla más que como un 0x7E puro, ya que ambos se solapan y los arreglos difieren en los bordes.
Cuando no arranca: entrar en Modo seguro
“Entra en Modo seguro y actualiza el controlador” es buen consejo hasta que te das cuenta de que no puedes abrir Configuración en una máquina que da pantalla azul antes de la pantalla de inicio de sesión. Lo difícil no es el Modo seguro en sí, es llegar a él.
Cómo llegas depende de hasta dónde arranca la máquina:
- Puedes llegar al escritorio, aunque sea un momento. Configuración, luego Sistema, luego Recuperación en Windows 11 (es Actualización y seguridad, luego Recuperación en Windows 10), y haz clic en Reiniciar ahora bajo Inicio avanzado.
- Llegas a la pantalla de bloqueo pero no puedes pasar. Mantén Mayús y haz clic en Reiniciar en el botón de encendido de la esquina inferior. Mismo destino, sin iniciar sesión.
- Nunca llega tan lejos. Deja que intente arrancar y corta la corriente con el botón en cuanto veas el círculo giratorio. Hazlo dos o tres veces y Windows se rinde con el arranque limpio y abre la Reparación automática por su cuenta; desde ahí, Opciones avanzadas.
Las tres llevan al mismo menú azul de recuperación. Recórrelo por Solucionar problemas, Opciones avanzadas, Configuración de inicio, Reiniciar, y cuando aparezca la lista numerada pulsa 4 para Modo seguro o 5 para Modo seguro con funciones de red si necesitas descargar un controlador. La guía completa del Modo seguro tiene la misma ruta con cada pantalla ilustrada por si te pierdes en los menús.
Una vez dentro —todo en baja resolución y feo, eso es lo correcto— haz la reversión o desinstalación del Administrador de dispositivos de la sección anterior. El Modo seguro carga solo controladores genéricos, así que el que falla queda al margen mientras lo sacas.
Si prefieres forzar el Modo seguro desde un Windows que funciona para que el siguiente reinicio vaya allí, ejecuta msconfig, pestaña Arranque, marca Arranque a prueba de errores, déjalo en Mínima y reinicia. Solo recuerda volver y desmarcarlo después, o te quedarás arrancando en Modo seguro para siempre, una llamada de seguimiento genuinamente común.

El renombrado de emergencia
A veces un archivo de controlador es tan claramente todo el problema que el camino más rápido a una máquina que arranque es sacar ese archivo de en medio a mano. Es un instrumento contundente, así que la advertencia va primero: hazlo solo con un controlador de terceros claramente nombrado —un .sys de gráficos o de un periférico— y nunca con archivos centrales de Windows como Ntfs.sys.
Desde el menú de recuperación, elige Símbolo del sistema en lugar de Configuración de inicio. Aquí la unidad de Windows a menudo no es C:, así que compruébalo primero; bcdedit | find "osdevice" muestra la letra correcta. Luego ve a su carpeta de controladores y renombra al culpable:
cd /d C:\Windows\System32\drivers
ren nvlddmkm.sys nvlddmkm.old
Reinicia. Con su archivo renombrado, el controlador defectuoso no puede cargarse, Windows recurre a un controlador de pantalla básico integrado, y la máquina arranca —feo, baja resolución, pero estable lo suficiente para luego instalar un controlador como Dios manda por la vía normal. Es un parche para llegar al escritorio, no el arreglo en sí.
Cuando no se nombra nada, o vuelve igual
Una línea “What failed” en blanco, o un 0x7E que sigue volviendo después de haber resuelto el controlador nombrado, traslada la sospecha a los archivos del sistema en los que se apoyan esos controladores. Los archivos del sistema dañados lanzan la misma excepción que un controlador defectuoso.
Abre un Símbolo del sistema como administrador (Inicio, escribe cmd, clic derecho, Ejecutar como administrador) y ejecuta estos en orden, DISM antes que SFC porque SFC repara contra el almacén de componentes que DISM repara primero:
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
DISM trae copias limpias de los archivos del sistema dañados desde Windows Update; puede quedarse aparentemente atascado en el 20% durante diez o quince minutos, lo cual es normal: déjalo terminar antes de empezar SFC, que no tiene nada limpio de donde copiar hasta que DISM acabe.

El otro lugar donde se esconde la respuesta es el Visor de eventos, que registra más de lo que cabía en la pantalla azul. Ábrelo, expande Registros de Windows, haz clic en Sistema, y mira las entradas de Error rojas marcadas alrededor de la hora del fallo; una entrada BugCheck registra el código de detención, y el error justo anterior a menudo nombra el dispositivo o servicio que cayó. Esa línea previa al fallo suele ser más específica que el nombre de la pantalla.
La memoria también merece descartarse, aunque aquí es la causa minoritaria —esto no es un page fault in nonpaged area, donde la RAM está mucho más arriba en la lista—. El propio Diagnóstico de memoria de Windows (mdsched.exe) hace dos pasadas rápidas y se pierde fallos intermitentes; MemTest86 desde un USB, dejándolo varias pasadas durante la noche, es la prueba que de verdad encuentra el módulo defectuoso. Y si todo esto empezó justo tras una actualización de BIOS o un ajuste de XMP/overclock, carga los valores predeterminados de la BIOS —son los de fábrica, distintos de actualizar la versión de la BIOS— y deshace un cambio de tiempos de memoria que los controladores no soportan.
Ambas versiones de Windows entran en juego aquí por una razón sencilla: Windows 10 todavía funciona en aproximadamente uno de cada cuatro equipos de escritorio del mundo, así que “simplemente actualiza” no ayuda a nadie en pleno fallo, y los pasos del Administrador de dispositivos y del Símbolo del sistema son idénticos en ambas.
Pasados el controlador nombrado, una reversión, archivos del sistema limpios y una prueba de memoria limpia, un 0x7E que sigue saltando te está diciendo que el módulo culpable no es el obvio. Windows escribió un pequeño volcado en C:\Windows\Minidump en el momento del fallo, y ese archivo, leído en WinDbg, nombra el módulo exacto que disparó la excepción en lugar de dejarte acotarlo a mano. Leer esos volcados por tu cuenta es trabajo lento y minucioso; nuestro servicio de pantalla azul saca el minivolcado y apunta directo al módulo, normalmente en menos de media hora porque el volcado rara vez miente. La referencia oficial del error 0x7E de Microsoft y su solucionador de pantallas azules cubren el mismo terreno desde el otro lado si quieres seguir investigando por tu cuenta.
Preguntas Frecuentes
¿Qué significa SYSTEM_THREAD_EXCEPTION_NOT_HANDLED?
Significa que un controlador en modo kernel sufrió un error —una excepción— que Windows no pudo manejar, así que se detuvo para protegerse. El valor del código de detención es 0x0000007E. La mayoría de las veces la culpa es de un controlador concreto, y la pantalla azul suele imprimir su nombre de archivo en una línea 'What failed': nvlddmkm.sys para gráficos NVIDIA, atikmdag.sys para AMD, los archivos Netwtw para Wi-Fi Intel. Ese nombre te dice qué controlador revertir, actualizar o quitar.
¿Qué es el archivo 'What failed' de la pantalla azul?
Es el módulo del controlador que lanzó la excepción, y es lo más útil que hay en pantalla. nvlddmkm.sys es el controlador de pantalla de NVIDIA, atikmdag.sys o atikmpag.sys es de AMD, dxgmms2.sys y dxgkrnl.sys son la capa de gráficos DirectX (sigue apuntando a la GPU), Netwtw04/06/10.sys es Wi-Fi Intel y iaStorA.sys es el almacenamiento Intel. Si es Ntfs.sys, eso apunta al disco y al sistema de archivos en lugar de a un controlador de fabricante. Cualquier nombre desconocido, busca el archivo exacto más la palabra controlador para identificar el dispositivo.
¿Cómo soluciono SYSTEM_THREAD_EXCEPTION_NOT_HANDLED si el PC no arranca?
Entra en Modo seguro sin iniciar sesión. Mantén Mayús y haz clic en Reiniciar en el menú de encendido de la pantalla de bloqueo, o interrumpe el arranque tres veces —apaga con el botón al ver el círculo giratorio— hasta que Windows abra la Reparación automática por su cuenta. Desde el menú de recuperación ve a Solucionar problemas, Opciones avanzadas, Configuración de inicio, Reiniciar, y pulsa 4 para Modo seguro. Una vez dentro, abre el Administrador de dispositivos y revierte o desinstala el controlador nombrado en la pantalla azul. El Modo seguro solo carga controladores genéricos, así que el que falla queda fuera mientras lo quitas.
¿Debo actualizar o revertir el controlador?
Revierte si los fallos empezaron justo después de actualizar un controlador o de un Windows Update que cambió uno: la versión nueva suele ser la causa, y el botón Revertir al controlador anterior del Administrador de dispositivos la deshace. Actualiza desde la web del fabricante si tu controlador es antiguo y no cambiaste nada recientemente. Tras revertir, oculta la actualización con la herramienta 'Mostrar u ocultar actualizaciones' de Microsoft para que Windows Update no vuelva a instalar el controlador defectuoso en el siguiente análisis.
¿SYSTEM_THREAD_EXCEPTION_NOT_HANDLED es un problema de hardware?
Normalmente no. Es un problema de controlador o de archivos del sistema mucho más a menudo que de hardware defectuoso: los propios datos de fallos de Microsoft llevan tiempo atribuyendo alrededor del 70% de los cierres de Windows a los controladores. La RAM dañada puede provocarlo, pero aquí es minoría, así que prueba con MemTest86 solo después de resolver el controlador nombrado y ejecutar DISM y SFC. La excepción es un nombre como Ntfs.sys, que apunta al disco y al sistema de archivos en vez de a un controlador.