Windows Update atascado: soluciona sin formatear el PC

Qué significa realmente “atascado” (y por qué no siempre es Windows Update)

Cuando la gente dice que Windows Update está “atascado”, normalmente se refiere a uno de estos modos de fallo:

• Interfaz congelada: la app de Configuración muestra un porcentaje fijo, pero las descargas o instalaciones pueden estar ocurriendo en segundo plano.
• Canal de descarga atascado: la máquina no puede obtener metadatos o contenido (proxy, DNS, inspección TLS, comportamientos extraños de Delivery Optimization o caché corrupta).
• Pila de mantenimiento atascada: CBS (Component-Based Servicing) no puede aplicar paquetes debido a corrupción del almacén de componentes, archivos de origen faltantes o una pila de mantenimiento desfasada.
• Fase de reinicio atascada: las actualizaciones se preparan y luego fallan durante el reinicio y hacen rollback en bucle.
• Límite de disco/IO: la actualización está “atascada” porque el almacenamiento es lento, el disco está lleno o el sistema está thrashing por un disco que falla.
• Interferencia de terceros: seguridad endpoint, drivers de filtro de disco, “optimizadores del sistema” o herramientas agresivas de limpieza bloquean actualizaciones o eliminan estado crítico.

La solución depende de cuál de estos casos sea. Por eso no empezamos borrando carpetas a ciegas. Empezamos midiendo.

Una cita para tener a mano:

“La esperanza no es una estrategia.” — idea parafraseada usada a menudo en operaciones e ingeniería de confiabilidad

Y una broma corta, porque te la mereces: los porcentajes de progreso de Windows Update son como los botones del ascensor: presionarlos con más fuerza no los hace ir más rápido.

Guion de diagnóstico rápido (primeras/segundas/terceras comprobaciones)

Primero: ¿realmente está trabajando o está congelado?

1. Comprueba actividad de disco y CPU en el Administrador de tareas (vista Detalles). Si TiWorker.exe, TrustedInstaller.exe o svchost.exe (wuauserv) están ocupados y el disco está activo, puede que estés en una fase lenta pero en progreso.
2. Comprueba espacio libre en disco. Si la unidad del sistema tiene menos de ~10–15 GB libres, las actualizaciones suelen atascarse o fallar a mitad del proceso.
3. Comprueba si estás atascado antes del reinicio o en un bucle de arranque. Si estás atascado en “Trabajando en las actualizaciones” durante el arranque, eso es una rama diferente que “Descargando 0%” en Configuración.

Segundo: identifica la categoría del cuello de botella

1. Ruta de red: ¿DNS/proxy/inspección TLS? En redes corporativas esto es común. En casa suele ser DNS del ISP, VPN o una caché mala.
2. Estado de los servicios de Windows Update: ¿están los servicios correctos en ejecución, atascados o deshabilitados?
3. Salud del almacén de componentes: si DISM/SFC están descontentos, deja de culpar a la interfaz de Update.
4. Salud del almacenamiento: discos lentos o fallando generan síntomas “atascados” que no son específicos de actualizaciones.

Tercero: aplica la solución menos destructiva que encaje con la categoría

1. Restablecimientos seguros: reinicia servicios, limpia SoftwareDistribution y catroot2 (de la forma correcta), intenta de nuevo.
2. Reparar mantenimiento: DISM RestoreHealth, luego SFC, y volver a intentar las actualizaciones.
3. Escalada dirigida: analiza logs, aísla un KB específico, usa el catálogo de actualizaciones/instalación manual o haz una reparación in-place (todavía no un formateo).

Datos interesantes y contexto histórico (6–10 puntos rápidos)

