Atascado en “Preparando la reparación automática”? La solución de recuperación que realmente funciona

Guía rápida de diagnóstico

Si estás de guardia con tu propio portátil, el tiempo importa. Este es el camino más corto hacia el cuello de botella.

Primero: determina si es un problema de salud del disco

1. Si la máquina hace clics, se congela en el BIOS o las herramientas WinRE se quedan colgadas: sospecha fallo de disco primero. Deja de “reparar”. Empieza la recuperación de datos.
2. En WinRE Command Prompt, ejecuta chkdsk en el volumen del SO (offline). Si tarda una eternidad, reporta sectores defectuosos o “reemplaza clusters defectuosos”, estás ante problemas de medio o corrupción severa.
3. Si SMART indica “Caution/Bad” (desde un sistema externo): trata el disco como defectuoso aunque Windows a veces arranque.

Segundo: confirma el modo de arranque y la cadena de arranque

1. En el firmware (BIOS/UEFI), comprueba si el sistema arranca en modo UEFI o Legacy/CSM.
2. Si el disco es GPT pero el firmware está en Legacy (o viceversa), puedes obtener bucles de “Automatic Repair” y errores raros de “no se encontró dispositivo de arranque”.
3. En WinRE, inspecciona las entradas BCD y la EFI System Partition (ESP). Si la ESP no tiene espacio libre o faltan archivos de arranque, has encontrado al culpable.

Tercero: decide si preservar el estado o cortar pérdidas

1. Si la integridad del disco parece buena: intenta la reparación de arranque (BCD/archivos de arranque) y la reversión (desinstalar actualización, Restaurar sistema).
2. Si la integridad del disco es dudosa: copia los datos primero, y luego repara o reinstala.
3. Si BitLocker está activado y no tienes la clave de recuperación: tus “opciones de reparación” se reducen drásticamente. Concéntrate en obtener la clave.

Una cita para tener en mente: “La esperanza no es una estrategia.” — idea parafraseada usada a menudo en operaciones y fiabilidad.

Qué significa realmente “Preparando la reparación automática”

Windows está intentando arrancar, detecta una falla y redirige al Windows Recovery Environment (WinRE) para intentar remediarla. La frase “Preparando la reparación automática” es el preludio. El bucle ocurre cuando:

• WinRE no puede arreglar la causa raíz (porque no es un problema de configuración “reparable”).
• El intento de reparación falla (por ejemplo: ediciones de BCD bloqueadas, ESP no escribible, errores de disco, volumen bloqueado por BitLocker).
• Windows arranca lo suficiente como para fallar y luego vuelve a activar la reparación (controlador, actualización, sistema de archivos o problemas de registro).

Piénsalo como una cadena: firmware → gestor de arranque → BCD → cargador → kernel → controladores/servicios. “Preparando la reparación automática” es lo que ves cuando la cadena se rompe pero el sistema aún tiene base para intentar recuperarse. Si el disco se está desmoronando, la cadena se rompe en sitios diferentes cada vez—por eso los síntomas son inconsistentes. Si es un problema limpio de configuración de arranque, es repetible y reparable.

Chequeo de realidad: Automatic Repair es una sugerencia educada, no un SLA.

Datos interesantes e historia útil

• WinRE desciende de Windows PE (Preinstallation Environment), creado para hacer la recuperación y el despliegue consistentes entre máquinas.
• El paso de BIOS/MBR a UEFI/GPT cambió dónde viven los archivos de arranque: del MBR/partición activa a una EFI System Partition (ESP) con FAT32.
• El almacén BCD reemplazó a boot.ini desde Windows Vista, permitiendo configuraciones de arranque más flexibles—pero también una nueva forma de romper arranques creativamente.
• Fast Startup (hiberboot) mezcla apagado y hibernación; cuando falla, puedes ver estados “sucios” que complican la recuperación.
• NTFS es resistente, no mágica; lleva un journal de metadatos, pero puede corromperse por pérdida de energía, fallos de controlador o medios defectuosos.
• La EFI System Partition suele ser pequeña (a menudo 100–300MB); puede llenarse con herramientas del fabricante, múltiples cargadores de SO o actualizaciones descuidadas.
• BitLocker cambió las reglas: las herramientas offline pueden ver un volumen cifrado hasta que lo desbloquees con la clave de recuperación.
• “SFC” y “DISM” no son la misma herramienta: SFC repara archivos del sistema usando un almacén de componentes; DISM repara ese almacén (o usa una imagen como fuente).
• Los fallos de firmware de almacenamiento ocurren: errores de firmware en SSD han provocado corrupción de datos y bucles de arranque en varias generaciones de fabricantes.

