Análisis de archivos de registro de arranque (Boot Logs) como Ntbtlog.txt para solucionar fallos de inicio de Windows

Última actualización: 31/03/2026
Autor: Isaac
  • El proceso de arranque de Windows se divide en fases (PreBoot, Boot Manager, OS Loader y kernel) y cada una muestra síntomas distintos cuando falla.
  • Herramientas como Reparación de inicio, BOOTREC, BCDEDIT y RegBack permiten reparar MBR, sector de arranque, BCD y hives del Registro dañadas.
  • El registro de arranque Ntbtlog.txt se activa con boot.ini o BCDEDIT y registra controladores cargados y omitidos, clave para diagnosticar fallos.
  • Combinar Boot Logs, Visor de eventos, SFC/DISM y volcados de memoria facilita localizar drivers o actualizaciones que impiden que Windows arranque.

Registro de arranque de Windows Ntbtlog.txt

Cuando Windows se niega a arrancar y se queda en una pantalla negra, un bucle de reinicios o un pantallazo azul, lo normal es entrar en pánico. Pero, más allá de las típicas herramientas automáticas, existe un recurso muy potente para entender qué está pasando: los archivos de registro de arranque o Boot Logs, especialmente el archiconocido Ntbtlog.txt.

Estos registros detallan qué controladores y componentes se cargan (o fallan al cargarse) durante el inicio del sistema, y combinados con otras utilidades como Reparación de inicio, BOOTREC, DISM o el propio Registro de Windows, permiten atacar de raíz muchos problemas de arranque, tanto en equipos con BIOS clásica como en sistemas modernos con UEFI (proceso de arranque en UEFI).

Cómo funciona el arranque de Windows y en qué fase está el fallo

Antes de lanzarse a revisar Ntbtlog.txt o a pegar comandos en la consola, conviene tener claro cómo se organiza el proceso de arranque de Windows y qué piezas se ponen en marcha en cada momento. Esto permite saber si el error se produce muy temprano (firmware/BIOS), en el gestor de arranque, en el cargador del sistema operativo o ya cuando entra en juego el kernel de Windows.

En líneas generales, el ciclo de inicio de un sistema Windows moderno se divide en cuatro grandes fases que se dan tanto en máquinas con BIOS heredada como en equipos con firmware UEFI, aunque los archivos implicados y las rutas cambian ligeramente:

  • Fase 1 – PreBoot: el firmware (BIOS o UEFI) hace la POST (Power-On Self Test), inicializa el hardware básico y localiza un disco de sistema válido. En máquinas BIOS se lee el MBR/PBR; en UEFI se carga el firmware y se busca la aplicación EFI del gestor de arranque de Windows.
  • Fase 2 – Windows Boot Manager: entra en juego el gestor de arranque, que busca la configuración de arranque y decide qué sistema iniciar.
  • Fase 3 – Windows OS Loader: el cargador del sistema (winload.exe o winload.efi) carga el kernel y los controladores marcados para cargarse en el arranque.
  • Fase 4 – Kernel de Windows NT: el kernel (ntoskrnl.exe) toma el control, monta la hive del Registro del sistema, carga los controladores BOOT_START y arranca la sesión del sistema (Smss.exe), que a su vez lanza el resto de servicios y controladores.

Cada una de estas etapas tiene síntomas y mensajes de error bastante característicos, desde el típico “Bootmgr is missing” hasta errores como INACCESSIBLE_BOOT_DEVICE o pantallas azules justo después del logotipo de Windows, y por tanto se diagnostican y reparan con herramientas diferentes.

Fase Etapa Equipo con BIOS Equipo con UEFI
1 PreBoot MBR / PBR (código de arranque) Firmware UEFI
2 Gestor de arranque de Windows %SystemDrive%\bootmgr \EFI\Microsoft\Boot\bootmgfw.efi
3 Cargador del SO de Windows %SystemRoot%\System32\winload.exe %SystemRoot%\System32\winload.efi
4 Kernel de Windows NT %SystemRoot%\System32\ntoskrnl.exe (igual, pero ya bajo UEFI)

El objetivo al diagnosticar un fallo de arranque es “pillar” en qué tramo de esta cadena se rompe el proceso. A partir de ahí, podremos decidir si tiene sentido mirar el archivo de registro de arranque, el SrtTrail.txt de la reparación de inicio, los volcados de memoria, el Registro o centrarnos en los códigos de arranque (MBR, BCD, Bootmgr, etc.).

