Pantalla azul tras instalar un controlador: revertir desde modo de recuperación

Qué se rompió realmente: un modelo mental práctico

Una “instalación de controlador” no es una sola cosa. Normalmente es un paquete:
un controlador en modo kernel (.sys), un paquete INF, una entrada de servicio, quizá controladores filtro,
quizá un co-installer, quizá un auxiliar en modo usuario que telefonea al arranque si puede.
Cuando un controlador rompe el arranque, típicamente lo hace de una de cinco formas:

1. Fallo de driver de arranque: un servicio con Start=0 (BOOT_START) se carga temprano y desreferencia algo incorrecto. Resultado: BSOD instantáneo.
2. Sabotaje en la pila de almacenamiento: un controlador de almacenamiento/NVMe/RAID/controlador filtro cambia cómo se enumeran los discos. Resultado: dispositivo de arranque inaccesible, volumen perdido o confusión con BitLocker.
3. Integridad de código / firma: Windows rechaza un controlador no firmado o bloqueado. Resultado: fallo de arranque, o bucle de recuperación con “no se puede cargar el controlador”.
4. Corrupción de memoria del kernel: el controlador “funciona” hasta que corrompe memoria y colapsas después. Resultado: BSOD no inmediatamente en el logo; tienes unos segundos/minutos.
5. Desajuste de dependencias: el controlador espera otra build de SO, distintas opciones de hipervisor o una pila de vendedor en conflicto. Resultado: fallos aleatorios, a veces sólo en ciertas revisiones de hardware.

Tu trabajo en modo de recuperación no es convertirte en un depurador de kernel. Tu trabajo es conseguir que el sistema arranque
sin borrar datos, y luego hacer un postmortem correcto en un entorno estable.

Una cosa más: los controladores son infraestructura. Trátalos como cambios de configuración en producción.
Las reversiónes deben ser aburridas, reversibles y registradas (incluso si “registradas” es que te tomes una foto de la pantalla porque estás en un aparcamiento).

Guion de diagnóstico rápido (primero/segundo/tercero)

Cuando la máquina no arranca, no tienes el lujo de “explorar”. Usa un bucle cerrado:
identifica la clase de fallo, elige la reversión menos destructiva, confirma el arranque y luego limpia.

Primero: clasifica el BSOD y el comportamiento de arranque

• Choque instantáneo en el spinner/logo → probablemente driver BOOT_START o problema en la pila de almacenamiento.
• Fallos después de que aparece la pantalla de inicio de sesión → a menudo controlador de vídeo, red o seguridad (todavía en modo kernel, pero más tarde).
• Código de detención “INACCESSIBLE_BOOT_DEVICE” → controlador de controlador de almacenamiento, driver filtro o BCD/ruta de dispositivo.
• Menciona un archivo .sys → tienes un sospechoso principal. Anótalo.

Segundo: elige la palanca de reversión más pequeña

• Startup Settings → Modo seguro (carga mínima) si está disponible. Elimina o revierte el controlador desde dentro de Windows.
• WinRE → Restaurar sistema si existen puntos de restauración y puedes permitirte su uso.
• WinRE → Símbolo del sistema para reversión offline: DISM para quitar paquetes de controladores, o registro offline para deshabilitar el servicio del controlador.

Tercero: verifica el arranque, luego refuerza

• Confirma que el sistema arranque dos veces seguidas. Un arranque exitoso puede engañar.
• Recopila logs/dumps. Identifica el paquete controlador raíz y bloquéalo para que no reaparezca.
• Reintroduce controladores de forma intencional (paquete del proveedor o Windows Update), no “lo que encuentre el asistente”.

Cómo entrar en el Entorno de Recuperación de Windows (WinRE) sin empeorar las cosas

WinRE es tu “gestión fuera de banda” para laptops y servidores Windows sin iDRAC/iLO.
No es glamuroso, pero suele ser suficiente.

Formas estándar de acceder a WinRE

• Recuperación automática: tras unos intentos fallidos de arranque, Windows suele entrar en “Preparando reparación automática.” Déjalo. No lo apagues durante el diagnóstico a menos que esté realmente colgado.
• Desde el arranque: interrumpe el arranque 2–3 veces (apagar tan pronto aparezcan los puntos) para forzar la recuperación. Es tosca pero efectiva.
• USB instalador arrancable: “Reparar el equipo” → Solucionar problemas → Opciones avanzadas. Suele ser la ruta más limpia si WinRE en disco está dañado.

Chequeo de la realidad con BitLocker

Si el volumen del SO está protegido con BitLocker, WinRE puede pedir la clave de recuperación antes de permitir el acceso al disco.
Eso no es Windows siendo difícil; es el cifrado haciendo su trabajo. Planea en consecuencia.

Broma #1: Si no tienes la clave de recuperación de BitLocker, no tienes un plan de recuperación—tienes un plan de optimismo.