Antes de tocar nada: protege datos y reduce el riesgo

Mentalidad de producción: la máquina ya está caída. Tu trabajo es evitar convertir “no arranca” en “datos perdidos”. Lo más peligroso en esta situación es ejecutar “arreglos” al azar hasta que des con algo que funcionó en un hilo de foro.

Decide: ¿los datos valen más que la rapidez?

Si es un portátil de trabajo con archivos locales, fotos familiares o una máquina de desarrollo con commits no subidos, asume que los datos son valiosos. Si es una imagen de quiosco que puedes reimager en 20 minutos, puedes ser más agresivo.

Señales de advertencia para priorizar primero la extracción de datos

• Mensajes repetidos de “reparando disco”, pantallas de arranque muy lentas o largas pausas en WinRE.
• CHKDSK reporta sectores defectuosos, “reemplazó clusters defectuosos” o se ejecuta durante horas con I/O intenso.
• Ruidos inusuales de la unidad (HDD), desaparición repentina del disco en BIOS o detección intermitente.
• Perdida de energía inesperada durante actualizaciones recientemente.

Broma #1: Automatic Repair es como una reunión que podría haber sido un correo—mucha actividad, poco progreso.

Tu caja de herramientas de recuperación (WinRE, firmware y un sistema externo)

WinRE: el escalpelo integrado

WinRE te da Símbolo del sistema, Reparación de inicio, Restaurar sistema, Modo seguro (vía Startup Settings) y opciones para desinstalar actualizaciones. Es suficiente para la mayoría de problemas de cadena de arranque y problemas leves de sistema de archivos.

Firmware (UEFI/BIOS): la fuente de la verdad para el modo de arranque

La mitad de los casos de “bucle de Automatic Repair” que veo son realmente desacuerdos de modo de arranque tras alguien restaurar valores por defecto del firmware o activar/desactivar CSM. El firmware te dice si el sistema tiene siquiera una ruta plausible al cargador del SO.

Sistema externo (Linux live USB o WinPE): la plataforma de inspección y extracción

Si no confías en el disco o WinRE sigue fallando, arranca un sistema externo para:

• Comprobar SMART/salud del disco sin las abstracciones de Windows.
• Copiar datos a una unidad externa.
• Inspeccionar particiones (ESP, MSR, OS, recovery) y verificar qué hay en ellas realmente.

Me gusta el medio Linux live para SMART y copias rápidas. Pero WinPE es más amigable para desbloquear BitLocker y herramientas específicas de Windows. Usa lo que puedas manejar bajo estrés.

Tareas prácticas (comandos, salidas, decisiones)

Estas son tareas reales que puedes ejecutar. Cada una incluye: comando, salida de ejemplo, qué significa y qué hacer a continuación. Ejecútalas desde WinRE Command Prompt salvo que se indique otra cosa. En WinRE, las letras de unidad a menudo cambian. No des nada por sentado.

Task 1: Identificar discos y particiones (deja de adivinar letras)

cr0x@server:~$ diskpart
Microsoft DiskPart version 10.0.19041.1

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          476 GB      0 B        *
  Disk 1    Online          931 GB      0 B

DISKPART> list vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     D   WINRE        NTFS   Partition    900 MB  Healthy    Hidden
  Volume 1     C   OS           NTFS   Partition    475 GB  Healthy
  Volume 2          SYSTEM      FAT32  Partition    100 MB  Healthy    System
  Volume 3     E   Data         NTFS   Partition    931 GB  Healthy

Qué significa: Tienes un disco GPT (probablemente UEFI). La ESP es FAT32 y está marcada como System. El volumen OS es C: aquí, pero no asumas que siempre será así.

Decisión: Anota la letra del volumen del SO y el número del volumen ESP. Si no hay un volumen FAT32 “System” en un disco GPT, tus archivos de arranque pueden faltar o el esquema de particiones es anormal.

Task 2: Comprobar si el volumen del SO está bloqueado por BitLocker

cr0x@server:~$ manage-bde -status C:
BitLocker Drive Encryption: Configuration Tool version 10.0.19041
Copyright (C) Microsoft Corporation. All rights reserved.

Volume C: [OS]
[OS Volume]

    Size:                 475.00 GB
    BitLocker Version:    2.0
    Conversion Status:    Fully Encrypted
    Percentage Encrypted: 100.0%
    Protection Status:    Protection On
    Lock Status:          Locked
    Identification Field: Unknown
    Key Protectors:
        Numerical Password