• El mantenimiento de Windows es anterior a “Windows Update”: el modelo Component-Based Servicing (CBS) se remonta a la era de Vista y sigue sosteniendo el mantenimiento moderno.
• La carpeta WinSxS no es un “bug de archivos duplicados”: es un almacén de componentes que permite versiones side-by-side, mantenimiento y rollback—a costa de complejidad y uso de disco.
• Delivery Optimization (DO) cambió las reglas: Windows puede obtener contenido de actualización de pares en tu LAN (o internet, según la política), lo cual es genial hasta que una política o corrupción de caché lo vuelve extraño.
• Existen las Servicing Stack Updates (SSU) porque el propio actualizador se actualiza: cuando la pila de mantenimiento está desfasada, puede no ser capaz de instalar paquetes nuevos correctamente.
• Las actualizaciones acumulativas redujeron la dispersión del “Patch Tuesday”: menos parches individuales, pero una acumulativa rota puede bloquear mucho de una vez.
• Windows Update usa múltiples cachés: no solo SoftwareDistribution; catálogos criptográficos y el estado de BITS también pueden intervenir.
• Antes el WindowsUpdate.log era simple: Windows moderno genera trazas ETL que conviertes en un log legible, genial para ingenieros y molesto para los demás.
• Algunos fallos de actualización son realmente fallos de sistema de archivos/driver: drivers de filtro (AV, cifrado, DLP) pueden provocar fallos de transacción que aparecen como “update atascado”.
• El rollback es una característica con tiempo limitado: el sistema conserva datos de desinstalación por una ventana limitada (varía según versión/configuración), lo que afecta la presión de disco y las opciones de recuperación.

Tareas prácticas: comandos, salida esperada y decisiones (12+)

Todos los comandos abajo asumen que los ejecutas en una consola elevada. Si estás en Windows, abre “Windows Terminal (Admin)” o “Command Prompt (Admin)”. La etiqueta del prompt en los bloques es cosmética; los comandos son reales de Windows.

Tarea 1: Confirma que los servicios relacionados con actualizaciones no estén deshabilitados o atascados

cr0x@server:~$ sc query wuauserv
SERVICE_NAME: wuauserv
        TYPE               : 20  WIN32_SHARE_PROCESS
        STATE              : 4  RUNNING
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

Qué significa: STATE: RUNNING es bueno. Si aparece STOPPED, no pasa nada si no hay actualizaciones en curso; si está deshabilitado o falla al iniciar, es un problema.

Decisión: Si wuauserv no está en ejecución durante un intento de actualización, arráncalo (Tarea 2) y comprueba dependencias (BITS, cryptsvc).

Tarea 2: Inicia servicios centrales (Windows Update, BITS, Crypto)

cr0x@server:~$ net start wuauserv
The Windows Update service was started successfully.

cr0x@server:~$ net start bits
The Background Intelligent Transfer Service service was started successfully.

cr0x@server:~$ net start cryptsvc
The Cryptographic Services service was started successfully.

Qué significa: Si algún servicio falla, el texto del error importa. “Access is denied” sugiere políticas o permisos rotos; “dependency service failed” te señala la siguiente pieza de la cadena.

Decisión: Si los servicios no arrancan, no borres cachés aún; diagnostica la configuración del servicio, permisos o corrupción primero.

Tarea 3: Comprueba espacio libre en disco (el asesino aburrido)

cr0x@server:~$ fsutil volume diskfree c:
Total # of free bytes        :  4294967296
Total # of bytes             : 255852544000
Total # of avail free bytes  :  4294967296

Qué significa: Aquí tienes ~4 GB libres. Eso no es “justo”, es “ruleta de actualizaciones”. Las actualizaciones de características y acumulativas pueden requerir varios GB para preparación, rollback y extracción temporal.

Decisión: Si tienes menos de ~10–15 GB libres, para y libera espacio antes de hacer cualquier otra cosa. Limpiar cachés sin espacio solo crea nuevos modos de fallo.

Tarea 4: Verificación rápida de salud de la unidad del sistema

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

Stage 1: Examining basic file system structure ...
  512000 file records processed.
File verification completed.
Windows has scanned the file system and found no problems.
No further action is required.

Qué significa: Si informa problemas, repara el sistema de archivos antes de culpar a los componentes de actualización. Metadatos corruptos pueden romper la preparación de paquetes y el rollback.

