Cómo interpretar códigos de BSOD en Windows 11 paso a paso

PCHardwarePro » Windows » Cómo interpretar códigos de BSOD en Windows 11 paso a paso

Si usas Windows 11 desde hace un tiempo, seguro que alguna vez te has topado con la famosa pantalla azul. Esa en la que ves un mensaje de que el PC ha tenido un problema, un porcentaje de recopilación de información y uno o varios códigos que apenas te da tiempo a leer antes de que el equipo salga pantalla azul y se reinicie. Esos códigos BSOD (o STOP) son la pista principal para saber qué ha fallado, pero interpretarlos no siempre es tan sencillo como “míralo en el Visor de eventos”.

Además, en muchos casos ocurre algo todavía más frustrante: intentas hacer lo que recomiendan todas las guías (revisar el visor, abrir el minidump, usar un analizador automático…) y descubres que Windows ni siquiera ha podido crear el archivo de volcado. Aparece el apagado inesperado en el Visor de eventos, sí, pero el siguiente registro dice que “la creación del archivo de volcado ha fallado”. ¿Qué haces entonces? ¿Es un fallo grave de tu sistema o estás mirando en el sitio equivocado?

Qué es realmente una pantalla azul (BSOD) en Windows 11

Una pantalla azul o BSOD (Blue Screen of Death) es, en esencia, el mecanismo de defensa de Windows cuando detecta un error crítico del que no puede recuperarse sin riesgo de corromper datos. Cuando esto pasa, el sistema detiene todo, muestra la pantalla azul y fuerza un reinicio para proteger la integridad del sistema y del hardware.

En Windows 10 y Windows 11 el mensaje típico que aparece es algo como “Tu PC tuvo un problema y debe reiniciarse”, acompañado de un código de error en texto (tipo CRITICAL_PROCESS_DIED) y a veces un código STOP en hexadecimal. Esa información, aunque parezca un galimatías, es la llave para saber si hablamos de un fallo de controladores, de hardware, de memoria, de disco o de un bug de Windows o de alguna actualización reciente.

Las causas más frecuentes de estas pantallas son bastante conocidas: hardware defectuoso (RAM, CPU, SSD/HDD), controladores viejos o mal escritos, software incompatible, malware y archivos de sistema corruptos. También entran en juego factores físicos como el sobrecalentamiento o problemas de alimentación que terminan manifestándose como errores de hardware (por ejemplo, WHEA_UNCORRECTABLE_ERROR o MACHINE_CHECK_EXCEPTION).

En los últimos tiempos se han visto incluso pantallazos provocados por parches de Windows 11 defectuosos. Por ejemplo, ciertas acumulativas recientes han generado BSOD con códigos como KERNEL_SECURITY_CHECK_FAILURE al usar la GPU de forma intensiva o han roto la conectividad Wi‑Fi en algunos equipos hasta que Microsoft ha publicado otra actualización correctora.

Qué es un código STOP y qué información contiene

El código STOP es el identificador numérico del error crítico que ha obligado a Windows a detenerse. Suele verse en formato hexadecimal (por ejemplo, 0x00000050 o 0x00000124) y va asociado a un nombre simbólico, como PAGE_FAULT_IN_NONPAGED_AREA o WHEA_UNCORRECTABLE_ERROR.

Ese nombre simbólico es el que Microsoft utiliza en su documentación. Por ejemplo, DRIVER_POWER_STATE_FAILURE corresponde al código 0x0000009F. Si abres un volcado con el depurador WinDbg y ejecutas el comando !analyze -v, verás algo del estilo:

BugCheck 9F, {3, ffffe000f38c06a0, fffff803c596cad0, ffffe000f46a1010}

La línea anterior muestra el código de comprobación de errores (9F) y cuatro parámetros adicionales entre llaves. Cada código STOP tiene hasta cuatro parámetros que aportan contexto muy específico sobre qué ha pasado (por ejemplo, direcciones de memoria implicadas, tipo de operación, identificadores de dispositivos, etc.). La referencia oficial de códigos de comprobación de errores de Microsoft detalla para cada bugcheck qué significa cada parámetro.