Evidencia primero: qué recoger antes de “arreglar” nada

Regla de SRE: antes de cambiar el estado, captura suficiente evidencia para aprender del fallo.
De lo contrario “lo arreglarás” hoy y lo repetirás el mes que viene con más confianza y menos cautela. Una combinación peligrosa.

En WinRE, la evidencia es sobre todo: qué instalación de Windows está en qué letra de unidad, qué controladores se añadieron recientemente,
y si un volcado/log apunta a un .sys específico.

• Anota el código de detención exacto y cualquier controlador nombrado (una foto está bien).
• Identifica la letra del volumen de Windows en WinRE (a menudo no es C:).
• Busca minidumps y registros de arranque (si están presentes).
• Lista paquetes de controladores añadidos recientemente offline (DISM puede hacerlo).

El objetivo es simple: poder responder “¿qué eliminamos/deshabilitamos y por qué?”

Vías de reversión desde modo de recuperación (elige la menos destructiva)

Camino A: Modo seguro, luego desinstalar/revertir normalmente

Si puedes entrar en Modo seguro, hazlo. El Modo seguro carga un conjunto mínimo de controladores y servicios.
Eso significa que el controlador problemático podría no cargarse, dándote una ventana estable para eliminarlo como una persona civilizada.

Usa WinRE: Troubleshoot → Advanced options → Startup Settings → Restart, luego elige:
4 (Modo seguro) o 5 (Modo seguro con redes) si necesitas descargar un controlador conocido bueno.

En Modo seguro:
desinstala el software desde Programas y características cuando sea un paquete del proveedor,
o usa la reversión del Administrador de dispositivos cuando sea una actualización de controlador de dispositivo,
o usa pnputil para mayor precisión.

Camino B: Restaurar sistema (rápido, a veces contundente)

Restaurar sistema puede revertir instalaciones de controladores porque los controladores forman parte del “estado del sistema” que rastrean los puntos de restauración.
A menudo es el camino más rápido cuando no sabes qué controlador rompió el arranque. La desventaja:
podrías revertir otros cambios también (actualizaciones, configuraciones).

Úsalo cuando:
el sistema tenga puntos de restauración,
puedas tolerar perder cambios recientes del sistema,
y necesites una vuelta rápida a la capacidad de arranque.

Camino C: Eliminación offline de controladores con DISM (quirúrgico, fiable)

DISM puede inspeccionar y eliminar paquetes de controladores desde una imagen de Windows offline.
Este es el método que usas cuando Modo seguro no arranca y Restaurar sistema no está disponible o es arriesgado.

También es el método que usas cuando quieres una pista de auditoría: “se eliminó oem42.inf que contenía badstor.sys.”

Camino D: Edición offline del registro para deshabilitar el servicio del controlador (bisturí de último recurso)

A veces no puedes eliminar el paquete limpiamente (estado bloqueado, dependencia, pila de proveedor desordenada),
pero puedes evitar que el controlador se cargue cambiando su tipo de inicio.
Eso puede ser suficiente para arrancar y terminar la limpieza desde una sesión normal.

Usa esto con cuidado, especialmente para controladores de almacenamiento. Deshabilitar un miniport de almacenamiento incorrecto es una excelente forma
de convertir “bucle de arranque” en “nunca arranca de nuevo.”

Tareas prácticas (comandos + salidas + decisiones)

Todas las tareas abajo asumen que estás en el Símbolo del sistema de WinRE (o en un símbolo elevado en Modo seguro donde se indica).
El error más común aquí es asumir que la unidad del SO es C:. En WinRE a menudo no lo es.

Task 1: Find the Windows installation drive letter

cr0x@server:~$ diskpart
Microsoft DiskPart version 10.0.19041.1

DISKPART> list vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     D   Windows      NTFS   Partition    237 GB  Healthy
  Volume 1         SYSTEM       FAT32  Partition    100 MB  Healthy    System
  Volume 2     E   Recovery     NTFS   Partition    900 MB  Healthy    Hidden

DISKPART> exit

Qué significa: El volumen de Windows es D:, no C:.
Decisión: Usa D:\Windows para todas las rutas offline abajo.

Task 2: Confirm you’re looking at the right Windows folder

cr0x@server:~$ dir D:\Windows\System32
 Volume in drive D is Windows
 Volume Serial Number is 34E2-9A1C

 Directory of D:\Windows\System32

...snip...

Qué significa: El directorio existe y parece un SO real.
Decisión: Procede; el mapeo de letras es correcto.

Task 3: Check for BitLocker protection status (and whether you need to unlock)

cr0x@server:~$ manage-bde -status D:
BitLocker Drive Encryption: Configuration Tool version 10.0.19041
Volume D: [Windows]
    Size:                 237.00 GB
    BitLocker Version:    2.0
    Conversion Status:    Fully Encrypted
    Percentage Encrypted: 100.0%
    Protection Status:    Protection Off
    Lock Status:          Unlocked
    Identification Field: Unknown
    Key Protectors:
        Numerical Password