Decisión: Si se encuentran errores, programa una reparación offline: chkdsk c: /f (puede requerir reinicio).

Tarea 5: Comprueba el cliente de Windows Update por estados de error obvios

cr0x@server:~$ usoclient StartScan

Qué significa: Esto dispara un escaneo. No imprimirá mucho. El objetivo es generar actividad en los logs que puedas inspeccionar.

Decisión: Si la interfaz está atascada pero un escaneo genera nuevas entradas en los logs, estás en territorio “interfaz congelada”; pasa a tareas de inspección de logs.

Tarea 6: Obtén un WindowsUpdate.log legible (Windows moderno)

cr0x@server:~$ powershell -NoProfile -Command "Get-WindowsUpdateLog -LogPath $env:TEMP\WindowsUpdate.log"
WindowsUpdate.log written to C:\Users\Administrator\AppData\Local\Temp\WindowsUpdate.log

Qué significa: Ahora tienes un log combinado que puedes abrir con el Bloc de notas. Busca errores repetidos, códigos HTTP, problemas de proxy o “FATAL”.

Decisión: Si ves patrones HTTP 401/407/0x8024402c, trátalo como red/proxy/DNS. Si ves fallos de CBS/paquetes, ve a DISM/SFC.

Tarea 7: Comprueba la cola de BITS (canal de descarga)

cr0x@server:~$ bitsadmin /list /allusers
BITSADMIN version 3.0
BITS administration utility.
(c) Copyright 2000-2003 Microsoft Corp.

{E3C8D2B4-0D3E-4D3D-9C5C-2AABF5C1A7E1} 'WU Client Download' SUSPENDED 0 / 1 0 / 52428800

Qué significa: Un trabajo suspendido puede ser normal si la red está limitada o el trabajo está pausado por política. También puede indicar una cola atascada.

Decisión: Si los trabajos permanecen suspendidos eternamente, reinicia BITS y elimina trabajos problemáticos (con cuidado). En la mayoría de los casos, restablecer componentes de actualización (Tarea 10/11) es más limpio que manipular trabajos de BITS manualmente.

Tarea 8: Comprueba la configuración proxy de WinHTTP (culpable corporativo)

cr0x@server:~$ netsh winhttp show proxy
Current WinHTTP proxy settings:

    Proxy Server(s) :  proxy.corp.local:8080
    Bypass List     :  (none)

Qué significa: WinHTTP proxy lo usan los servicios del sistema (incluidos componentes de actualización) aunque tu proxy de navegador de usuario sea distinto.

Decisión: Si estás fuera de la red o el proxy es incorrecto, restablécelo: netsh winhttp reset proxy. Si estás en la red corporativa, asegúrate de que coincide con la política.

Tarea 9: Confirma que la hora del sistema no mienta (TLS y verificación de firmas)

cr0x@server:~$ w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Last Successful Sync Time: 2/5/2026 9:12:32 AM
Source: time.windows.com

Qué significa: Si la hora está muy desfasada, la validación de certificados falla y las descargas/firmas de actualizaciones pueden romperse de formas no evidentes.

Decisión: Si la sincronización es antigua o la fuente es “Local CMOS Clock”, arregla la sincronización de tiempo antes de perseguir fantasmas de actualización.

Tarea 10: Detén servicios antes de la cirugía en cachés

cr0x@server:~$ net stop wuauserv
The Windows Update service was stopped successfully.

cr0x@server:~$ net stop bits
The Background Intelligent Transfer Service service was stopped successfully.

cr0x@server:~$ net stop cryptsvc
The Cryptographic Services service was stopped successfully.

Qué significa: No puedes modificar de forma segura la caché de actualización mientras los servicios estén escribiendo en ella.

Decisión: Si algún servicio se niega a detenerse, comprueba si hay un reinicio pendiente o un servicio colgado; reinicia una vez (no cinco veces) y vuelve a intentarlo.

Tarea 11: Restablece las cachés de actualización (el clásico, hecho correctamente)

cr0x@server:~$ ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
cr0x@server:~$ ren C:\Windows\System32\catroot2 catroot2.old