Qué significa: WinRE puede ver el volumen pero está bloqueado. Muchas reparaciones (SFC/DISM/ediciones del registro) fallarán hasta que lo desbloquees.

Decisión: Si tienes la clave de recuperación, desbloquea. Si no, detente y consíguela (cuenta Microsoft, AD, Azure AD, custodia corporativa). Adivinar no es un plan.

Task 3: Desbloquear volumen BitLocker (si procede)

cr0x@server:~$ manage-bde -unlock C: -RecoveryPassword 123456-123456-123456-123456-123456-123456-123456-123456
BitLocker Drive Encryption: Configuration Tool version 10.0.19041
Copyright (C) Microsoft Corporation. All rights reserved.

The password successfully unlocked volume C:.

Qué significa: La partición OS ahora es legible/escribible. Ahora tus reparaciones offline realmente operarán sobre el sistema de archivos real.

Decisión: Considera inmediatamente copiar datos críticos si sospechas problemas de disco. El cifrado no te protege contra la falla física del hardware.

Task 4: Leer el registro de Startup Repair de WinRE para saber qué intentó

cr0x@server:~$ type C:\Windows\System32\LogFiles\Srt\SrtTrail.txt
Startup Repair diagnosis and repair log
---------------------------------------
Number of repair attempts: 1

Session details
---------------------------
System Disk = \Device\Harddisk0
Windows directory = C:\Windows
AutoChk Run = 0
Number of root causes = 1

Test Performed:
---------------------------
Name: Check for updates
Result: Completed successfully. Error code = 0x0

Root cause found:
---------------------------
Boot critical file c:\windows\system32\drivers\disk.sys is corrupt.
Repair action: File repair
Result: Failed. Error code = 0x57
Time taken = 120 ms

Qué significa: Startup Repair encontró algo concreto: un controlador crítico de arranque marcado como corrupto, y no pudo repararlo.

Decisión: Esto apunta a corrupción de archivos del sistema. Probablemente usarás SFC/DISM offline, o revertirás actualizaciones. Si DISK.SYS está corrupto y hay errores de disco, sospecha también problemas de almacenamiento subyacentes.

Task 5: Ejecutar CHKDSK offline (integridad del sistema de archivos primero)

cr0x@server:~$ chkdsk C: /f
The type of the file system is NTFS.
Volume label is OS.

Stage 1: Examining basic file system structure ...
File verification completed.
Stage 2: Examining file name linkage ...
An unspecified error occurred (696e647863686b2e 12f1).

Qué significa: CHKDSK encontró un problema de bajo nivel. Esa firma hex-ish suele aparecer cuando la metadata NTFS está seriamente dañada o el disco se comporta mal.

Decisión: Si CHKDSK no puede completarse, deja de ejecutar más “reparaciones” que generan escrituras masivas. Arranca con medios externos, copia datos y comprueba la salud del disco. Si debes continuar, intenta chkdsk /r solo si aceptas el tiempo de ejecución largo y la tensión adicional sobre un disco que falla.

Task 6: Si CHKDSK se ejecuta, interpreta la línea “bad sectors” como un adulto

cr0x@server:~$ chkdsk C: /f /r
The type of the file system is NTFS.
Stage 4: Looking for bad clusters in user file data ...
Windows replaced bad clusters in file 12345 of name \Windows\System32\config\SYSTEM.
...
Windows has made corrections to the file system.
  4096 KB in bad sectors.

Qué significa: La unidad devolvió sectores ilegibles y Windows remapeó/recuperó lo que pudo. Aunque ahora arranque, el disco no es fiable.

Decisión: Trata esto como una unidad defectuosa (o al menos de alto riesgo). Haz copia de seguridad inmediatamente. Planifica un reemplazo de disco. No celebres instalando más actualizaciones.

Task 7: Verificar archivos de Windows con SFC offline

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

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

Windows Resource Protection found corrupt files and successfully repaired them.

Qué significa: Había archivos del sistema corruptos y SFC pudo repararlos usando el almacén de componentes.

Decisión: Reinicia y prueba. Si SFC no puede reparar, probablemente necesites DISM con una imagen fuente o revertir una actualización.

Task 8: Reparar el almacén de componentes con DISM (offline)

cr0x@server:~$ dism /image:C:\ /cleanup-image /restorehealth
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3693