Fallos en la fase de BIOS o firmware: cómo detectarlos

Diagnóstico de problemas de arranque en BIOS y UEFI

Si el equipo ni siquiera llega a mostrar el logotipo de Windows y se queda colgado en una pantalla en negro sin mensajes claros, o ni siquiera se enciende correctamente, el problema suele estar en el propio firmware o en el hardware base.

Hay un par de comprobaciones muy sencillas para saber si el sistema ha superado la fase de BIOS o se ha quedado atascado ahí:

  1. Desconecta todos los periféricos externos (USB, discos externos, impresoras…). A veces el firmware intenta arrancar desde un dispositivo extraíble y se queda bloqueado.
  2. Observa el LED de actividad del disco duro. Si no parpadea en absoluto durante el encendido, es posible que el proceso no esté llegando al punto en el que se lee el sector de arranque.
  3. Prueba a pulsar la tecla BloqNum (Num Lock). Si el indicador del teclado no cambia, suele indicar que el sistema está totalmente colgado a nivel de firmware o de placa base.

Cuando el bloqueo está en esta etapa tan temprana, lo habitual es estar ante un fallo de hardware (memoria, placa, fuente de alimentación, disco moribundo…) y no tanto ante un problema de archivos de arranque, por lo que en estos casos el análisis de Ntbtlog.txt y similares ni siquiera llega a generarse.

Errores en el gestor de arranque y cargador (MBR, BCD, Bootmgr)

Si la máquina enciende, el logo del fabricante aparece y acto seguido ves una pantalla negra con un cursor parpadeando o mensajes como “Operating System Missing”, “Bootmgr is missing” o errores relacionados con BCD, el problema está ya en la fase del gestor de arranque (Boot Manager / Boot Loader).

  Cuándo es mejor activar o desactivar la indexación de archivos en Windows

Algunos mensajes típicos de esta etapa dejan bastante claro por dónde van los tiros:

  • Boot Configuration Data (BCD) missing or corrupted
  • Boot file or MBR corrupted
  • Operating system missing
  • Boot sector missing or corrupted
  • Bootmgr missing or corrupted
  • Unable to boot due to system hive missing or corrupted

En este punto, la forma más eficaz de actuar es arrancar con un medio externo de Windows (USB/DVD creado con la herramienta de Microsoft o un ISO de la misma versión o superior) y abrir un símbolo del sistema usando la combinación Mayús+F10 o mediante las opciones avanzadas de recuperación.

Uso de la herramienta de Reparación de inicio (Startup Repair)

La utilidad de Reparación de inicio de Windows es el primer cartucho que conviene disparar, porque automatiza muchas comprobaciones: revisa la integridad de los archivos de arranque, intenta arreglar el BCD, repara sectores de arranque dañados y genera su propio registro de lo que ha hecho.

El flujo de uso es muy sencillo cuando arrancas desde el medio de instalación de la misma versión de Windows que tienes instalada:

  1. Inicia el equipo desde el USB/DVD de instalación de Windows y, en la ventana inicial, pulsa en Siguiente > Reparar el equipo.
  2. En la pantalla de elección, entra en Solucionar problemas.
  3. Accede a Opciones avanzadas > Reparación de inicio y deja que la herramienta analice el sistema.
  4. Cuando termine, apaga desde el propio asistente y prueba a arrancar normalmente.

Todo lo que hace esta herramienta queda registrado en el archivo SrtTrail.txt, ubicado en %windir%\System32\LogFiles\Srt\Srttrail.txt. Aunque no es un boot log al estilo de Ntbtlog.txt, sí resulta útil para entender qué ha detectado y qué acciones ha intentado aplicar.

Reparar el MBR y el sector de arranque con BOOTREC

Si Reparación de inicio no soluciona el asunto, el siguiente paso clásico es usar la herramienta BOOTREC (ver guía de BOOTREC) desde el símbolo del sistema del entorno de recuperación. Esta utilidad permite reescribir el MBR, reconstruir el sector de arranque y volver a generar la base de datos BCD.

Los comandos básicos para atacar problemas típicos de MBR y sector de arranque son los siguientes:

  • Reescribir el MBR (muy útil si otro sistema o una herramienta de terceros lo han machacado):
    bootrec /fixmbr
  • Reparar el sector de arranque de la partición del sistema:
    bootrec /fixboot