Qué significa: Renombrar es más seguro que eliminar. Si esto soluciona el problema, luego puedes borrar las carpetas .old para recuperar espacio.

Decisión: Si el renombrado falla con “in use”, no detuviste los servicios correctos—o algo (software de seguridad, driver de filtro) mantiene handles abiertos. Investiga antes de forzar.

Tarea 12: Inicia servicios y prueba el escaneo otra vez

cr0x@server:~$ net start cryptsvc
The Cryptographic Services service was started successfully.

cr0x@server:~$ net start bits
The Background Intelligent Transfer Service service was started successfully.

cr0x@server:~$ net start wuauserv
The Windows Update service was started successfully.

cr0x@server:~$ usoclient StartScan

Qué significa: Esto fuerza la reconstrucción de cachés y metadatos.

Decisión: Si las actualizaciones ahora pasan del 0%/estados atascados, estabas en tierra de corrupción de caché. Si no, procede a comprobaciones de salud del mantenimiento.

Tarea 13: Comprueba la salud del almacén de componentes (DISM)

cr0x@server:~$ DISM /Online /Cleanup-Image /CheckHealth
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

No component store corruption detected.
The operation completed successfully.

Qué significa: Si indica que hay corrupción, necesitas /RestoreHealth.

Decisión: Si existe corrupción, repárala antes de reintentar actualizaciones. Windows Update depende de que CBS esté sano.

Tarea 14: Repara el almacén de componentes (DISM RestoreHealth)

cr0x@server:~$ DISM /Online /Cleanup-Image /RestoreHealth
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

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

Qué significa: DISM reparó el almacén de componentes usando Windows Update o fuentes locales.

Decisión: Si DISM falla con errores de origen (comunes: 0x800f081f), puede que necesites un ISO montado como fuente. No formatees; proporciona a DISM los archivos correctos.

Tarea 15: Repara archivos del sistema (SFC)

cr0x@server:~$ sfc /scannow
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: SFC reparó archivos del sistema. Si no puede reparar algunos, tendrás que inspeccionar C:\Windows\Logs\CBS\CBS.log y posiblemente volver a ejecutar DISM.

Decisión: Si SFC repara cosas, reinicia y reintenta las actualizaciones. Si SFC no puede reparar, tratalo como un problema de mantenimiento más profundo.

Tarea 16: Comprueba si hay un estado de reinicio pendiente (el bloqueador silencioso)

cr0x@server:~$ reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending"
ERROR: The system was unable to find the specified registry key or value.

Qué significa: La ausencia de la clave suele indicar que no hay bandera de reinicio pendiente de CBS. Si existe, probablemente necesites reiniciar para completar una instalación/desinstalación previa.

Decisión: Si hay un reinicio pendiente, reinicia una vez, luego reintenta las actualizaciones. No encadenes 12 reinicios y lo llames plan.