[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.

Qué significa: La salud de la imagen de Windows se restauró; SFC tiene ahora más posibilidades.

Decisión: Ejecuta SFC offline otra vez después de DISM. Si DISM falla por falta de fuente, usa medios de instalación como fuente (ver tarea siguiente).

Task 9: DISM con una fuente conocida buena desde medios de instalación

cr0x@server:~$ dism /image:C:\ /cleanup-image /restorehealth /source:WIM:D:\sources\install.wim:1 /limitaccess
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.

Qué significa: DISM usó la imagen de los medios de instalación como fuente de reparación en lugar de buscar en Windows Update (que no tienes en WinRE).

Decisión: Si esto tiene éxito, vuelve a ejecutar SFC offline. Si falla con “source files could not be found”, tu número de índice es incorrecto o los medios no coinciden suficientemente con la edición/build.

Task 10: Inspeccionar entradas de arranque (BCD) para ver qué piensa Windows que hace

cr0x@server:~$ bcdedit /enum
Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  en-US

Windows Boot Loader
-------------------
identifier              {default}
device                  partition=C:
path                    \Windows\system32\winload.efi
description             Windows 10
osdevice                partition=C:
systemroot              \Windows

Qué significa: Boot Manager apunta a un archivo EFI en la ESP, y el cargador apunta a C:. Esto es un diseño UEFI sensato.

Decisión: Si device apunta a la partición equivocada, o winload.efi falta, estás en territorio de reparación de arranque (reconstrucción de ESP, reconstrucción de BCD).

Task 11: Reconstruir archivos de arranque en sistemas UEFI con bcdboot (la solución que suele ser correcta)

cr0x@server:~$ diskpart
Microsoft DiskPart version 10.0.19041.1

DISKPART> sel vol 2

Volume 2 is the selected volume.

DISKPART> assign letter=S

DiskPart successfully assigned the drive letter or mount point.

DISKPART> exit
Leaving DiskPart...

cr0x@server:~$ bcdboot C:\Windows /s S: /f UEFI
Boot files successfully created.

Qué significa: Montaste la ESP como S: y copiaste archivos de arranque nuevos en ella, generando un entorno de arranque limpio.

Decisión: Reinicia. Si sigue en bucle, puede que tengas corrupción más profunda del SO, orden de arranque incorrecto en firmware, o problemas de almacenamiento.

Task 12: Sistemas MBR/Legacy: reparar con bootrec (usar solo cuando seas realmente legacy)

cr0x@server:~$ bootrec /fixmbr
The operation completed successfully.

cr0x@server:~$ bootrec /fixboot
Access is denied.

cr0x@server:~$ bootrec /scanos
Total identified Windows installations: 1
[1]  C:\Windows

cr0x@server:~$ bootrec /rebuildbcd
Total identified Windows installations: 1
[1]  C:\Windows
Add installation to boot list? Yes(Y)/No(N)/All(A): y
The operation completed successfully.

Qué significa: /fixmbr y /rebuildbcd funcionaron, pero /fixboot devolvió “Access is denied”, una molestia común en WinRE.

Decisión: Si estás realmente en UEFI, no sigas usando bootrec como si fuera una solución universal. Usa bcdboot y trabaja en la ESP. Si eres legacy y /fixboot falla, a veces se soluciona asegurando que la partición System Reserved esté activa y con formato correcto; pero muchos casos son más fáciles resolviéndolos con bcdboot C:\Windows /s X: hacia la partición de sistema correcta.

Task 13: Encontrar el directorio Windows correcto cuando las letras están cambiadas

cr0x@server:~$ dir C:\Windows
 Volume in drive C is OS
 Volume Serial Number is 8A1B-2C3D

 Directory of C:\Windows

06/01/2025  10:22 AM    <DIR>          System32
06/01/2025  10:22 AM    <DIR>          WinSxS
...

Qué significa: Esto parece un directorio Windows real. En WinRE, a veces Windows está en D: o E:.

Decisión: Verifica siempre la ruta antes de ejecutar SFC/DISM/bcdboot. “Reparé el volumen equivocado” es más común de lo que piensas.

Task 14: Intentar Modo Seguro vía BCD (cuando el arranque normal falla al inicio)

cr0x@server:~$ bcdedit /set {default} safeboot minimal
The operation completed successfully.

Qué significa: El próximo intento de arranque irá en Modo Seguro (controladores mínimos). Útil si un controlador o servicio de terceros está matando el arranque.

Decisión: Si arranca en Modo Seguro, elimina controladores instalados recientemente, AV, controladores filtro de almacenamiento, o revierte actualizaciones. Cuando termines, quita la bandera safeboot:

cr0x@server:~$ bcdedit /deletevalue {default} safeboot
The operation completed successfully.

Task 15: Identificar actualizaciones de Windows recientes (offline) y eliminar una

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

Package Identity                                             State      Release Type
-----------------------------------------------------------  ---------  ------------
Package_for_KB5030211~31bf3856ad364e35~amd64~~19041.3324.1.0 Installed  Update
Package_for_KB5031356~31bf3856ad364e35~amd64~~19041.3448.1.0 Installed  Security Update

Qué significa: Puedes ver lo instalado. Si el bucle empezó justo después de parchear, esto es tu línea de tiempo en un cuadro.

Decisión: Elimina el sospechoso más reciente (especialmente si puedes correlacionar la fecha). Ejemplo:

cr0x@server:~$ dism /image:C:\ /remove-package /packagename:Package_for_KB5031356~31bf3856ad364e35~amd64~~19041.3448.1.0
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

[==========================100.0%==========================]
The operation completed successfully.

Si la eliminación falla por acciones pendientes, puede que tengas que limpiar operaciones pendientes (tarea siguiente).

Task 16: Limpiar acciones “pendientes” que mantienen resucitando una actualización rota

cr0x@server:~$ dism /image:C:\ /cleanup-image /revertpendingactions
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Reverting pending actions from the image...
[==========================100.0%==========================]
The operation completed successfully.

Qué significa: Windows tenía pasos de servicing pendientes que pueden estar rompiendo el arranque cada vez. Revertir puede devolver el sistema a un estado consistente previo.

Decisión: Reinicia. Si arranca, estabiliza inmediatamente: termina las actualizaciones luego, y comprueba la salud del disco.

Task 17: Comprobar y establecer la entrada de arranque del firmware correcta (común en UEFI tras “reparaciones”)

cr0x@server:~$ bcdedit /enum firmware
Firmware Boot Manager
---------------------
identifier              {fwbootmgr}
displayorder            {bootmgr}
                        {a1b2c3d4-e5f6-7890-abcd-ef0123456789}
timeout                 2

Firmware Application (101fffff)
-------------------------------
identifier              {bootmgr}
description             Windows Boot Manager

Qué significa: El firmware conoce “Windows Boot Manager.” Si falta, el orden de arranque del firmware puede apuntar a otro lado (PXE, otro disco, una entrada antigua).

Decisión: Si la entrada del firmware falta o es incorrecta, arréglalo en la configuración BIOS/UEFI: elige el “Windows Boot Manager” correcto ligado al disco correcto. Las reparaciones por software no siempre corrigen reliably las rarezas del firmware del fabricante.

Task 18: Copiar datos desde WinRE (cuando el SO no arranca pero el disco se lee)

cr0x@server:~$ robocopy C:\Users\alice\Desktop E:\Rescue\Desktop /E /R:1 /W:1 /XJ
-------------------------------------------------------------------------------
   ROBOCOPY     ::     Robust File Copy for Windows
-------------------------------------------------------------------------------

  Started : Tuesday, February 4, 2026 10:42:11
   Source : C:\Users\alice\Desktop\
     Dest : E:\Rescue\Desktop\

    Files : *.*

  Options : *.* /E /R:1 /W:1 /XJ

------------------------------------------------------------------------------

               Total    Copied   Skipped  Mismatch    FAILED    Extras
    Dirs :        42        42         0         0         0         0
   Files :       380       380         0         0         0         0
   Bytes :   1.82 g   1.82 g         0         0         0         0
   Times :   0:02:11   0:02:11                       0:00:00   0:00:00

   Speed :            14.2 MBytes/sec.
   Ended : Tuesday, February 4, 2026 10:44:22

Qué significa: Los datos se copiaron con éxito. /XJ evita bucles por junctions; /R:1 /W:1 evita perder la vida en reintentos eternos.

Decisión: Si la copia falla repetidamente en archivos específicos con “read errors”, es otra señal de salud del disco. Prioriza lo que puedas y deja de estresar la unidad.

Broma #2: Si sigues reiniciando el bucle “solo para ver”, felicitaciones—has inventado un nuevo benchmark para el optimismo.

Tres microhistorias corporativas del mundo real

Micro-historia 1: El incidente causado por una suposición errónea

Una empresa mediana tenía una flota de portátiles para desarrolladores. Una mañana, algunos empezaron a buclear en “Preparando la reparación automática” tras una actualización de firmware desplegada por la herramienta del proveedor de hardware. El canal interno de TI se llenó con lo de siempre: “La actualización de Windows lo rompió otra vez.”

El primer responded hizo lo que hace la mayoría bajo presión: ejecutó bootrec /fixmbr y bootrec /fixboot en varios equipos. Algunos empeoraron—ahora ni siquiera encontraban dispositivo de arranque de forma consistente. Fue entonces cuando afloró la suposición: pensaban que todos los portátiles eran BIOS/MBR legacy porque “eso era lo que usábamos años atrás”.

En realidad, los dispositivos eran UEFI/GPT con una pequeña ESP. La actualización de firmware del proveedor había restablecido algunos equipos a modo Legacy/CSM. Windows estaba bien; el firmware simplemente dejó de arrancar la entrada UEFI. Startup Repair no podía arreglar un cambio de firmware, así que quedaba en bucle.

La solución fue aburrida: poner el firmware en UEFI, verificar que “Windows Boot Manager” estuviera primero en el orden de arranque, y en algunos casos reconstruir los archivos de arranque con bcdboot porque intentos previos con bootrec habían enmarañado la situación. Tras eso, la flota se estabilizó.

Lección: No empieces “reparando Windows” cuando el problema es la realidad del firmware. Confirma el modo de arranque y el esquema de particiones pronto.

Micro-historia 2: La optimización que salió mal

Un equipo de imagen empresarial intentó que los portátiles “arrancaran más rápido” y “parcharan más limpio”. Activaron Fast Startup ampliamente, ajustaron algunas configuraciones de energía y estandarizaron políticas de cifrado de disco. Se veía bien en un piloto.

Luego, un pequeño grupo de máquinas empezó a caer en el bucle tras los martes de parches, sobre todo las que se apagaban bruscamente con frecuencia (consultores, viajes, batería baja). El patrón fue feo: flags “dirty” en NTFS, avisos ocasionales de BitLocker y herramientas WinRE que no podían conciliar el estado de forma fiable.

La optimización no era mala en esencia; simplemente amplificó casos límite. Fast Startup puede preservar un estado híbrido más sensible a pérdidas de energía abruptas. Combinado con cifrado y parches agresivos, la vía de recuperación se estrechó. Startup Repair tuvo que navegar un sistema medio hibernado, acciones de servicing pendientes y a veces volúmenes bloqueados.

La remediación no fue “desactivar todo”. Fue dirigida: para la cohorte afectada, desactivar Fast Startup, mejorar la sincronización de instalación de actualizaciones (evitar parches críticos antes de viajes) y aplicar la práctica estándar de “terminar actualizaciones y reiniciar completamente”. También mejoraron el acceso a WinRE y aseguraron que las claves de recuperación estuvieran custodiadas y recuperables bajo presión.

Lección: Los ajustes de rendimiento pueden convertirse en ajustes de fiabilidad. Cuando fallan, no avisan educadamente.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Un departamento financiero tenía un par de docenas de escritorios Windows con software especializado. Eran máquinas monótonas, gestionadas con conservadurismo. El responsable de TI insistía en dos prácticas: (1) copias semanales probadas de perfiles de usuario a un recurso de red, y (2) una lista documentada de recuperación de arranque pegada dentro del armario de la sala de servidores.

Una mañana, un fallo del controlador de almacenamiento durante un evento de energía corrompió algunos volúmenes de arranque. Varias PCs cayeron en el bucle “Preparando la reparación automática” simultáneamente. El pánico habría sido razonable; se acercaba el cierre de mes.

En lugar de eso, el equipo ejecutó la lista de comprobación. Arrancaron WinRE, ejecutaron CHKDSK para evaluar integridad, y en las que tenían sectores defectuosos no perdieron tiempo pretendiendo que las reparaciones fueran una solución a largo plazo. Copiaron lo que pudieron, cambiaron discos donde fue necesario y reimagiaron. Los usuarios estaban de vuelta en pocas horas.

No fue heroico. Fue proceso. Las copias y los runbooks hicieron que “desastre” se convirtiera en “martes molesto”.

Lección: Las prácticas aburridas—copias probadas y runbooks—convierten “desastre” en “molestia administrativa”.

Listas de comprobación / plan paso a paso

Plan A: Quieres arrancar de nuevo sin empeorar las cosas

1. Entra en WinRE (interrumpe el arranque 3 veces, o arranca desde medios de instalación → Repair your computer).
2. Registra lo básico: modo de arranque (UEFI/Legacy), tipo de disco (GPT/MBR), letra del volumen del SO en WinRE.
3. Comprueba el estado de BitLocker con manage-bde -status. Desbloquea si es necesario.
4. Lee SrtTrail.txt. Si nombra un archivo corrupto o faltante de arranque, trátalo como una pista, no como un evangelio.
5. Ejecuta CHKDSK (/f primero). Si aparecen sectores defectuosos, cambia a prioridad de extracción de datos.
6. Ejecuta DISM y luego SFC offline si sospechas corrupción.
7. Arregla archivos de arranque usando el método correcto:
   • UEFI/GPT: monta la ESP y ejecuta bcdboot C:\Windows /s S: /f UEFI.
   • Legacy/MBR: considera bootrec y verifica la partición del sistema activa.
8. Reinicia. Si arranca, estabiliza inmediatamente: comprueba la salud del disco en Windows, programa copias de seguridad y evita reinicios sorpresa durante actualizaciones.

Plan B: Sospechas que el disco está fallando (actúa en consecuencia)

1. Detén reparaciones que generan escrituras intensas (los bucles interminables de CHKDSK /r no son amables).
2. Arranca con medios externos (WinPE o Linux live).
3. Comprueba la salud del disco (SMART) y confirma si el disco se desconecta intermitentemente.
4. Copia datos críticos primero (carpetas de perfil, repositorios, documentos). Usa herramientas que manejen errores y continúen.
5. Reemplaza la unidad, luego reinstala o restaura. Si debes conservar el SO, restaura desde una imagen en vez de “reparar” un disco enfermo.

Plan C: Probablemente es una actualización o controlador malo

1. Intenta Modo Seguro (vía Startup Settings, o establece safeboot en BCD).
2. Desinstala la última actualización vía interfaz de WinRE o DISM offline.
3. Revierte acciones pendientes si el servicing está atascado.
4. Desactiva controladores problemáticos de terceros (AV, filtros de almacenamiento) solo si sabes lo que haces y tienes un plan de reversión.
5. Reinicia y valida. Una vez estable, actualiza controladores con intención, no todos a la vez.

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

1) Síntoma: CHKDSK se ejecuta durante mucho tiempo, el sistema es más lento cada arranque