Qué significa: El volumen está cifrado pero desbloqueado en WinRE (común si la recuperación ya autenticó).
Decisión: Si estuviera bloqueado, necesitarías manage-bde -unlock D: -RecoveryPassword YOUR-KEY antes de que DISM pueda leerlo.

Task 4: Identify the last boot’s BSOD evidence in the offline event logs

cr0x@server:~$ wevtutil qe /lf:true D:\Windows\System32\winevt\Logs\System.evtx /q:"*[System[(EventID=41 or EventID=1001)]]" /c:5 /rd:true /f:text
Event[0]:
  Log Name: System
  Source: Microsoft-Windows-WER-SystemErrorReporting
  Event ID: 1001
  Level: Error
  Description: The computer has rebooted from a bugcheck.  The bugcheck was: 0x0000007B ...
Event[1]:
  Log Name: System
  Source: Microsoft-Windows-Kernel-Power
  Event ID: 41
  Level: Critical
  Description: The system has rebooted without cleanly shutting down first.

Qué significa: Tienes un bugcheck code (aquí 0x7B, clásico dispositivo de arranque inaccesible).
Decisión: Concéntrate en controladores del controlador de almacenamiento/filtros e instalaciones recientes relacionadas con almacenamiento.

Task 5: Check for minidumps and copy them somewhere safe

cr0x@server:~$ dir D:\Windows\Minidump
 Volume in drive D is Windows
 Directory of D:\Windows\Minidump

02/04/2026  08:13 AM           1,245,184 020426-9328-01.dmp
               1 File(s)      1,245,184 bytes

Qué significa: Existe un minidump. Perfecto—esto puede nombrar al controlador culpable más adelante.
Decisión: Cópialo fuera de la caja (USB, recurso de red) antes de cambiar nada, si es posible.

Task 6: List installed third-party driver packages offline (DISM)

cr0x@server:~$ dism /image:D:\ /get-drivers /format:table
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3803

Published Name  Original Name  Inbox  Class Name          Provider Name       Date
-------------  -------------  -----  ------------------  ------------------  ----------
oem12.inf      iaStorVD.inf   No     SCSIAdapter         Intel              01/29/2026
oem21.inf      nvme.inf       No     SCSIAdapter         VendorStorageCo     02/03/2026
oem34.inf      netwtw10.inf   No     Net                 Intel              11/10/2025

Qué significa: Tienes un controlador de almacenamiento añadido recientemente (oem21.inf) con fecha justo antes del fallo.
Decisión: Candidato para eliminación o deshabilitado, pero confirma que no sea el único controlador viable para tu controlador.

Task 7: Inspect a specific driver package for files and version clues

cr0x@server:~$ dism /image:D:\ /get-driverinfo /driver:oem21.inf
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Driver package information:
Published Name: oem21.inf
Original File Name: nvme.inf
Provider Name: VendorStorageCo
Class Name: SCSIAdapter
Class GUID: {4d36e97b-e325-11ce-bfc1-08002be10318}
Driver Version: 02/03/2026 2.1.0.14
Signer Name: Microsoft Windows Hardware Compatibility Publisher

Qué significa: Es clase de almacenamiento, instalado recientemente. Firmado, así que probablemente sea un bug/compatibilidad, no un problema de firma.
Decisión: Si el BSOD es 0x7B, eliminar este paquete es un paso razonable—a menos que hubiera reemplazado el único driver necesario para tu controlador.

Task 8: Remove the suspected driver package offline

cr0x@server:~$ dism /image:D:\ /remove-driver /driver:oem21.inf
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3803

Removing driver package: oem21.inf
[==========================100.0%==========================]
The operation completed successfully.

Qué significa: El paquete se elimina del driver store para esa imagen offline.
Decisión: Reinicia y prueba el arranque. Si sigue fallando, pasa a deshabilitar el servicio o usar un punto de restauración.

Task 9: If you can boot Safe Mode, use pnputil to remove a driver package (online)

cr0x@server:~$ pnputil /enum-drivers
Published Name : oem12.inf
Driver Package Provider : Intel
Class : SCSIAdapter
Driver Version And Date : 01/29/2026 19.6.1.1053
Signer Name : Microsoft Windows Hardware Compatibility Publisher

Published Name : oem34.inf
Driver Package Provider : Intel
Class : Net
Driver Version And Date : 11/10/2025 22.250.1.2
Signer Name : Microsoft Windows Hardware Compatibility Publisher

Qué significa: Puedes ver lo instalado cuando Windows está arriba (incluso en Modo seguro).
Decisión: Usa pnputil /delete-driver oemXX.inf /uninstall para limpieza dirigida, especialmente con paquetes de proveedor que se reinstalan.

Task 10: Enable boot logging to capture which driver loads last (when you can reach Startup Settings)