Tarea 17: Inspecciona historial de actualizaciones rápidamente (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5"
Source        Description      HotFixID  InstalledBy          InstalledOn
------        -----------      -------  -----------          -----------
COMPUTERNAME  Update           KB5034123 NT AUTHORITY\SYSTEM 1/30/2026
COMPUTERNAME  Security Update  KB5033375 NT AUTHORITY\SYSTEM 1/15/2026
COMPUTERNAME  Update           KB5032007 NT AUTHORITY\SYSTEM 12/20/2025
COMPUTERNAME  Update           KB5029920 NT AUTHORITY\SYSTEM 11/18/2025
COMPUTERNAME  Update           KB5028851 NT AUTHORITY\SYSTEM 10/22/2025

Qué significa: Puedes ver si algo se instaló recientemente. Si nada se instala desde hace meses, puede que tengas bloqueos de política o una pila de mantenimiento rota.

Decisión: Si la última actualización es antigua, prioriza comprobaciones de política/proxy/WSUS (Tarea 18) y salud del mantenimiento.

Tarea 18: Comprueba si WSUS/política fuerza un servidor muerto

cr0x@server:~$ reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v WUServer
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
    WUServer    REG_SZ    http://wsus.corp.local:8530

Qué significa: Esta máquina está configurada para usar WSUS. Si no estás en esa red, efectivamente intentas comprar en una tienda que no existe.

Decisión: En entornos gestionados, no anules la política a la ligera. En máquinas no gestionadas, eliminar la política WSUS puede restaurar las actualizaciones directas, pero hazlo con conocimiento (y preferiblemente tras respaldar el estado de la política).

Segunda broma corta, y volvemos al trabajo: Eliminar C:\Windows también “arreglaría” Windows Update, de la misma forma en que quitar un motor arregla una fuga de aceite.

Listas de verificación / plan paso a paso (seguro, luego quirúrgico)

Fase 0: No lo empeores (5 minutos)

1. Conecta la alimentación (portátiles). Los fallos de actualización por apagones de batería son autoinfligidos.
2. Desconecta almacenamiento USB innecesario (especialmente discos externos inestables).
3. Pausa cargas de trabajo intensas de IO: juegos descargando, sincronización en la nube, actividad de discos de VM. Las actualizaciones compiten por el disco.
4. Toma una instantánea rápida de la realidad: anota el estado atascado (0%, 100%, bucle de reinicio) y cualquier código de error.

Fase 1: Comprobaciones rápidas (15–30 minutos)

1. Libera espacio en disco hasta al menos 15–20 GB en C: si es posible (desinstala apps grandes, limpia Descargas, borra temporales). No uses “limpiadores de registro” sospechosos.
2. Reinicia una vez. Un reinicio limpio soluciona muchas transacciones pendientes y deadlocks de servicio.
3. Comprueba servicios (Tarea 1/2). Asegúrate de que BITS, cryptsvc y wuauserv estén en ejecución.
4. Comprueba proxy/hora (Tarea 8/9). Si la hora/proxy está mal, todo lo demás es teatro.

Fase 2: Restablecer componentes de actualización de forma segura (20 minutos)

1. Detén servicios (Tarea 10).
2. Renombra cachés (Tarea 11): SoftwareDistribution y catroot2.
3. Inicia servicios (Tarea 12) y provoca un escaneo.
4. Observa el comportamiento: si las descargas empiezan a avanzar, probablemente esté solucionado. Deja que continúe; no lo interrumpas por diversión.

Fase 3: Reparar salud del mantenimiento (30–90 minutos)

1. DISM CheckHealth y luego RestoreHealth (Tareas 13/14).
2. SFC /scannow (Tarea 15).
3. Reinicia.
4. Vuelve a intentar actualizaciones.

Fase 4: Cuando DISM necesita una fuente (todavía no formatear)

Si DISM falla porque no puede encontrar archivos de origen, usa un ISO de Windows que coincida con tu build. móntalo (doble clic en el ISO) y apunta DISM a install.wim o install.esd.

cr0x@server:~$ DISM /Online /Cleanup-Image /RestoreHealth /Source:WIM:D:\sources\install.wim:1 /LimitAccess
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

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

Qué significa: Reparamos usando una fuente local en lugar de Windows Update.

Decisión: Si esto tiene éxito, ejecuta SFC otra vez y reintenta las actualizaciones. Si falla, puede que tengas un desajuste profundo de imagen del SO o problemas de fiabilidad a nivel de disco.

Fase 5: Instalación de reparación in-place (la opción nuclear que no borra)

Si has reparado el almacén de componentes, restablecido cachés, validado la salud del disco y las actualizaciones siguen fallando, una instalación de reparación in-place puede reemplazar archivos del sistema manteniendo apps y datos. Es básicamente “reinstalar la fontanería del SO” sin demoler la casa.

Regla: Haz esto solo después de recopilar logs y estar seguro de que el almacenamiento está sano. Reparar en una SSD que falla es cómo pasas de “molesto” a “pérdida de datos”.

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

1) “Atascado en 0% descargando”

Síntoma: La descarga nunca comienza; no hay tráfico de red; los reintentos no hacen nada.