Causa raíz: Disco fallando (sectores defectuosos) o problemas de controlador que provocan reintentos.

Solución: Prioriza la extracción de datos; reemplaza la unidad. Si debes ejecutar CHKDSK, hazlo una vez para evaluar, no como ritual.

2) Síntoma: “Access is denied” en bootrec /fixboot

Causa raíz: A menudo sistemas UEFI/GPT donde bootrec es la herramienta equivocada, o la ESP/partición del sistema no es accesible correctamente.

Solución: Usa diskpart para montar la ESP y ejecuta bcdboot. Confirma que el firmware esté en UEFI y el orden de arranque sea correcto.

3) Síntoma: Startup Repair dice que “no pudo reparar tu PC” con errores vagos

Causa raíz: Startup Repair es limitada; no puede arreglar hardware de disco, desajustes de modo de arranque de firmware o fallos complejos de servicing.

Solución: Lee SrtTrail.txt, luego elige: ruta de integridad de disco (CHKDSK/SMART) o ruta de cadena de arranque (bcdboot/inspección BCD) o ruta de servicing (DISM/SFC/revert pending).

4) Síntoma: DISM/SFC falla con “Windows Resource Protection could not perform the requested operation”

Causa raíz: Letras de unidad equivocadas, imagen offline inaccesible, o volumen bloqueado por BitLocker.