El nombre simbólico (por ejemplo, DRIVER_POWER_STATE_FAILURE) y el valor hexadecimal (0x9F) aparecen juntos en la salida del depurador y en la documentación. Cuando busques información técnica avanzada, te interesa usar ambos: el nombre y el código. En cambio, las guías más genéricas suelen centrarse en el nombre en texto porque es más legible.

Cómo se recopilan los parámetros de un código de comprobación de errores

Si quieres ir más allá de “me ha salido un pantallazo azul” y entender qué ha fallado, necesitas obtener el código STOP y sus parámetros. Hay varias vías para conseguirlo, dependiendo de si tienes volcados de memoria, si puedes adjuntar un depurador o si solo te queda el registro de eventos.

La vía más accesible para la mayoría de usuarios es el Visor de eventos. En el registro del sistema, los eventos de comprobación de errores incluyen el código STOP y los cuatro parámetros asociados. No siempre es bonito ni fácil de leer, pero la información está ahí, salvo que la creación del volcado haya fallado o el sistema se haya quedado tan colgado que ni siquiera se haya podido registrar correctamente.

Otra forma más técnica es cargar el archivo de volcado generado (el minidump o el volcado completo) en WinDbg o en el depurador de Windows y usar el comando !analyze, idealmente con la opción -v para ver un análisis detallado. Ahí verás el BugCheck con sus parámetros, el módulo que probablemente ha causado el problema (por ejemplo, hidusb.sys) e incluso la pila de llamadas en el momento del fallo.

Si tienes un depurador de kernel conectado al equipo cuando se produce el error, la comprobación de errores hará que el sistema se detenga directamente en el depurador. En ese escenario, la pantalla azul puede ni siquiera aparecer en el monitor, sino que toda la información se envía a la ventana del depurador. Puedes volver a visualizar los datos del bugcheck con el comando .bugcheck o relanzar el análisis con !analyze.

Por qué a veces falla la creación del archivo de volcado

Una queja muy habitual es encontrarse en el Visor de eventos con un registro que dice “la creación del archivo de volcado falló debido a un error durante la creación del volcado”. Esto no significa necesariamente que tu sistema esté roto sin remedio, pero sí indica que algo ha impedido a Windows guardar esa información crucial.

Las causas pueden ser varias: falta de espacio en disco, errores en el propio volumen donde se debe escribir el volcado, corrupción del sistema de archivos, problemas de memoria tan graves que ni siquiera se puede completar la operación o configuraciones incorrectas de los ajustes de volcado. También puede interferir software de terceros (antivirus agresivos, cifrado a bajo nivel, etc.).

En estos casos, suele ser útil revisar la configuración avanzada del sistema, en la sección de Inicio y recuperación, para asegurarte de que tienes activado algún tipo de volcado (minidump, kernel o completo) y que la ruta de guardado es válida. Además, conviene comprobar que la unidad de sistema no está llena y que el sistema de archivos no presenta errores (con herramientas como CHKDSK).

Si aun así sigue fallando, no es que estés mirando mal: simplemente tu equipo no ha conseguido “loggear” el fallo en forma de volcado. En estos casos, tendrás que apoyarte más en el Visor de eventos, en pruebas de hardware y en el análisis del contexto (qué estabas haciendo, qué se ha actualizado recientemente, etc.).

Lectura de la información de depuración con WinDbg

Para quien quiera llegar al fondo de la cuestión, la herramienta clave es WinDbg. Cuando cargas un volcado de kernel y ejecutas !analyze -v, el depurador muestra una descripción detallada del error, incluyendo el bugcheck, los parámetros, la pila de llamadas y el módulo sospechoso.

Por ejemplo, podrías ver algo como que el error se ha producido “Probably caused by: hidusb.sys”, lo que apunta a un problema con el controlador HID USB (ratones, teclados, etc.). A partir de ahí puedes profundizar, poner puntos de interrupción en el código relevante, avanzar paso a paso y comprobar exactamente en qué parte del controlador se produce la violación.