Causa probable: Configuración WinHTTP proxy errónea, problemas de DNS, interrupción de inspección TLS o cola BITS atascada.

Solución: Comprueba proxy (Tarea 8), hora (Tarea 9), BITS (Tarea 7). Restablece componentes de actualización (Tareas 10–12) si las cachés están corruptas.

2) “Atascado en 100% instalando” (en Configuración)

Síntoma: La interfaz dice 100% pero no pasa nada durante horas.

Causa probable: El mantenimiento está en curso (disco lento) o CBS está atascado en una transacción.

Solución: Comprueba actividad de disco; asegúrate de tener espacio libre suficiente (Tarea 3). Si realmente no avanza, repara el mantenimiento (Tareas 13–15).

3) Bucle de reinicio interminable tras actualizaciones

Síntoma: “Trabajando en las actualizaciones” y luego reinicio; a veces “No pudimos completar las actualizaciones”.

Causa probable: Un driver específico o driver de filtro falla durante la fase offline; errores del sistema de archivos; espacio insuficiente para rollback; estado de paquete roto.

Solución: Arranca en Inicio avanzado, usa Modo seguro si hace falta, ejecuta chkdsk y DISM/SFC. Elimina software de seguridad/driver añadido recientemente si hay correlación. Restablece cachés de actualización una vez estés estable.

4) Error 0x800f081f (o “no se encontraron archivos de origen”)

Síntoma: DISM falla; las actualizaciones pueden fallar; SFC no puede reparar.

Causa probable: Corrupción del almacén de componentes más incapacidad para obtener fuentes (WSUS mal configurado, máquina offline o fuentes de características opcionales faltantes).

Solución: Usa un ISO coincidente como fuente de DISM (Fase 4) o corrige políticas WSUS/proxy (Tarea 18 + alineación con IT corporativa).

5) “Servicio Windows Update ausente/deshabilitado” tras usar un “debloater”

Síntoma: Las actualizaciones nunca se ejecutan; servicios deshabilitados; errores sobre acceso denegado.

Causa probable: Un script deshabilitó servicios, cambió permisos o eliminó tareas programadas.

Solución: Vuelve a habilitar servicios, repara permisos (a menudo lo más sencillo es una instalación de reparación in-place) y deja de usar scripts de “tuning” en máquinas que necesites confiar.

6) La descarga de la actualización ocurre pero la instalación falla repetidamente

Síntoma: Reintentos de instalación repetidos, mismo KB fallando.

Causa probable: Problemas del almacén de componentes, conflictos de drivers o software de seguridad de terceros interceptando operaciones de archivos.

Solución: DISM/SFC; desactiva/desinstala temporalmente AV de terceros (si la política lo permite) y vuelve a intentar. Si un KB en particular es el problema, instálalo manualmente o bloquéalo hasta que exista una acumulativa que lo reemplace.

Tres microhistorias corporativas desde el frente

Microhistoria 1: El incidente causado por una suposición equivocada

Asumieron que el problema de actualización era “solo internet”. En las notas de helpdesk decían que los portátiles eran remotos, los usuarios tenían Wi‑Fi doméstico y Windows Update se quedaba en 0%. La primera respuesta fue predecible: pide a todos reiniciar el router, desactivar VPN y probar de nuevo.

No funcionó. No durante una semana. El porcentaje atascado era consistente y los códigos de error eran lo bastante vagos como para no servir sin mirar los logs correctos. Un ingeniero finalmente ejecutó netsh winhttp show proxy en una de las máquinas afectadas. Sorpresa: había un proxy corporativo configurado en WinHTTP y forzaba los servicios del sistema, pero los portátiles estaban fuera de la red. El tráfico del navegador funcionaba porque el navegador usaba un proxy a nivel de usuario; Windows Update usaba el proxy del sistema e intentaba alcanzar un nombre interno que no resolvía en redes domésticas.