Solución: Verifica la ruta de Windows con dir. Comprueba el estado de BitLocker; desbloquea. Usa los parámetros correctos /image y /offwindir.

5) Síntoma: Tras “arreglar”, aparece “No boot device found”

Causa raíz: Orden de arranque del firmware cambiado, o archivos de arranque escritos al disco/ESP equivocado (común con múltiples unidades conectadas).

Solución: Desconecta discos externos. En firmware, selecciona la entrada Windows Boot Manager correcta. Vuelve a ejecutar bcdboot apuntando a la ESP correcta en el disco del SO.

6) Síntoma: Arranca una vez y luego vuelve al bucle tras actualizaciones

Causa raíz: Acciones de servicing pendientes, disco inestable, o un controlador que falla temprano en el arranque.

Solución: Usa dism /revertpendingactions, desinstala la última actualización y comprueba la salud del disco. Si arranca en Modo Seguro pero no en normal, sospecha cambios en controladores/servicios.

7) Síntoma: WinRE ve el disco pero no puede acceder a archivos (parece vacío o pide formatear)

Causa raíz: Cifrado BitLocker sin desbloquear, o corrupción severa del sistema de archivos.

Solución: Comprueba con manage-bde. Si no es BitLocker, detén las escrituras y cambia a herramientas de recuperación; considera clonar/imager el disco primero.