cr0x@server:~$ bcdedit /store D:\Boot\BCD /set {default} bootlog Yes
The operation completed successfully.

Qué significa: Los próximos intentos de arranque escribirán ntbtlog.txt.
Decisión: Reinicia, deja que falle una vez, y vuelve a WinRE para inspeccionar el registro.

Task 11: Read the boot log offline to see the last loaded driver

cr0x@server:~$ type D:\Windows\ntbtlog.txt
Loaded driver \SystemRoot\system32\ntoskrnl.exe
Loaded driver \SystemRoot\System32\drivers\CLASSPNP.SYS
Loaded driver \SystemRoot\System32\drivers\disk.sys
Loaded driver \SystemRoot\System32\drivers\badstor.sys

Qué significa: El último driver cargado listado es badstor.sys. Eso es una pistola humeante.
Decisión: Elimina su paquete vía DISM o deshabilita su servicio offline.

Task 12: Disable a driver service offline by editing the registry hive (safer than random deletions)

Este es el movimiento de “dejar de cargarlo”. Montas la colmena SYSTEM offline, editas la clave de servicio, desmontas la colmena.

cr0x@server:~$ reg load HKLM\OFFSYS D:\Windows\System32\config\SYSTEM
The operation completed successfully.

cr0x@server:~$ reg query HKLM\OFFSYS\ControlSet001\Services\badstor /v Start
HKEY_LOCAL_MACHINE\OFFSYS\ControlSet001\Services\badstor
    Start    REG_DWORD    0x0

cr0x@server:~$ reg add HKLM\OFFSYS\ControlSet001\Services\badstor /v Start /t REG_DWORD /d 4 /f
The operation completed successfully.

cr0x@server:~$ reg unload HKLM\OFFSYS
The operation completed successfully.

Qué significa: Start=0 (boot start) se convirtió en Start=4 (disabled).
Decisión: Reinicia. Si el sistema arranca, ahora tienes una plataforma estable para eliminar el controlador correctamente e instalar una versión conocida buena.

Task 13: Verify the active control set (avoid editing the wrong one)

cr0x@server:~$ reg load HKLM\OFFSYS D:\Windows\System32\config\SYSTEM
The operation completed successfully.

cr0x@server:~$ reg query HKLM\OFFSYS\Select
HKEY_LOCAL_MACHINE\OFFSYS\Select
    Current    REG_DWORD    0x1
    Default    REG_DWORD    0x1
    LastKnownGood    REG_DWORD    0x2

cr0x@server:~$ reg unload HKLM\OFFSYS
The operation completed successfully.

Qué significa: Current=1 indica que ControlSet001 es el actual.
Decisión: Si Current fuera 2, editarías ControlSet002 en su lugar (o ambas si necesitas doble seguridad).

Task 14: Use Last Known Good Configuration logic (manual hint)

Windows no expone “Última configuración válida” como en versiones antiguas, pero el registro aún la rastrea.
Si un driver de arranque rompió las cosas, forzar un arranque que elija la última configuración válida puede ayudar.
Un enfoque práctico es deshabilitar el controlador en ambos conjuntos de control 001 y 002 si no estás seguro.

cr0x@server:~$ reg load HKLM\OFFSYS D:\Windows\System32\config\SYSTEM
The operation completed successfully.

cr0x@server:~$ reg add HKLM\OFFSYS\ControlSet002\Services\badstor /v Start /t REG_DWORD /d 4 /f
The operation completed successfully.

cr0x@server:~$ reg unload HKLM\OFFSYS
The operation completed successfully.

Qué significa: Deshabilitaste el controlador también en el conjunto alternativo.
Decisión: Esto reduce sorpresas de “arrancó una vez y luego falló otra vez.”

Task 15: Check the offline driver file actually exists (and isn’t a leftover)

cr0x@server:~$ dir D:\Windows\System32\drivers\badstor.sys
 Volume in drive D is Windows
 Directory of D:\Windows\System32\drivers

02/03/2026  06:21 PM           842,752 badstor.sys
               1 File(s)        842,752 bytes

Qué significa: El archivo existe; probablemente se añadió/actualizó recientemente.
Decisión: No lo borres todavía. Prefiere la eliminación del paquete o la deshabilitación del servicio para poder avanzar limpiamente después.

Task 16: If the driver is a filter driver, identify its attach points (offline registry check)

Los controladores filtro de almacenamiento a menudo viven en UpperFilters/LowerFilters y pueden inutilizar el arranque si están mal configurados.

cr0x@server:~$ reg load HKLM\OFFSYS D:\Windows\System32\config\SYSTEM
The operation completed successfully.

cr0x@server:~$ reg query "HKLM\OFFSYS\ControlSet001\Control\Class\{4d36e967-e325-11ce-bfc1-08002be10318}" /v UpperFilters
HKEY_LOCAL_MACHINE\OFFSYS\ControlSet001\Control\Class\{4d36e967-e325-11ce-bfc1-08002be10318}
    UpperFilters    REG_MULTI_SZ    badstorflt