La suposición equivocada fue sutil: “Si la web funciona, Windows Update debe tener acceso a la red.” En entornos corporativos, eso no es cierto. Los servicios del sistema y los navegadores pueden tomar rutas y políticas de red diferentes.

La solución fue simple y aburrida: cuando los dispositivos están fuera de la red, o aseguras que el proxy sea accesible (vía VPN) o restableces WinHTTP a acceso directo. Después de eso, fue necesario restablecer SoftwareDistribution en un conjunto de máquinas porque los intentos fallidos dejaron estado obsoleto.

La lección duradera no fue sobre proxies. Fue sobre respetar la separación entre la red del usuario y la red del sistema. Windows Update vive en el mundo del sistema.

Microhistoria 2: La optimización que salió mal

Un equipo de ingeniería de escritorio intentó “acelerar el parcheo” confiando fuertemente en Delivery Optimization peer-to-peer entre pisos de la oficina. En el papel era genial: menos descargas repetidas desde internet, distribución más rápida y reducción del uso de WAN.

En la práctica, las oficinas tenían una mezcla de switches y VLANs donde el multicast no era relevante pero el broadcast y el descubrimiento de pares eran… inconsistentes. Algunos subnets tenían aislamiento agresivo de clientes, algunos tenían firewalls de endpoints con reglas desajustadas y algunos portátiles dormían más de lo que estaban despiertos.

El resultado: un grupo de máquinas intentaba obtener cargas útiles de actualización de pares que eran técnicamente “disponibles” en el grafo de DO pero efectivamente inaccesibles o demasiado lentos. Las descargas empezaban, se quedaban estancadas y permanecían en estado suspendido. El helpdesk veía “atascado en 2%” y culpaba a Microsoft. Red culpaba a los equipos. Los equipos culpaban a red. Ya conoces la danza.

Cuando deshabilitaron temporalmente el caching entre pares para los segmentos problemáticos—forzando a los clientes a tirar del origen oficial—el problema desapareció. Luego reintrodujeron DO con un scope más estricto y políticas sensatas, después de mapear la realidad de la red en lugar de confiar en un valor por defecto.

La optimización está bien. La optimización prematura en sistemas distribuidos que no has instrumentado es cómo acabas con una cola de tickets que nunca duerme.

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

Un departamento financiero ejecutaba aplicaciones críticas en máquinas Windows que parchaban en una ventana de mantenimiento estricta. Nada glamuroso: ventanas mensuales, anillos por fases (grupo piloto primero) y un inventario limpio de espacio en disco y métricas de salud.

Un mes, una actualización acumulativa empezó a fallar en un subconjunto de máquinas con errores de instalación y largos tiempos de “instalando”. Porque tenían telemetría base, notaron de inmediato que las máquinas afectadas compartían un rasgo aburrido: sus discos del sistema tenían menos de 8 GB libres. No era un misterio; era matemáticas.

No buscaron tweaks de registro. No ejecutaron “arregladores de Windows Update” aleatorios. Liberaron espacio con limpieza estándar, eliminaron un paquete de instalador en caché usado por una herramienta de despliegue antigua y ampliaron algunas particiones donde el hardware lo permitía.

Después de eso, la misma actualización se instaló correctamente. Sin reparación in-place. Sin reimágenes. Sin fin de semana perdido en adivinanzas.

La “práctica” no fue un comando mágico; fue mantener higiene aburrida: presupuestos de espacio, despliegue por fases y la disciplina de medir antes de actuar. En sistemas de producción, lo aburrido es una característica.

Preguntas frecuentes

1) ¿Es seguro eliminar o renombrar la carpeta SoftwareDistribution?

Sí, cuando detienes primero los servicios de actualización. Renombrar a SoftwareDistribution.old es más seguro que eliminar porque puedes revertir si necesitas inspeccionar el estado antiguo.

2) ¿Y qué hay de catroot2—por qué importa?

catroot2 almacena catálogos criptográficos usados para verificación de firmas. Si está corrupto, las instalaciones pueden fallar de formas que parecen “descarga atascada” o “instalación atascada”. Renómbrala después de detener cryptsvc.