En algunos escenarios (sobre todo en sistemas UEFI con partición EFI en FAT32) puede aparecer el temido “Acceso denegado” al ejecutar /fixboot. En esos casos hay que comprobar que la partición de sistema está correctamente asignada, con letra, y a veces marcarla como activa o reparar manualmente los archivos de arranque copiando bootmgr y el contenido de \EFI\Microsoft\Boot.

Corregir errores del almacén BCD

Cuando el BCD está corrupto o apunta a instalaciones inexistentes, verás errores más específicos sobre “Boot Configuration Data”. Aquí BOOTREC y BCDEDIT trabajan de la mano (ver diagnóstico con BCDEDIT).

Un procedimiento típico para regenerar el BCD desde cero es este:

  1. Escanear las instalaciones detectables de Windows:
    bootrec /scanos
  2. Si tras el escaneo sigue sin arrancar, respaldar el BCD y reconstruirlo:
    bcdedit /export C:\bcdbackup
    attrib C:\boot\bcd -r -s -h
    ren C:\boot\bcd bcd.old
    bootrec /rebuildbcd
  3. Cuando se pregunte si deseas agregar la instalación encontrada a la lista de arranque, responde que sí.

En algunos casos aparecerá un error del tipo “No se puede encontrar el dispositivo de sistema solicitado” al intentar añadir la instalación; ahí toca revisar con diskpart que la partición de sistema esté marcada correctamente, tenga letra y no esté dañada.

Reemplazar el archivo Bootmgr

Si tras varios intentos los errores apuntan directamente a bootmgr dañado, se puede optar por renombrar la copia defectuosa y colocar una nueva desde la partición reservada del sistema o desde el medio de instalación.

La idea general es dejar el antiguo bootmgr a salvo y copiar uno funcional a la partición donde reside el sistema:

  1. Identifica la partición reservada del sistema (normalmente sin letra, en FAT32 o NTFS, de unos 100 MB en Windows modernos) y asígnale una letra con diskpart si es necesario.
  2. En esa partición, lista los archivos ocultos y de sistema con:
    attrib -r -s -h
  3. Haz lo mismo en la unidad del sistema (por ejemplo, C:) para ver el bootmgr existente.
  4. Cambia el nombre del bootmgr dañado, por ejemplo:
    ren C:\bootmgr bootmgr.old
  5. Copia el bootmgr “sano” desde la partición reservada del sistema a la raíz de la unidad de Windows.
  6. Reinicia y comprueba si ya arranca.

Restaurar el subárbol del Registro del sistema

Cuando los errores indican que la hive del sistema no se puede cargar (“system hive missing or corrupted”), el problema pasa de ser puramente de arranque a un tema de Registro. En esos casos suele ser necesario restaurar los subárboles del Registro desde una copia válida (puedes ver técnicas para mejorar el Registro con RegScanner).

  Tutorial del dock de macOS si vienes desde Windows 11

Desde el entorno de recuperación WinRE o un disco de reparación ERD se puede copiar el contenido de C:\Windows\System32\config\RegBack a C:\Windows\System32\config, sobreescribiendo los archivos dañados (SYSTEM, SOFTWARE, etc.). Si aún así no arranca, tocaría restaurar una copia de seguridad completa del estado del sistema y luego traer solo las hives necesarias.

Fase de kernel: pantallazos azules, bucles y bloqueos tras el logo

Errores de kernel y pantallazos azules en el arranque de Windows

Si ya ves el logotipo de Windows, incluso el icono de la “rueda” de puntos girando, pero de repente salta un pantallazo azul, se queda congelado o aparece una pantalla negra sin más, es muy probable que el problema esté en la fase del kernel o en los controladores que se cargan en esa etapa.

Algunos síntomas típicos de fallo en esta fase son muy conocidos:

  • Código de parada justo después de la pantalla de presentación (por ejemplo, 0x00000C2, 0x0000007B, etc.).
  • Error de INACCESSIBLE_BOOT_DEVICE, con el identificador de parada 0x7B, que implica problemas para acceder al disco de arranque.
  • La rueda de puntos giratorios se queda indefinidamente como “sistema ocupado”.
  • La pantalla se queda en negro tras el logo de Windows, sin mensajes.

En estas situaciones las opciones de recuperación se basan en arrancar de forma limitada y luego diagnosticar con herramientas como el Visor de eventos, los registros de arranque, los volcados de memoria y el propio Registro.

Intentar Modo seguro y Última configuración válida conocida

El Modo seguro sigue siendo un clásico porque carga lo mínimo imprescindible para que Windows arranque, dejando fuera buena parte de los controladores de terceros y servicios que podrían estar causando el desastre.