cr0x@server:~$ reg unload HKLM\OFFSYS
The operation completed successfully.

Qué significa: Hay un filtro superior adjunto a la clase de disco. Si está roto, toda la clase puede comportarse mal.
Decisión: Deshabilita el servicio del filtro (o elimina su paquete) en lugar de eliminar valores del registro a ciegas—a menos que tengas evidencia clara de que la entrada del filtro está corrupta.

Task 17: Run an offline system file check (when you suspect collateral damage, not just a driver)

cr0x@server:~$ sfc /scannow /offbootdir=D:\ /offwindir=D:\Windows
Beginning system scan.  This process will take some time.

Beginning verification phase of system scan.
Verification 100% complete.

Windows Resource Protection did not find any integrity violations.

Qué significa: Los archivos centrales de Windows están íntegros.
Decisión: Concéntrate en la reversión del controlador en lugar de reparaciones del SO.

Task 18: Check the disk for filesystem issues (especially after crash loops)

cr0x@server:~$ chkdsk D: /scan
The type of the file system is NTFS.
Stage 1: Examining basic file system structure ...
No problems found.

Qué significa: El sistema de archivos parece sano.
Decisión: Si se hubieran encontrado errores, arréglalos antes de perseguir fantasmas de controladores: chkdsk D: /f (puede requerir reinicio).

Tres microhistorias corporativas desde el terreno

Microhistoria 1 (suposición equivocada): “Es solo un controlador de GPU; no puede afectar el arranque”

Una firma de diseño de tamaño medio desplegó una actualización de controlador de gráficos en estaciones de trabajo porque una aplicación del proveedor
se quejaba de “componentes obsoletos.” El despliegue fue un viernes por la noche—porque claro que sí—y el plan era “solo es gráficos, como mucho la app se cuelga.”

El lunes por la mañana, varias máquinas quedaron en bucle de arranque. El código de detención era inconsistente.
Algunas mostraban un archivo .sys relacionado con la pila de GPU. Otras simplemente se reiniciaban antes de que alguien pudiera leerlo.
El helpdesk intentó Reparación de inicio repetidamente. No sirvió de nada, salvo gastar tiempo y confianza.

La suposición equivocada: los controladores gráficos son “carga tardía.” En Windows moderno, los controladores de GPU pueden intervenir temprano
en la ruta de arranque a inicio de sesión, especialmente con inicio rápido, hibernación híbrida y servicios del proveedor que arrancan al inicio.
Un módulo de kernel malo no se preocupa de que sea “solo gráficos.” Si corre en modo kernel, tiene privilegios suficientes para hundir todo.

La solución fue aburrida y quirúrgica: arrancar WinRE, habilitar el registro de arranque, identificar el último controlador de terceros de pantalla cargado,
y luego eliminar el paquete del controlador offline con DISM. Tras restaurar el arranque, fijaron una versión conocida buena
y deshabilitaron actualizaciones automáticas de controladores por política para esa clase de dispositivo hasta que pudieran probar correctamente.

Lección del postmortem: trata las actualizaciones de controladores como cambios de SO. Si no puedes revertir limpiamente, no estás “actualizando”,
estás apostando con menús más bonitos.

Microhistoria 2 (optimización que salió mal): intercambio de controladores de almacenamiento por “más rendimiento”

Una pequeña empresa SaaS compró nuevos NVMe para un par de servidores on‑premise de Windows usados para artefactos de build.
Alguien encontró un “controlador de rendimiento” del proveedor y una utilidad de gestión que prometía mejor manejo de colas y menor latencia.
La ventana de cambios fue corta. El argumento era simple: “es el controlador recomendado por el proveedor.”

El controlador se instaló limpiamente y el servidor arrancó bien una vez. Luego, tras otro reinicio, apareció INACCESSIBLE_BOOT_DEVICE.
WinRE podía ver el disco, pero Windows no montaba el volumen de arranque a tiempo. Es el tipo de fallo que te hace considerar pasatiempos
como la carpintería, donde al menos las herramientas son honestas sobre ser peligrosas.

Qué pasó: el controlador del proveedor cambió el comportamiento de la pila de almacenamiento de una forma que interactuó mal con la configuración de firmware del sistema.
No estaba “roto” en laboratorio. Estaba roto en su entorno, con su BIOS y su modo de arranque.
La “optimización” introdujo una nueva cadena de dependencias en el arranque.

La recuperación se hizo completamente offline: DISM listó el controlador de clase de almacenamiento instalado recientemente; el equipo lo eliminó del driver store.
Cuando el sistema arrancó de nuevo, mantuvieron el controlador inbox de Microsoft, y en su lugar ajustaron rendimiento donde era más seguro:
opciones del sistema de archivos, exclusiones de antivirus para directorios de artefactos y cachés a nivel de aplicación.