Si tienes la posibilidad de conectar un depurador al sistema con problemas de forma persistente, la depuración de kernel es especialmente útil para errores recurrentes o muy complejos, sobre todo cuando otras técnicas de diagnóstico ya no dan más de sí. Eso sí, conviene anotar siempre el texto exacto que aparece en el mensaje de la pantalla azul y las acciones concretas que conducen al problema para poder reproducirlo de forma controlada.

Microsoft ofrece documentación específica sobre cómo analizar volcados de memoria (tanto en modo kernel como en modo usuario) y cómo usar en profundidad las extensiones del depurador, en particular !analyze y sus opciones. Para desarrolladores y personal de soporte avanzado, esto permite diferenciar si el fallo es realmente de su propio código o de otro componente del sistema.

BSOD frecuentes en Windows 11 y qué suelen significar

Hay un conjunto de errores de pantalla azul que se repiten con bastante frecuencia en Windows 10 y Windows 11. Reconocerlos de un vistazo ayuda a priorizar por dónde empezar a mirar. Algunos de los más habituales son:

• PAGE_FAULT_IN_NONPAGED_AREA (0x00000050): Windows ha intentado acceder a una página de memoria que no existe o no es accesible en ese momento. Suele apuntar a RAM defectuosa o a un volumen NTFS dañado.
• IRQL_NOT_LESS_OR_EQUAL (0x0000000A): un controlador de modo kernel ha tratado de acceder a memoria paginable cuando no debía (IRQL demasiado alto). Muy típico de controladores defectuosos o hardware con problemas.
• SYSTEM_SERVICE_EXCEPTION (0x0000003B): un servicio del sistema, normalmente un controlador o un proceso crítico, ha generado una excepción no controlada. A menudo está relacionado con drivers incompatibles o software que se mete demasiado en el kernel.
• DRIVER_IRQL_NOT_LESS_OR_EQUAL (0x000000D1): un controlador ha intentado acceder a una dirección de memoria no válida en un nivel de prioridad elevado. De nuevo, driver problemático casi seguro.
• CRITICAL_PROCESS_DIED (0x000000EF): un proceso esencial para el sistema se ha terminado de forma inesperada. Puede estar causado por archivos de sistema dañados, malware o errores del propio Windows.
• MEMORY_MANAGEMENT (0x0000001A): indica inconsistencias en la gestión de memoria. Suelen estar implicados módulos de RAM defectuosos, errores de hardware o corrupción profunda del sistema.
• SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (0x0000007E): muy asociado a controladores antiguos o incompatibles que lanzan excepciones no controladas.
• INACCESSIBLE_BOOT_DEVICE (0x0000007B): Windows no puede acceder a la partición de arranque. Puede deberse a cambios en la configuración SATA (RAID/AHCI), controladores de almacenamiento que faltan o archivos de arranque dañados.
• UNMOUNTABLE_BOOT_VOLUME (0x000000ED): el sistema no puede montar correctamente la unidad de arranque, a menudo durante el inicio. De nuevo, problemas de disco o de sistema de archivos.
• DPC_WATCHDOG_VIOLATION (0x00000133): típicamente ligado a drivers que bloquean el sistema durante demasiado tiempo (tiempos de espera superados en colas DPC).
• WHEA_UNCORRECTABLE_ERROR (0x00000124) y MACHINE_CHECK_EXCEPTION (0x0000009C): errores muy relacionados con fallos de hardware (CPU, RAM, placa base, alimentación) o con problemas graves de temperatura o tensión.

Cada uno de estos errores tiene su propia ficha en la documentación de Microsoft, con explicación técnica, significado de los parámetros y recomendaciones específicas. Si tu código STOP coincide con uno de estos, merece la pena revisar la referencia oficial para afinar el diagnóstico.

Códigos de BSOD menos frecuentes y orientaciones típicas

Además de los bugchecks clásicos, muchos fabricantes (Huawei, Dell y otros) recopilan internamente listados de códigos menos comunes con recomendaciones rápidas para su servicio técnico. Aunque están pensados para su ecosistema, dan una idea de por dónde suelen ir los tiros:

Errores como MANUALLY_INITIATED_POWER_BUTTON_HOLD o NMI_HARDWARE_FAILURE sólo se producen si el sistema está configurado para mostrar pantalla azul cuando se mantiene pulsado el botón de encendido cierto tiempo. Aunque el gatillo sea “manual”, el hecho de que se dispare puede indicar un problema de hardware que fuerza al usuario a apagar así el equipo.

Otros, como CPFN_REFERENCE_COUNT, FAST_ERESOURCE_PRECONDITION_VIOLATION o INVALID_KERNEL_STACK_ADDRESS, suelen achacarse a errores internos de Windows que rara vez se repiten. En estos casos, el consejo típico es reiniciar, actualizar parches y, si el problema persiste, acudir a soporte técnico porque puede haber corrupción profunda o un bug en el propio sistema.

También existen muchos códigos asociados casi siempre a aplicaciones o controladores de terceros. Por ejemplo, QUOTA_UNDERFLOW, PROCESS_HAS_LOCKED_PAGES, BUGCODE_NDIS_DRIVER (red), BUGCODE_USB3_DRIVER (USB 3.0), DRIVER_OVERRAN_STACK_BUFFER o FSRTL_EXTRA_CREATE_PARAMETER_VIOLATION. En la práctica, la recomendación suele ser revisar qué programas o drivers se han instalado últimamente, especialmente gestores de PC, software antivirus o herramientas “milagro” de optimización, y desinstalarlos para ver si el problema desaparece.

Hay códigos directamente relacionados con el sistema de archivos, como FAT_FILE_SYSTEM, UDFS_FILE_SYSTEM, EXFAT_FILE_SYSTEM o FLTMGR_FILE_SYSTEM. Cuando aparecen de forma repetida, apuntan a unidades mal particionadas, instalaciones de sistema poco ortodoxas, discos en mal estado o controladores de filtro que interfieren con el acceso al disco. En muchos casos los fabricantes recomiendan restaurar ajustes de fábrica o reinstalar Windows si tras actualizar y reparar el sistema de archivos el fallo continúa.

Otros códigos están vinculados a fallos de CPU, memoria o hipervisor, por ejemplo MACHINE_CHECK_EXCEPTION, WHEA_INTERNAL_ERROR, HYPERVISOR_ERROR o STORE_DATA_STRUCTURE_CORRUPTION. Aquí ya hablamos casi siempre de problemas de hardware o de configuraciones de virtualización avanzadas, y lo habitual es tirar de garantía o de diagnóstico físico avanzado.

Cuando el problema viene de actualizaciones de Windows 11

No todos los BSOD son culpa de tu hardware o del software que has instalado. En ocasiones, son las propias actualizaciones de Windows las que introducen regresiones. Se han documentado casos recientes en los que parches acumulativos para Windows 11 han provocado pantallazos con KERNEL_SECURITY_CHECK_FAILURE en equipos con ciertas gráficas, así como fallos de conectividad Wi‑Fi.

En esos escenarios, Microsoft suele reconocer públicamente el problema y publicar una actualización correctora. Por ejemplo, una acumulativa defectuosa puede ser la KB5074105 y la actualización que corrige los errores, la KB5077181. Esta última se distribuye a través de Windows Update y se va desplegando de forma escalonada.

Si empiezas a ver pantallas azules después de instalar una actualización concreta y todo funcionaba bien antes, es buena idea revisar el historial de actualizaciones de Windows Update y buscar si tu KB aparece asociada a problemas conocidos en la documentación de Microsoft. Mientras esperas al parche corrector, podrías desinstalar la actualización conflictiva o pausar temporalmente las actualizaciones automáticas, aunque esto siempre implica cierto riesgo de seguridad.

En cualquier caso, además de instalar el parche que arregla el desaguisado, conviene mantener el resto del sistema al día: BIOS/UEFI actualizada, controladores de chipset, gráficos, red y almacenamiento en versiones recientes, especialmente si el fabricante de tu equipo proporciona herramientas propias (SupportAssist, PC Manager, etc.).

Herramientas y técnicas para investigar un BSOD en profundidad