8) Síntoma: “Preparando la reparación automática” aparece después de cambiar ajustes del BIOS

Causa raíz: Modo de arranque cambiado (UEFI ↔ Legacy), cambios en Secure Boot, o reinicio del orden de arranque.

Solución: Restaura el modo de arranque correcto y el orden de arranque. Si es necesario, reconstruye archivos de arranque con bcdboot para el modo correcto.

Preguntas frecuentes (FAQ)

1) ¿“Preparando la reparación automática” siempre es un problema de Windows?

No. Puede deberse a configuración de firmware, hardware de disco, comportamiento del controlador de almacenamiento o incluso a un problema de energía. Windows es solo donde se manifiesta el síntoma.

2) ¿Cuál es el comando más eficaz para problemas de arranque UEFI?

bcdboot para reconstruir archivos de arranque en la EFI System Partition—después de identificar y montar correctamente la ESP. Es más limpio que experimentar con ediciones BCD al azar.

3) ¿Debo ejecutar chkdsk /r inmediatamente?

No a menos que aceptes el intercambio. /r es lento y provoca muchas escrituras; en un disco que falla puede acelerar el final. Empieza con /f para evaluar. Si ves sectores defectuosos, prioriza copiar datos.

4) ¿Por qué WinRE muestra mi disco Windows como D: o E:?