Lección del postmortem: los ajustes de rendimiento que tocan rutas críticas de arranque necesitan pruebas a través de ciclos de reinicio y estados de firmware.
Un cambio que sobrevive un reinicio no está probado; simplemente tuvo suerte.

Microhistoria 3 (práctica correcta pero aburrida): anillos de despliegue y claves de recuperación salvaron el día

Un equipo de TI empresarial gestionaba miles de laptops con cifrado de disco completo habilitado.
Tenían una costumbre que nadie presumía: actualizaciones de controladores por anillos (piloto → temprano → amplio),
y verificaban que las claves de recuperación de BitLocker estuvieran custodiadas y accesibles al personal de guardia.

Llegó una actualización de controlador de Wi‑Fi a través de un paquete interno. En un subconjunto pequeño de máquinas con una revisión de hardware particular,
causó BSODs poco después del inicio de sesión. No en el arranque, pero lo suficiente para que los usuarios dijeran “no enciende.”
El anillo piloto lo detectó en horas.

La respuesta del equipo no fue heroica. Fue procedimental: bloquear la actualización, publicar un runbook corto interno e instruir a los usuarios afectados para que iniciasen en Modo seguro y revertieran el controlador.
Para máquinas que no podían entrar en Modo seguro, el personal de guardia usó WinRE con la clave de recuperación, y luego deshabilitó el servicio del controlador offline.

Volvieron a la normalidad rápidamente porque dos piezas aburridas ya estaban en su lugar:
despliegues por etapas (radio de blast limitado) y acceso garantizado a volúmenes cifrados (custodia de claves).
No hubo súplicas de última hora por claves. No hubo “puedes iniciar como admin” de ida y vuelta.

Lección del postmortem: la diferencia entre un incidente menor y una caída de varios días suele ser una hoja de cálculo aburrida
donde alguien verificó prerrequisitos semanas antes.

Errores comunes: síntoma → causa raíz → solución

1) “Startup Repair no funcionó, así que Windows está corrupto”

Síntoma: Bucle de Reparación Automática; “Startup Repair couldn’t repair your PC.”

Causa raíz: El arranque está bien; un driver de kernel se cae después de que el cargador de arranque hace el handoff.

Solución: Usa WinRE Símbolo del sistema para listar controladores recientes (dism /get-drivers), elimina el paquete sospechoso o deshabilita el servicio offline.

2) “Borré el .sys y ahora está peor”

Síntoma: Nuevo código de detención, o Windows se queja de controlador faltante; la pila de dispositivo falla de otra forma.

Causa raíz: Eliminaste el binario pero dejaste referencias del servicio e INF.

Solución: Prefiere la eliminación del paquete (dism /remove-driver offline o pnputil /delete-driver online). Si ya lo borraste, restaura desde el driver store o reinstala un paquete conocido bueno.

3) “DISM no encuentra la imagen”

Síntoma: Errores de DISM al usar /image:C:\.

Causa raíz: Letra de unidad equivocada en WinRE.

Solución: Usa diskpart → list vol para identificar la partición de Windows, luego usa la letra correcta (a menudo D:).

4) “Deshabilité un controlador de almacenamiento y ahora obtengo INACCESSIBLE_BOOT_DEVICE”

Síntoma: 0x7B tras editar valores Start del registro.

Causa raíz: Deshabilitaste el miniport/RAID/NVMe requerido en lugar del complemento/filtro problemático.

Solución: Vuelve a habilitar el controlador (deja Start como estaba) y en su lugar elimina el filtro de terceros o el paquete reciente; usa punto de restauración si está disponible.

5) “Modo seguro también hace pantalla azul; estoy atascado”

Síntoma: Incluso el Modo seguro falla.

Causa raíz: Driver de arranque, problema en la pila de almacenamiento o enforcement de integridad de código.

Solución: Usa reversión offline: DISM eliminar el paquete, registrar deshabilitar offline. Considera Restaurar sistema si está disponible y es rápido.

6) “El controlador vuelve después de eliminarlo”

Síntoma: Tras la recuperación, Windows Update reinstala el mismo controlador; vuelve el BSOD.

Causa raíz: Las actualizaciones automáticas de controladores reaplican la versión problemática.

Solución: Usa políticas/configuración para bloquear actualizaciones de controladores para esa clase de dispositivo o oculta la actualización; instala una versión conocida buena y fíjala.

7) “WinRE pide la clave de BitLocker y no la tenemos”

Síntoma: No puedes acceder a D:\Windows o ejecutar DISM; el volumen está bloqueado.

Causa raíz: Volumen de SO cifrado y proceso de clave de recuperación faltante.

Solución: Recupera la clave desde el sistema de custodia de la organización o la cuenta Microsoft del usuario. Sin ella, tus opciones se reducen a destructivas.

8) “Eliminé el controlador pero sigue fallando”