Más allá del consejo genérico de “actualiza todo y reinicia”, hay varias herramientas bastante potentes pensadas precisamente para diagnosticar la causa raíz de un pantallazo azul, incluso cuando no se han generado volcados de forma fiable.

Por un lado está el Visor de eventos, que ya hemos mencionado. Navegando a Registros de Windows > Sistema puedes filtrar por errores críticos ocurridos alrededor de la hora del BSOD. Aunque el volcado haya fallado, el registro del apagado inesperado y del intento de crear el volcado suele quedar ahí, con algunos datos útiles (código de error, módulo, etc.).

También son muy valiosos los archivos minidump, esos ficheros pequeños que Windows crea en C:\Windows\Minidump cuando consigue completar al menos un volcado parcial. Contienen información condensada de la situación del sistema en el momento del fallo y se pueden abrir con WinDbg u otras herramientas para identificar el driver o módulo implicado.

Si el sistema arranca, otra opción es usar Driver Verifier, una herramienta integrada en Windows que somete a los controladores a una especie de “estrés test” en tiempo real. Valida su comportamiento con la memoria, los IRQL, las colas, etc. Cuando detecta un uso incorrecto, puede forzar un bugcheck proactivo para señalar claramente qué driver se está portando mal. Eso sí, añade cierta sobrecarga, por lo que hay que seleccionar con cuidado qué controladores se van a comprobar para no ralentizar en exceso el equipo.

Además, puedes apoyarte en otras utilidades avanzadas como el conjunto de herramientas Sysinternals y monitores de red, que ayudan a aislar problemas que podrían terminar derivando en un pantallazo (fugas de memoria extremas, drivers que no responden, servicios colgados, etc.). Junto con el registro de eventos y los volcados, permiten construir un cuadro bastante completo de lo que está ocurriendo.

Consejos específicos para desarrolladores y software de terceros

Si desarrollas drivers o software que se mete en el kernel, tarde o temprano verás un BSOD provocado por tu propio código. En ese caso, no basta con “reinstalar Windows”: toca depurar y corregir el problema. Para ello, lo más efectivo es usar la depuración de kernel con WinDbg, reproducir el error en un entorno controlado, analizar el bugcheck y estudiar la pila de llamadas y los IRQL en el momento de la caída.

Cuando el bugcheck no se debe a tu código, pero tu aplicación se ve afectada, el objetivo cambia: no podrás arreglar el fallo raíz, pero sí puedes intentar evitar que tu software lo dispare. A menudo esto pasa por implementar comprobaciones adicionales, manejar mejor los errores de otros componentes, reducir dependencias agresivas de drivers de terceros o evitar prácticas arriesgadas que se apoyan demasiado en comportamientos no documentados.

En cualquier caso, es fundamental anotar con precisión las acciones exactas que llevan al pantallazo, los códigos que aparecen y la frecuencia con la que se reproduce. Con esa información es mucho más fácil para los equipos de soporte o para Microsoft evaluar si se trata de un bug conocido, de hardware defectuoso o de una interacción extraña entre componentes.

Por último, no hay que subestimar las “soluciones básicas” de toda la vida: revisar manuales, reinstalar componentes clave, comprobar fechas de archivos, desinstalar antivirus o gestores de PC intrusivos y verificar drivers de red, USB o almacenamiento. Una gran parte de las BSOD ligadas a software de terceros acaban resolviéndose eliminando el componente problemático.

En definitiva, interpretar códigos de BSOD en Windows 11 no es solo cuestión de ver un número en la pantalla azul: es combinar ese código y sus parámetros con las pistas del Visor de eventos, los volcados de memoria, el estado del hardware y los cambios recientes en el sistema. Cuando se junta todo ese contexto —y se entiende qué significa cada bugcheck— deja de ser un pantallazo “misterioso” y pasa a ser una herramienta muy concreta para saber qué está fallando, si es culpa de un driver, del hardware, de una actualización o incluso de tu propio código, y decidir si basta con actualizar, desinstalar algo, reparar Windows o ya toca pensar en diagnóstico físico y servicio técnico especializado.