3) DISM RestoreHealth se queda en 62% (u otro número). ¿Está congelado?

A menudo está trabajando. El progreso de DISM no es lineal y puede pausar mientras procesa grandes manifiestos. Si continúa la actividad de disco y el proceso consume CPU, déjalo. Si se queda horas sin IO y sin CPU, investiga (salud de disco, registros de eventos, disponibilidad de fuente).

4) SFC dice que encontró archivos corruptos pero no pudo reparar algunos. ¿Ahora qué?

Ejecuta DISM /RestoreHealth primero, luego vuelve a ejecutar SFC. Si aún no puede reparar, inspecciona C:\Windows\Logs\CBS\CBS.log por los archivos específicos y considera una instalación de reparación in-place.

5) ¿Por qué Windows Update dice 100% pero nunca termina?

Porque “descargado” e “instalado” no son lo mismo que “comprometido”. Las actualizaciones preparan payloads y luego aplican cambios vía CBS y a veces durante el reinicio. Discos lentos, poco espacio o problemas del almacén de componentes pueden hacer que la fase final lleve horas o falle.

6) ¿Debería usar herramientas de terceros de “reparación de Windows Update”?

Normalmente no. Muchas son wrappers alrededor de los mismos restablecimientos que puedes hacer tú, más limpieza adicional que puede romper el mantenimiento o las políticas. En empresa, además pueden violar la configuración base.

7) Estoy en un PC corporativo. ¿Puedo restablecer la configuración WSUS para arreglarlo?

No sin coordinarlo. Si la política apunta a WSUS, hay una razón (cumplimiento, pruebas, ancho de banda). Lo correcto es confirmar que puedes alcanzar WSUS (VPN) o pedir a IT que ajuste la política para escenarios remotos.

8) ¿Un SSD que falla puede parecer “Windows Update atascado”?

Sí. Las actualizaciones hacen muchas lecturas/escrituras y comprobaciones de integridad. Un disco con sectores reasignados, timeouts IO o errores de sistema de archivos puede provocar que las instalaciones cuelguen o hagan rollback. Siempre descarta la salud del disco cuando los síntomas son extraños y lentos.

9) ¿Puedo arreglar esto sin perder mis archivos?

En casi todos los casos, sí. El “gran martillo” es una instalación de reparación in-place, que mantiene apps y datos. Un formateo es para cuando el SO está más allá de la reparación económica o el almacenamiento es poco fiable.

10) ¿Por qué a veces fallan las actualizaciones después de scripts de “debloat”?

Porque muchos scripts deshabilitan servicios, eliminan tareas programadas o quitan componentes que la pila de mantenimiento espera. Windows Update está estrechamente acoplado con componentes del SO; tratar Windows como un binario de piezas desmontables es cómo terminas reconstruyéndolo después.

Siguientes pasos (mantenerlo arreglado)

1. Después de una actualización exitosa, borra las carpetas de caché renombradas si el espacio de disco importa:
   • C:\Windows\SoftwareDistribution.old
   • C:\Windows\System32\catroot2.old

   Haz esto solo cuando estés seguro de que las actualizaciones son estables.

2. Establece un umbral de espacio en disco: si C: suele bajar por debajo de 15 GB libres, volverás a revivir esta historia.
3. No “optimices” los servicios de actualización deshabilitándolos. Si necesitas control, usa políticas apropiadas y ventanas de mantenimiento.
4. En máquinas corporativas, verifica la postura de VPN/proxy antes de los días de parcheo. La ruta de red de Windows Update no es la misma que la de tu navegador.
5. Si tuviste corrupción del almacén de componentes, programa tiempo para investigar la causa (problemas de disco, cortes abruptos de energía, herramientas de limpieza agresivas, drivers de filtro). Arregla las causas, no solo los síntomas.

Si no haces nada más: libera espacio, restablece las cachés de actualización de la forma correcta, ejecuta DISM RestoreHealth y luego SFC. Esa secuencia arregla un porcentaje sorprendente de sistemas “atascados”—sin reinstalación total.