Síntoma: Persiste el mismo código de detención.

Causa raíz: El controlador que eliminaste no era el que realmente se cargaba primero, o hay múltiples componentes (filtro + miniport + servicio).

Solución: Habilita el registro de arranque e inspecciona ntbtlog.txt; revisa filtros de clase; elimina/deshabilita el componente que realmente se carga.

Listas de verificación / plan paso a paso

Checklist 1: Secuencia de recuperación de riesgo mínimo

1. Entra en WinRE (recuperación automática o USB instalador).
2. Anota el código de detención y cualquier archivo .sys mencionado.
3. Abre Símbolo del sistema. Identifica la letra del volumen de Windows con diskpart.
4. Comprueba el estado de BitLocker; desbloquea si es necesario.
5. Intenta Startup Settings → Modo seguro. Si arranca, desinstala/revierte el controlador normalmente.
6. Si Modo seguro falla, lista controladores offline con DISM; busca controladores no inbox recientes que coincidan con la hora del fallo.
7. Elimina el paquete de controlador sospechoso offline con DISM.
8. Reinicia. Si sigue fallando, habilita registro de arranque con bcdedit, reproduce un fallo y luego inspecciona ntbtlog.txt.
9. Si el controlador identificado sigue bloqueando el arranque, deshabilita su servicio offline (pon Start=4 en el conjunto de control correcto).
10. Una vez arrancado, estabiliza: instala un controlador conocido bueno, bloquea la versión mala para que no vuelva, recoge dumps/logs para la causa raíz.

Checklist 2: Si el código de detención es INACCESSIBLE_BOOT_DEVICE (0x7B)

1. Asume la ruta de almacenamiento. No deshabilites controladores al azar.
2. Usa DISM para listar controladores de clase de almacenamiento y ordena por fecha (mentalmente, observando la salida).
3. Elimina primero el paquete de controlador de almacenamiento/filtro de terceros más nuevo.
4. Si editaste el registro, verifica que no hayas deshabilitado el miniport requerido.
5. Busca filtros de clase de disco (UpperFilters/LowerFilters) y deshabilita el servicio del filtro si hace falta.
6. Sólo entonces considera reparaciones más profundas (SFC/CHKDSK) si la evidencia sugiere problemas en el sistema de archivos.

Checklist 3: Si el BSOD nombra un .sys

1. Busca el archivo en disco: D:\Windows\System32\drivers\name.sys.
2. Usa DISM driver info para mapearlo a un paquete INF si es posible.
3. Elimina el paquete con DISM (offline) o pnputil (Modo seguro/online).
4. Si la eliminación falla, deshabilita el servicio offline.
5. Arranca, luego reemplaza con una versión conocida buena del OEM o Windows Update (controlado).

Broma #2: “Simplemente reinstala Windows” es el equivalente en TI a arreglar una puerta que chirría mudándote de casa.

Datos interesantes y contexto histórico

• Los controladores de Windows suelen ser servicios. Los controladores de kernel típicamente se registran bajo HKLM\SYSTEM\...\Services con un tipo Start que controla cuándo se cargan.
• Los drivers BOOT_START se cargan antes de que puedas iniciar sesión. Si un driver de arranque falla, incluso el Modo seguro puede colapsar, porque el Modo seguro aún necesita controladores de almacenamiento y de clase centrales.
• INACCESSIBLE_BOOT_DEVICE (0x7B) es un clásico. Aparece cuando Windows no puede hablar con el volumen de arranque—a menudo debido a cambios en el controlador del controlador de almacenamiento o drivers filtro.
• Los paquetes de controladores viven en el driver store. El driver store permite reversión e instalaciones consistentes, pero también significa que “borrar el .sys” no elimina el paquete y puede crear estados parciales.
• DISM puede administrar imágenes offline. Fue construido para gestionar imágenes de Windows, y esa misma maquinaria funciona para un volumen de SO roto desde WinRE.
• Los controladores filtro son potentes y peligrosos. Antivirus, cifrado, backup y herramientas de almacenamiento a menudo usan drivers filtro; un filtro malo puede romper clases enteras de dispositivos.
• Las letras de unidad en WinRE no son estables. Los entornos de recuperación asignan letras de forma distinta a tu SO en ejecución, por eso “C:\Windows” es una trampa frecuente.
• BitLocker cambió la cultura de respuesta a incidentes. El cifrado es bueno, pero obliga a las organizaciones a operacionalizar la custodia de claves y flujos de recuperación—or pagar por ello durante las caídas.
• Windows Error Reporting registra los bugchecks. Incluso cuando los usuarios no pueden leer un BSOD, el sistema suele registrar información del bugcheck y produce minidumps para análisis posterior.

Parafraseando una idea (Werner Vogels): construye sistemas asumiendo que fallos ocurrirán, y enfócate en la recuperación como una característica de primera clase.

Preguntas frecuentes