Desde las Opciones avanzadas de arranque puedes probar:

  • Modo seguro
  • Modo seguro con funciones de red
  • Última configuración correcta conocida (si aparece disponible en tu versión)

Si el equipo consigue arrancar en alguna de estas variantes, una de las primeras cosas recomendables es abrir el Visor de eventos y revisar los registros del sistema y de aplicación alrededor del momento en que empezaron los síntomas, copiando los eventos relevantes para analizarlos con calma.

Inicio limpio para localizar servicios y controladores conflictivos

Cuando el problema apunta a un servicio o controlador de terceros (antivirus, software de copia de seguridad, drivers de almacenamiento especiales, etc.), es muy útil realizar un “inicio limpio” con la herramienta msconfig.

En Configuración del sistema se puede seleccionar “Inicio selectivo” y desmarcar progresivamente servicios no críticos, especialmente los que no son de Microsoft, hasta localizar cuál es el que dispara el fallo de arranque. Una vez hallado, se puede deshabilitar definitivamente y volver a un “Inicio normal”.

Si el problema está en la firma de controladores (sobre todo en sistemas x64 con Secure Boot o exigencia de firma), otra vía es arrancar con la opción “Deshabilitar el uso obligatorio de controladores firmados” y analizar qué driver exige firma o está causando conflicto, siguiendo las pautas de los artículos específicos de Microsoft sobre este tipo de problemas.

Error INACCESSIBLE_BOOT_DEVICE (STOP 0x7B)

El error INACCESSIBLE_BOOT_DEVICE es uno de los más temidos porque implica que Windows no puede acceder a la unidad desde la que debería arrancar: controladores de almacenamiento inadecuados, filtros de terceros, cambios en el modo del controlador SATA/RAID en BIOS, etc.

Un método avanzado para lidiar con este error consiste en filtrar controladores de terceros en el Registro desde el entorno de recuperación:

  1. Arranca en WinRE usando un ISO de la misma versión de Windows o superior.
  2. Abre el editor del Registro y carga la hive del sistema, dándole un nombre temporal, por ejemplo test.
  3. Ve a la clave:
    HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class
  4. Localiza entradas UpperFilters y LowerFilters que se refieran a controladores que no sean de Microsoft.
  5. Para cada controlador sospechoso, limpia el contenido del valor de filtro correspondiente.
  6. Busca otras ocurrencias similares en la hive, modifícalas con cuidado y descarga la hive cuando termines.
  7. Reinicia el sistema en Modo normal y comprueba si el error 0x7B ha desaparecido.

Si el problema empezó justo después de instalar actualizaciones de Windows, puede ser necesario retirar paquetes pendientes o revertir acciones de actualización con DISM, cambiando valores en el Registro (por ejemplo, el servicio TrustedInstaller) e incluso renombrando archivos como pending.xml en WinSxS para desatascar el proceso.

Habilitar el registro de arranque (BootLog) en Windows

Llegados a este punto, entra en juego el protagonista de este artículo: el archivo Ntbtlog.txt. Este fichero es el registro clásico de arranque de Windows; en él se anotan los controladores y componentes que se van cargando (o fallando) durante el inicio, lo que permite detectar, por ejemplo, qué driver concreto impide que el sistema se levante.

El BootLog no viene activado de serie, pero activarlo es muy sencillo y puedes hacerlo de dos formas principales: mediante boot.ini en sistemas antiguos o con bcdedit en versiones modernas como Windows 10 y posteriores; resulta muy útil combinarlo con técnicas para analizar con BootTrace.

Activar BootLog en sistemas basados en boot.ini (Windows XP y similares)

En equipos antiguos, el archivo de configuración de arranque es boot.ini, que se encuentra en la raíz de la unidad donde está instalado Windows (normalmente C:) y está marcado como archivo oculto y de sistema.

  Qué es un Enablement Package en actualizaciones Windows

Para editarlo, primero hay que mostrar los archivos de sistema protegidos desde las opciones de carpeta, localizar boot.ini y abrirlo con el Bloc de notas. Ahí verás una línea similar a esta (aunque con otros parámetros):

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=»Microsoft Windows XP Professional» /noexecute=optin /fastdetect

Para activar el registro de arranque basta con añadir el modificador /BOOTLOG al final de esa línea, quedando algo como:

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=»Microsoft Windows XP Professional» /noexecute=optin /fastdetect /BOOTLOG