Las letras de unidad se asignan dinámicamente en WinRE. El entorno de recuperación es un contexto de SO distinto. Verifica siempre con diskpart y dir antes de ejecutar reparaciones offline.

5) Si reconstruyo el BCD, ¿perderé datos?

Reconstruir la configuración de arranque generalmente no modifica datos de usuario, pero los errores pueden dejar el sistema no arrancable hasta corregirlos. El mayor riesgo es reparar el disco equivocado o escribir en la ESP equivocada cuando hay múltiples discos conectados.

6) ¿Y si BitLocker está activado y no tengo la clave de recuperación?

Entonces tus opciones son limitadas. Puede que no puedas acceder a archivos ni realizar reparaciones. Tu tarea real será recuperar la clave de donde esté custodiada (cuenta Microsoft, AD, o la gestión de dispositivos de la organización).

7) ¿Puede una actualización de Windows por sí sola causar este bucle?

Sí. Las actualizaciones pueden dejar acciones pendientes, reemplazar archivos críticos de arranque o provocar problemas de controladores. Pero “la actualización lo rompió” también es una historia conveniente que puede ocultar problemas de disco que ya estaban gestándose.

8) ¿Cuándo debo dejar de intentar solucionar y reinstalar Windows?

Si la salud del disco es cuestionable, si los archivos del sistema siguen corrompiéndose, o si has gastado más tiempo del que la máquina vale. Reinstalar no es fracaso; es una recuperación controlada. Solo extrae los datos primero.

9) ¿Secure Boot causa bucles de “Preparando la reparación automática”?

Secure Boot puede estar implicado si los cargadores son incompatibles o se alteran las claves, pero es menos frecuente que problemas de orden/modo de arranque. Cambia Secure Boot solo si conoces las implicaciones para tu entorno.

10) ¿Por qué falla Startup Repair aun cuando la solución parece obvia?

Porque es cauteloso y limitado. No siempre reescribirá estructuras de arranque y no puede resolver de forma fiable fallos causados por hardware o cifrado sin desbloqueos explícitos y objetivos correctos.

Conclusión: los siguientes pasos que te mantienen fuera de este bucle

Si estás atascado en “Preparando la reparación automática”, haz tres cosas en este orden: identifica el volumen del SO y el modo de arranque, evalúa la integridad del disco, y luego repara la capa correcta (archivos, servicing, cadena de arranque) con la herramienta menos destructiva.

Pasos prácticos siguientes:

• Después de recuperar el arranque: ejecuta una comprobación completa de salud del disco, verifica las copias de seguridad y registra si el sistema es UEFI/GPT con una ESP que puedas montar.
• Si CHKDSK reportó sectores defectuosos: programa el reemplazo de la unidad. No esperes a que el siguiente bucle sea permanente.
• Si la causa fue un reinicio de firmware u orden de arranque: documenta los ajustes correctos y, en entornos corporativos, controla las actualizaciones de firmware como controlas cambios en producción.
• Si la causa fue una actualización/controlador: mejora la disciplina de despliegue—actualizaciones por fases, baselines de controladores comprobados y claves de recuperación accesibles cuando tu portátil sea un ladrillo caro.

La solución de recuperación que realmente funciona no es un comando mágico. Es negarse a adivinar, no entrar en pánico y tratar el bucle de arranque como un sistema con un modo de fallo medible—porque lo es.