1) ¿Debería usar Restaurar sistema o DISM para eliminar controladores primero?

Si tienes un punto de restauración y necesitas velocidad, Restaurar sistema está bien. Si quieres precisión y una pista de auditoría clara, usa DISM.
En entornos corporativos, prefiero DISM primero cuando el controlador sospechoso es obvio y crítico para el arranque.

2) ¿Por qué el Modo seguro sigue haciendo pantalla azul?

El Modo seguro es “mínimo”, no “sin controladores”. Drivers de arranque, drivers de clase de almacenamiento y algunos componentes de seguridad siguen cargándose.
Si el fallo está en ese conjunto temprano, Modo seguro no te salvará. Ve offline: DISM o deshabilitar registro.

3) ¿Puedo revertir un controlador sin desinstalarlo?

A veces. Si Windows puede arrancar, la opción “Revertir controlador” del Administrador de dispositivos puede restaurar una versión anterior.
Desde WinRE offline, normalmente eliminas el paquete problemático y luego reinstalas una versión conocida buena tras el arranque.

4) ¿Qué pasa si DISM dice “The driver package could not be installed” o la eliminación falla?

Si estás eliminando offline y falla, comprueba que el volumen esté desbloqueado (BitLocker) y que apuntas a la ruta de imagen correcta.
Si aún falla, deshabilita el servicio del controlador offline (pon Start=4) para conseguir arrancar el sistema y luego limpia desde dentro de Windows.

5) ¿Es seguro deshabilitar un servicio de controlador estableciendo Start=4?

Es seguro cuando deshabilitas un controlador claramente no esencial (auxiliar de GPU, filtro de terceros, dispositivo opcional).
Es arriesgado cuando lo haces con controladores del controlador de almacenamiento. Si deshabilitas el equivocado, Windows no podrá montar el volumen de arranque.

6) Mi BSOD no nombra un controlador. ¿Cómo encuentro al culpable?

Usa logs de eventos offline para obtener códigos de bugcheck, busca minidumps, habilita registro de arranque y revisa instalaciones recientes de controladores con DISM.
Correlaciona por tiempo: qué cambió justo antes de que comenzaran los fallos.

7) Después de recuperar, ¿cómo evito que Windows Update reinstale el controlador malo?

En entornos gestionados, usa controles de política para bloquear actualizaciones de controladores o restricciones por clase de dispositivo.
En máquinas autónomas, puedes desactivar actualizaciones automáticas de controladores e instalar una versión OEM conocida buena.
El objetivo es romper el ciclo “reinstalar → reiniciar → crash”.

8) ¿Eliminar un paquete de controlador borra mis datos?

Eliminar un paquete no debería tocar datos de usuario. El riesgo es operativo: eliminar el controlador de almacenamiento equivocado puede impedir el arranque.
Por eso identificas la letra correcta de Windows, confirmas la clase de driver y cambias una cosa a la vez.

9) Si no puedo desbloquear BitLocker, ¿hay alguna opción no destructiva?

No realmente. Sin la clave de recuperación no puedes acceder al volumen del SO cifrado para eliminar controladores o sacar logs.
Tus opciones se reducen a “conseguir la clave” o “borrar y reinstalar”. Por eso la custodia de claves no es opcional.

10) ¿Reinstalar Windows es alguna vez la opción correcta?

Sí—cuando el sistema es desechable, o cuando perdiste la clave de cifrado, o cuando el SO está verdaderamente irrecuperable.
Pero para un bucle de arranque causado por un controlador en una máquina con estado valioso, reinstalar es una falla de proceso, no una estrategia.

Conclusión: pasos siguientes para evitar la secuela

Revertir un controlador malo desde modo de recuperación es menos cuestión de brujería y más de disciplina:
identifica el volumen de Windows, captura evidencia, elimina o deshabilita la cosa específica que se carga y colapsa, y luego verifica el arranque dos veces.
DISM y las ediciones offline del registro son las herramientas fiables cuando Modo seguro y puntos de restauración no cooperan.

Una vez que vuelves a un arranque normal, no lo llames “hecho.” Haz el seguimiento aburrido:
recopila el minidump, mapea el .sys ofensivo a un paquete de controlador y evita que la versión mala se reinstale.
Luego prueba tu camino de reversión mientras estás tranquilo—no durante el próximo incidente cuando tu única herramienta sea el pánico y un café frío.

Pasos prácticos siguientes (hazlos hoy)

• Verifica que las claves de recuperación de BitLocker estén custodiadas y accesibles al personal de guardia.
• Adopta anillos de despliegue para controladores: primero piloto, luego ampliar.
• Mantén un USB instalador de Windows arrancable (o equivalente) disponible para máquinas críticas.
• Documenta un runbook interno para eliminación offline de controladores con DISM y deshabilitación de servicios offline.
• Tras la recuperación, fija una versión conocida buena del controlador y bloquea el mecanismo problemático de actualización.