Una vez guardado el archivo, el sistema empezará a generar el registro de arranque en cada inicio. Además, en situaciones de emergencia se puede activar el registro de forma puntual desde el menú avanzado de arranque: pulsando F8 justo antes de que arranque Windows y eligiendo la opción “Habilitar registro de inicio”.

El archivo generado se llama siempre Ntbtlog.txt y se guarda en la carpeta de Windows, normalmente en C:\Windows, listo para abrir con el Bloc de notas y revisar qué controladores se han cargado correctamente y cuáles no.

Activar y desactivar BootLog con BCDEDIT en Windows 10 y posteriores

En sistemas modernos que usan BCD (Windows Vista en adelante, incluido Windows 10), la configuración de arranque ya no se gestiona con boot.ini, sino con el almacén de datos de configuración de arranque y la herramienta bcdedit.

Para habilitar el registro de arranque en un sistema concreto necesitas conocer el identificador (ID) de ese cargador dentro del BCD. Se obtiene ejecutando en un símbolo del sistema con privilegios de administrador:

bcdedit

En el bloque “Cargador de arranque de Windows” verás una línea denominada “Identificador” que puede ser algo como {current} o un GUID distinto. Usando ese ID, se puede activar el BootLog así:

bcdedit /set {ID} bootlog Yes

Para desactivarlo basta con cambiar el valor a “No”:

bcdedit /set {ID} bootlog No

Tras el siguiente reinicio, si el registro está activado, Windows generará el archivo Ntbtlog.txt en la ruta indicada con toda la información necesaria sobre los controladores y módulos que participan en el arranque, lo que es de enorme ayuda para diagnosticar fallos caprichosos.

Interpretar Ntbtlog.txt y otros registros de arranque

Aunque a simple vista Ntbtlog.txt parezca un simple listado de líneas, la clave está en entender qué patrón estamos buscando. En este archivo verás entradas indicando que un controlador se ha cargado correctamente o que se ha omitido.

La gracia está en localizar controladores que fallen justo antes de que se produzca el cuelgue o el reinicio, o aquellos que claramente no pertenecen a Microsoft y podrían estar provocando conflictos (drivers de antivirus, cifrado de disco, soluciones de copia de seguridad, etc.). Combinando esta información con los eventos del Visor de sucesos y, si los hubiera, volcados de memoria, se puede acotar muchísimo el problema.

En muchas ocasiones, los volcados de memoria señalan explícitamente un archivo de controlador concreto (por ejemplo, \Windows\System32\drivers\stcvsm.sys faltante o dañado). Las recomendaciones generales en ese tipo de caso son:

  • Revisar qué funcionalidad aporta ese controlador y si es crítico para el arranque.
  • Si es un driver de terceros no esencial, deshabilitarlo cargando la hive del sistema en el Registro desde WinRE.
  • Ejecutar el Comprobador de archivos de sistema (sfc) en modo sin conexión si se sospecha de corrupción en archivos del sistema.
  • Si se intuye corrupción generalizada del Registro o instalación reciente de múltiples drivers/servicios, renombrar las hives antiguas (añadiendo .old a los nombres en C:\Windows\System32\config) y restaurar las copias de RegBack, intentando luego un arranque normal.

A veces, sobre todo tras una gran actualización de Windows, el problema al reparar con DISM viene de la versión de la imagen de origen. Si la ISO usada para restaurar no coincide lo suficiente con la versión instalada, DISM devuelve el error 0x800f081f (“No se pudieron encontrar los archivos de origen”). En estos casos conviene comprobar con dism /get-wiminfo la versión exacta de la imagen (install.wim o install.esd) y buscar una ISO que realmente se corresponda con la compilación del sistema a reparar.

En definitiva, los registros de arranque como Ntbtlog.txt, el SrtTrail de Reparación de inicio, los volcados de memoria y los logs de DISM y SFC forman un “ecosistema” de información con el que es posible reconstruir lo que pasa en cada arranque: qué se carga, qué se omite, qué se corrompe y qué cambios (controladores, actualizaciones, antivirus o utilidades varias) han roto la cadena. Combinando el uso de estas herramientas con las técnicas de reparación del MBR, BCD, Bootmgr, RegBack y los arranques limpios, las probabilidades de recuperar un Windows que no inicia sin reinstalar desde cero son mucho más altas de lo que parece a primera vista.

Boot Trace en windows 11
Artículo relacionado:
Boot Trace en Windows 11: guía completa para analizar el arranque