El banner es condescendiente. El botón dice Buscar actualizaciones. Haces clic. Gira. Y vuelve como un boomerang:
“Su dispositivo carece de correcciones importantes de seguridad y calidad.” Otra vez. Y otra vez. Y de algún modo siempre parece ser culpa tuya.
Esto no es un caso de “intenta apagar y encender”—aunque reiniciar suele ser el primer paso. Es una pila de Windows Update que está
confundida, bloqueada, corrupta, ligada por políticas, o esperando un prerrequisito específico que nunca llega. Vamos a hacer que llegue.
Qué significa realmente el bucle
Ese mensaje no es un único error. Es la alarma genérica de Windows Update “no puedo llevarte a un nivel de parches conforme”.
Aparece cuando el motor de actualizaciones cree que existen actualizaciones aplicables, pero no puede completar la instalación—o no puede probar que lo hizo.
Eso puede ocurrir por razones mundanas (reinicio pendiente), razones estructurales (store de componentes dañado), o por políticas (WSUS / aplazamiento /
red medida / actualizaciones pausadas). También puede suceder porque Windows Update intenta instalar actualizaciones en el orden incorrecto, especialmente
si la situación del Servicing Stack Update (SSU) está enredada en compilaciones antiguas.
El modelo mental correcto: Windows Update es una tubería con múltiples partes móviles—servicios, directorios de caché, catálogos criptográficos,
un almacén de componentes local, entradas de políticas y un motor de mantenimiento (CBS). El banner aparece cuando la tubería falla continuamente en una etapa,
a menudo sin decirte cuál en la interfaz gráfica.
Trataremos esto como respuesta a incidentes en producción: identificar el subsistema que falla, aplicar la reparación más pequeña y segura, y confirmar con
señales fiables (logs, estado de servicios, IDs de evento). Nada de “limpiadores de registro” aleatorios. Nada de aceite de serpiente para actualizar controladores.
Guía de diagnóstico rápido (verifica 1/2/3)
1) Confirma si estás bloqueado por “reinicio pendiente” o bloqueos de servicing
Si Windows cree que necesita un reinicio, encantado seguirá pidiendo actualizaciones al tiempo que se niega a finalizarlas. Esta es la causa de bucle más común
en flotas reales.
- Comprobar: indicadores de reinicio pendiente en el registro y estado de Windows Update
- Decisión: reiniciar una vez (reinicio limpio), luego volver a comprobar actualizaciones antes de hacer cualquier cosa destructiva
2) Revisa la política y la fuente: Windows Update vs WSUS vs “administrado por su organización”
Una máquina apuntando a WSUS (o parcialmente apuntada a WSUS) puede quedarse atascada: la GUI habla con Microsoft Update, pero el agente está forzado a
usar un servidor interno mal configurado, sin aprobaciones o bloqueado por proxy. Esto produce bucles que parecen corrupción pero
que en realidad son “la política lo hizo”.
- Comprobar: claves de política en el registro y fragmentos de WindowsUpdate.log
- Decisión: arreglar la conectividad/aprobaciones de WSUS o eliminar temporalmente la política (si se permite)
3) Repara la plomería de Windows Update: servicios + caché + component store
Si los servicios no se están ejecutando, si la caché está envenenada o si el component store está corrupto, puedes descargar actualizaciones eternamente y
nunca instalarlas. Aquí es donde reiniciamos SoftwareDistribution/Catroot2 y ejecutamos DISM/SFC.
- Comprobar: estado de servicios, corrupción de carpetas, salud de DISM
- Decisión: resetear componentes de WU, luego reparar el component store, y volver a intentar la actualización
Hechos interesantes y breve historia (porque el contexto ayuda)
- Las “actualizaciones de calidad” se nombraron en Windows 10 cuando Microsoft cambió a actualizaciones acumulativas mensuales en lugar de muchos parches pequeños.
- El Servicing Stack Update (SSU) existe porque Windows necesita actualizar al propio actualizador; si el stack es muy antiguo, las actualizaciones acumulativas más nuevas pueden fallar.
- Windows Update ha tenido varias eras de registro: el antiguo WindowsUpdate.log era estático; las builds modernas lo generan dinámicamente desde trazas ETW.
- SoftwareDistribution no es datos sagrados; es una caché. Caché corrupta causa fallos repetitivos espectaculares.
- Catroot2 trata catálogos criptográficos; si las firmas y catálogos no se pueden validar, las instalaciones fallan aun cuando las descargas tengan éxito.
- WSUS existe desde antes de Windows 10 y fue diseñado para parcheo empresarial controlado—genial cuando se mantiene, una trampa cuando se abandona.
- Delivery Optimization (DoSvc) introdujo distribución peer-to-peer de actualizaciones; puede reducir ancho de banda y también crear rarezas en redes mal configuradas.
- El servicing de Windows usa CBS (Component-Based Servicing); cuando CBS está enfermo, los síntomas aparecen como “actualización fallida” aunque el problema real sea el component store.
- Las funciones de aplazamiento y pausa cambiaron los modos de fallo; una máquina puede “carecer de correcciones” mientras está intencionalmente retenida por política.
Tres mini-historias corporativas desde el campo
Mini-historia #1: El incidente causado por una suposición errónea
Una flota de portátiles del departamento financiero comenzó a mostrar el banner de faltan correcciones tras una renovación trimestral. Soporte hizo lo que suele hacer:
reiniciar, ejecutar el solucionador de problemas, decir a los usuarios “intenten de nuevo mañana”. Una semana después, los escaneos de vulnerabilidades empezaron a gritar. La dirección
preguntó por qué “el parcheo está roto”.
La suposición errónea fue simple: “Si la UI de Windows Update puede comprobar Microsoft, no está gestionado.” En realidad, una GPO había establecido claves de WSUS
años atrás, y luego alguien desactivó a medias el proyecto de migración del servidor WSUS. Los clientes apuntaban a un servicio de actualizaciones interno que ya no existía. Podían hablar con internet, pero el agente no lo usaría.
La solución no fue DISM. Fue higiene de políticas: eliminar claves de WSUS obsoletas, forzar un gpupdate, reiniciar servicios de update y re-escanear.
Las actualizaciones se instalaron de inmediato. El banner desapareció como si nunca hubiera existido, que es exactamente cómo a las políticas problemáticas les gusta burlarse.
Lección: si un sistema está “gestionado”, trátalo como gestionado hasta que se demuestre lo contrario. La UI no es prueba. El registro sí lo es.
Mini-historia #2: La optimización que resultó contraproducente
Un equipo de TI intentó ahorrar ancho de banda en un campus pequeño confiando mucho en Delivery Optimization. Lo ajustaron agresivamente: más compartición entre pares, mayor retención de caché, y la creencia de que “la red puede con ello”. Mayormente lo hizo—hasta que no.
Durante la semana de Patch Tuesday, un subconjunto de máquinas comenzó a entrar en bucle con “faltan correcciones”. Las descargas eran rápidas, las instalaciones fallaban. Los logs mostraban
problemas de validación de firmas y cargas parciales ocasionales. El patrón fue desagradable: afectó a máquinas con Wi‑Fi inestable y a las que se movían entre edificios.
Habían creado la tormenta perfecta: los pares servían contenido rápido, pero la conectividad intermitente provocaba transferencias corruptas o incompletas
que no se revalidaban de forma fiable antes de la instalación. La caché seguía sirviendo los mismos bits malos. Resetear las cachés arregló el problema inmediato.
Reducir las opciones de Delivery Optimization lo solucionó a largo plazo.
Lección: las optimizaciones de distribución son geniales hasta que amplifican la corrupción. Si optimizas la entrega, también optimiza
la validación y la recuperación ante fallos—o solo estás haciendo que las fallas lleguen más rápido.
Mini-historia #3: La práctica aburrida pero correcta que salvó el día
Una empresa regulada tenía una regla aburrida: ventanas de mantenimiento mensuales, reinicio obligatorio dentro de las 24 horas tras la instalación de parches,
y un panel que seguía el estado “reinicio pendiente” por separado de “actualizaciones faltantes”.
Un mes, una actualización de seguridad fuera de banda causó un número más alto de lo habitual de banners de “faltan correcciones”. El equipo de seguridad entró en pánico.
El equipo de operaciones no. Consultaron el panel: la mayoría de máquinas afectadas estaban en “reinicio pendiente”, no en “actualización fallida”.
Forzaron una ventana de reinicio coordinada (con comunicación a usuarios y un plan de reversión). El banner desapareció en la mayoría de máquinas sin
ningún trabajo de reparación. Una pequeña parte restante necesitó reparación del component store, que se manejó con calma porque se había eliminado el ruido inicial.
Lección: la disciplina operacional aburrida reduce incidentes falsos. Los reinicios no son glamorosos, pero tampoco lo es explicarle a los auditores por qué
“planeabas reiniciar la próxima semana”.
Tareas prácticas (comandos, salidas, decisiones)
A continuación hay tareas reales que puedes ejecutar en Windows (PowerShell o CMD). Sí, el prompt parece Linux porque me gustan los prompts previsibles.
Los comandos y rutas son reales en Windows. Ejecuta como Administrador salvo que se indique lo contrario.
Tarea 1: Identificar versión y build de Windows (no adivinar)
cr0x@server:~$ cmd /c ver
Microsoft Windows [Version 10.0.19045.3803]
Qué significa: Necesitas el número de build porque el comportamiento y problemas conocidos de SSU/LCU varían por versión.
Decisión: Si estás en una build antigua (o cercana al fin de soporte), planifica una actualización de enablement o una actualización de característica después de estabilizar las actualizaciones.
Tarea 2: Confirmar que los servicios de Windows Update están presentes y en ejecución
cr0x@server:~$ powershell -NoProfile -Command "Get-Service wuauserv,bits,cryptsvc,msiserver | Format-Table -Auto Name,Status,StartType"
Name Status StartType
---- ------ ---------
wuauserv Stopped Manual
bits Running AutomaticDelayedStart
cryptsvc Running Automatic
msiserver Stopped Manual
Qué significa: wuauserv detenido no siempre es incorrecto (puede iniciarse por disparo), pero si nunca se inicia durante los escaneos de actualización, estás atascado.
Decisión: Si bits o cryptsvc están detenidos/deshabilitados, arregla eso primero. Si los servicios fallan al arrancar, salta a errores del Visor de Eventos (Tarea 11).
Tarea 3: Iniciar los servicios principales y vigilar fallos inmediatos
cr0x@server:~$ cmd /c "net start wuauserv & net start bits & net start cryptsvc"
The Windows Update service is starting.
The Windows Update service was started successfully.
The Background Intelligent Transfer Service service is already running.
The Cryptographic Services service is already running.
Qué significa: Si un servicio se niega a iniciar, probablemente tienes corrupción, problemas de permisos o restricciones por políticas.
Decisión: Si algún servicio falla con “Access is denied” o “The service cannot be started,” detente aquí y diagnostica políticas y software de seguridad.
Tarea 4: Comprobar si Windows cree que hay un reinicio pendiente
cr0x@server:~$ powershell -NoProfile -Command "Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'; Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'"
True
False
Qué significa: True indica un reinicio pendiente por servicing (CBS). Eso por sí solo puede mantenerte en un bucle.
Decisión: Reinicia una vez antes de resets de caché. Si no puedes reiniciar (restricciones de mantenimiento del servidor), acepta que estás solucionando con una mano atada.
Tarea 5: Extraer los últimos 50 eventos del cliente Windows Update para obtener señales
cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational' -MaxEvents 50 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-Table -Wrap"
TimeCreated Id LevelDisplayName Message
----------- -- ---------------- -------
2/5/2026 9:12:10 AM 20 Information Installation Successful: Windows successfully installed the following update...
2/5/2026 9:01:33 AM 31 Error The system failed to install the update with error 0x800f081f
Qué significa: El ID de evento 31 con 0x800f081f suele apuntar a archivos fuente faltantes / problemas del component store.
Decisión: Si ves repeticiones de descargas exitosas pero instalaciones fallidas, prioriza DISM/SFC y reparación del component store (Tareas 9–10).
Tarea 6: Generar un WindowsUpdate.log legible en Windows modernos
cr0x@server:~$ powershell -NoProfile -Command "Get-WindowsUpdateLog -LogPath $env:TEMP\WindowsUpdate.log; Get-Item $env:TEMP\WindowsUpdate.log | Select-Object FullName,Length"
FullName Length
-------- ------
C:\Users\admin\AppData\Local\Temp\WindowsUpdate.log 284901
Qué significa: Ahora tienes un log consolidado construido desde trazas ETW.
Decisión: Búscalo por errores con 0x y por URLs de WSUS. Si detectas endpoints internos de actualización que no esperabas, salta a la Tarea 8.
Tarea 7: Comprobar si existe una política WSUS que fuerza un servidor de actualizaciones inexistente
cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' /s"
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
WUServer REG_SZ http://wsus.corp.local:8530
WUStatusServer REG_SZ http://wsus.corp.local:8530
DisableWindowsUpdateAccess REG_DWORD 0x0
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
UseWUServer REG_DWORD 0x1
Qué significa: UseWUServer=1 fuerza WSUS. Si ese servidor es inalcanzable o está mal configurado, entrarás en un bucle eterno.
Decisión: Si estás en un entorno corporativo, arregla WSUS/proxy/aprobaciones. Si eres propietario del dispositivo, puedes eliminar las claves de política (Tarea 8).
Tarea 8: Deshabilitar temporalmente la política WSUS (solo si tienes permiso)
cr0x@server:~$ powershell -NoProfile -Command "reg add 'HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU' /v UseWUServer /t REG_DWORD /d 0 /f; net stop wuauserv; net start wuauserv"
The operation completed successfully.
The Windows Update service was stopped successfully.
The Windows Update service was started successfully.
Qué significa: Le has dicho al agente que no use WSUS. Esto no anula MDM en todos los casos, y GPO puede volver a aplicarlo más tarde.
Decisión: Intenta inmediatamente un escaneo de actualizaciones. Si funciona, tu bucle era por política/fuente, no por corrupción.
Tarea 9: Reparar el component store con DISM (el verdadero caballo de batalla)
cr0x@server:~$ powershell -NoProfile -Command "DISM /Online /Cleanup-Image /RestoreHealth"
Deployment Image Servicing and Management tool
Version: 10.0.19041.3636
Image Version: 10.0.19045.3803
[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.
Qué significa: DISM arregló el store, o confirmó que está bien. Si falla con errores de fuente, puede que necesites un install.wim como origen (Tarea 10).
Decisión: Si DISM tiene éxito, ejecuta SFC a continuación. Si DISM falla, no sigas intentando a ciegas—resuelve primero el problema de origen.
Tarea 10: DISM con una fuente conocida-buena (cuando Windows Update no puede proveerla)
cr0x@server:~$ powershell -NoProfile -Command "DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:D:\sources\install.wim:1 /LimitAccess"
Deployment Image Servicing and Management tool
Version: 10.0.19041.3636
[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.
Qué significa: Usaste medios de instalación como fuente de reparación, evitando canales de actualización rotos/bloqueados.
Decisión: Si esto tiene éxito donde la Tarea 9 falló, tu entorno está bloqueando contenido de reparación (WSUS sin “Features on Demand”, proxy, o endpoints restringidos).
Tarea 11: Ejecutar SFC para reparar archivos del sistema tras DISM
cr0x@server:~$ cmd /c "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: Archivos protegidos corruptos fueron reparados, lo que puede desbloquear el servicing.
Decisión: Reinicia, luego intenta las actualizaciones otra vez. Si SFC no puede reparar archivos, te diriges hacia una instalación de reparación in-place.
Tarea 12: Resetear la caché de Windows Update de forma segura (SoftwareDistribution y Catroot2)
cr0x@server:~$ cmd /c "net stop wuauserv & net stop bits & net stop cryptsvc & ren C:\Windows\SoftwareDistribution SoftwareDistribution.old & ren C:\Windows\System32\catroot2 catroot2.old & net start cryptsvc & net start bits & net start wuauserv"
The Windows Update service was stopped successfully.
The Background Intelligent Transfer Service service was stopped successfully.
The Cryptographic Services service was stopped successfully.
The Cryptographic Services service was started successfully.
The Background Intelligent Transfer Service service was started successfully.
The Windows Update service was started successfully.
Qué significa: Has forzado a Windows Update a reconstruir sus cachés y catálogos criptográficos.
Decisión: Ejecuta un escaneo de actualizaciones. Si el bucle desaparece, la caché estaba corrupta. Si persiste, pasa a comprobaciones más profundas de política/servicing.
Tarea 13: Vaciar trabajos BITS que pueden quedarse “atorados”
cr0x@server:~$ powershell -NoProfile -Command "Get-BitsTransfer -AllUsers | Select-Object -First 5 DisplayName,JobState; Get-BitsTransfer -AllUsers | Remove-BitsTransfer"
DisplayName JobState
----------- --------
WU Client Download Transferring
Qué significa: Los trabajos BITS pueden colgarse o fallar repetidamente; eliminarlos fuerza un reintento limpio.
Decisión: Si ves estados interminables Transferring/Error, límpialos y re-escanéa. Si reaparecen y fallan inmediatamente, sospecha de proxy/inspección TLS.
Tarea 14: Comprobar espacio en disco y espacio libre en la unidad del sistema (sí, en serio)
cr0x@server:~$ powershell -NoProfile -Command "Get-PSDrive -Name C | Select-Object Used,Free | Format-List"
Used : 227.91 GB
Free : 1.84 GB
Qué significa: Poco espacio en disco hace que las actualizaciones acumulativas fallen de formas que la UI no explica claramente.
Decisión: Si el espacio libre está por debajo de ~10–15 GB en Windows 10, para y recupera espacio antes de seguir. Si no, solo generarás más logs y tristeza.
Tarea 15: Verificar sincronización horaria y cadena de certificados
cr0x@server:~$ cmd /c "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 8:52:14 AM
Source: time.windows.com
Qué significa: Hora incorrecta rompe TLS y la validación de firmas, llevando a fallos de catálogo y al infame bucle.
Decisión: Si la hora no está sincronizada o está muy desajustada, arréglala antes de perseguir corrupción de actualizaciones.
Tarea 16: Buscar errores del servicing stack / CBS en el log de CBS
cr0x@server:~$ powershell -NoProfile -Command "Select-String -Path C:\Windows\Logs\CBS\CBS.log -Pattern 'error','0x800f','CSI' | Select-Object -First 10"
C:\Windows\Logs\CBS\CBS.log:... Error CSI 00000001 (F) 0x800f081f ...
C:\Windows\Logs\CBS\CBS.log:... Error CBS Failed to resolve package ...
Qué significa: CBS te dice lo que la GUI se niega a decir: la resolución de paquetes y errores del component store.
Decisión: Repetidos 0x800f081f apuntan a fuentes faltantes; fallos repetidos de paquetes pueden indicar problemas de orden SSU/LCU o corrupción de componentes.
Broma #1: Windows Update es el único compañero de piso que me pidió la renta cada mes y aun así dijo que el apartamento no cumplía con el código.
Errores comunes: síntoma → causa raíz → solución
Aquí es donde la mayoría de las investigaciones se descarrilan: la gente trata cada fallo como corrupción y empieza a borrar carpetas.
No lo hagas. Empareja los síntomas con los modos de fallo.
1) Síntoma: El banner se repite después de que aparece brevemente “Estás actualizado”
- Causa raíz: El escaneo de actualización se completa, pero la detección de instalación falla debido a reinicio pendiente o finalización post-instalación fallida.
- Solución: Comprueba claves de reinicio pendiente (Tarea 4), reinicia y luego revisa eventos de WindowsUpdateClient Operational (Tarea 5).
2) Síntoma: “Administrado por su organización” y las actualizaciones nunca avanzan
- Causa raíz: Política WSUS/MDM que fuerza fuente interna de actualizaciones o reglas de aplazamiento; a veces una configuración de WSUS medio eliminada.
- Solución: Inspecciona claves de política (Tarea 7). Si está permitido, deshabilita temporalmente UseWUServer (Tarea 8). Si no, arregla la conectividad/aprobaciones de WSUS.
3) Síntoma: Las descargas tienen éxito, las instalaciones fallan con 0x800f081f / 0x800f0831
- Causa raíz: Corrupción del component store o fuente de reparación faltante; a veces el dispositivo no puede acceder al contenido de Microsoft por proxy/inspección TLS.
- Solución: DISM RestoreHealth (Tarea 9). Si falla, usa una fuente WIM (Tarea 10). Luego ejecuta SFC (Tarea 11).
4) Síntoma: Error 0x8024a105 o comportamiento aleatorio “inténtalo más tarde”
- Causa raíz: Inestabilidad del servicio Windows Update, interrupciones de red, o caché local corrupta causando timeouts repetidos.
- Solución: Reinicia servicios (Tareas 2–3), limpia trabajos BITS (Tarea 13), resetea SoftwareDistribution/Catroot2 (Tarea 12).
5) Síntoma: La actualización se instala y luego hace rollback durante el reinicio
- Causa raíz: Conflictos de controladores, presión de espacio en disco, errores de sistema de archivos, o software de seguridad que altera archivos del sistema.
- Solución: Asegura espacio libre (Tarea 14). Revisa el CBS log (Tarea 16). Considera deshabilitar temporalmente el AV de terceros durante la instalación (si la política lo permite).
6) Síntoma: Las actualizaciones fallan solo en portátiles fuera del VPN
- Causa raíz: Política dividida: WSUS requerido pero accesible solo por VPN, o ajustes de proxy válidos solo en la red corporativa.
- Solución: Confirma claves WSUS (Tarea 7). Asegura la ruta de red correcta o cambia esos dispositivos a Microsoft Update cuando estén fuera de VPN.
7) Síntoma: “Faltan correcciones importantes” pero no aparecen actualizaciones en la lista
- Causa raíz: Desajuste de metadatos de detección, caché de actualizaciones atascada, o la UI muestra un estado de conformidad obsoleto.
- Solución: Resetea caché (Tarea 12), regenera WindowsUpdate.log (Tarea 6), re-escanéa.
8) Síntoma: Todo parece normal, pero el bucle persiste durante meses
- Causa raíz: El dispositivo está fuera de soporte / en una build que no puede recibir ciertas actualizaciones, o se requiere una actualización de característica para continuar.
- Solución: Confirma la build (Tarea 1). Planifica una actualización de característica o una instalación de reparación in-place. Deja de intentar “arreglar” una base no soportada.
Listas de verificación / plan paso a paso
Lista A: Secuencia mínima y más segura (la mayoría de máquinas)
- Comprobar estado de reinicio pendiente (Tarea 4). Si hay pendiente, reinicia una vez.
- Confirmar que los servicios no están deshabilitados (Tarea 2). Iniciarlos (Tarea 3).
- Comprobar el event log por un código de error real (Tarea 5). Anótalo.
- Verificar espacio en disco (Tarea 14). Si es bajo, libera espacio antes de continuar.
- Ejecutar DISM RestoreHealth (Tarea 9).
- Ejecutar SFC (Tarea 11).
- Resetear SoftwareDistribution + Catroot2 (Tarea 12).
- Reiniciar.
- Escanear e instalar actualizaciones otra vez.
Lista B: Si la máquina está “gestionada” (realidad empresarial)
- Comprobar claves de política WSUS/WindowsUpdate (Tarea 7).
- Confirmar que la fuente de actualización es accesible (red/DNS/proxy). No asumas.
- Si está permitido, establece temporalmente
UseWUServer=0(Tarea 8) para aislar si el problema es WSUS. - Si el problema es WSUS, arregla las aprobaciones/sincronización del servidor o el targeting del cliente—no la caché del cliente.
- Si el problema no es WSUS, continúa con DISM/SFC y reset de caché.
Lista C: Cuando DISM falla (no te enrosques)
- Captura el error del output de DISM y de los eventos WindowsUpdateClient.
- Prueba DISM con fuente WIM y
/LimitAccess(Tarea 10). - Confirma sincronización horaria (Tarea 15) y restricciones por proxy/inspección TLS.
- Si las reparaciones siguen fallando, programa una instalación de reparación in-place (mantiene apps/datos) en lugar de reintentos sin fin.
Broma #2: Si borras carpetas de Windows al azar para arreglar actualizaciones, básicamente estás “recolectando basura” con un lanzallamas.
Qué evitar (lo que lo empeora)
- No ejecutes “scripts de debloat” en máquinas de producción y luego te quejes de que Windows Update está roto. Muchos de esos scripts eliminan dependencias de servicing.
- No deshabilites permanentemente los servicios de Windows Update para “evitar interrupciones”. Tendrás interrupciones más adelante, en el peor incidente posible.
- No uses “arregladores” de actualizaciones de terceros que prometen reparación con un clic. A menudo solo eliminan cachés y ocultan la causa raíz real.
- No luches contra WSUS con ajustes locales si estás en un entorno gestionado. GPO siempre gana eventualmente.
Una cita de operaciones (idea parafraseada)
idea parafraseada: La esperanza no es una estrategia.
— General H. Norman Schwarzkopf (comúnmente citado en cultura de ops; parafraseado)
Preguntas frecuentes
1) ¿El mensaje “faltan correcciones importantes de seguridad y calidad” siempre es exacto?
Es exacto en el sentido de que Windows cree que no estás completamente parcheado. No es fiable respecto al porqué. El mensaje es un indicador de conformidad,
no un diagnóstico.
2) ¿Siempre debo resetear SoftwareDistribution primero?
No. Comprueba reinicio pendiente y políticas primero. Resetear cachés es seguro, pero puede ocultar el problema real y costarte tiempo en volver a descargar
grandes acumulativos.
3) ¿Qué hago si estoy en un portátil corporativo y no tengo derechos de administrador?
Aún puedes recopilar señales: versión de Windows (Tarea 1), entradas del visor de eventos (Tarea 5 si está permitido), y si el dispositivo está gestionado.
Luego pásalo a IT. La parte útil es el código de error y si WSUS está impuesto.
4) ¿Por qué DISM a veces se queda mucho tiempo en un porcentaje?
DISM realiza operaciones largas de servicing y puede parecer detenido mientras procesa manifiestos o repara el component store. Si hay actividad de disco, dale tiempo.
Si realmente se estanca por horas sin actividad, puede haber problemas de disco o sistema de archivos.
5) ¿Necesito instalar SSU antes que LCU?
Históricamente, sí—SSU primero. En builds recientes de Windows 10, SSU y LCU a menudo se combinan o se manejan más suavemente, pero aún existen prerrequisitos relacionados con SSU.
Si los logs de CBS se quejan de componentes del servicing stack, trata SSU como una dependencia de primera clase.
6) ¿Puede el antivirus o la protección endpoint causar este bucle?
Sí. Algunos productos interceptan cambios del sistema y pueden bloquear operaciones de servicing, especialmente durante fases de reinicio. La prueba limpia es
deshabilitar temporalmente el producto (si la política lo permite) y reintentar. Si lo arregla, coordina una exclusión o una actualización con tu equipo de seguridad.
7) Reseteé los componentes de Windows Update y sigue el bucle. ¿Ahora qué?
Sube en la pila: revisa política/WSUS, luego DISM con una fuente conocida-buena, luego considera una instalación de reparación in-place. También verifica espacio en disco
y sincronización de tiempo—dos causas aburridas que se hacen pasar por “corrupción misteriosa”.
8) ¿Renombrar Catroot2 romperá cifrado o BitLocker?
Renombrar C:\Windows\System32\catroot2 es un paso estándar de reparación de Windows Update y no rompe BitLocker.
Fuerza la regeneración de catálogos para la validación de actualizaciones. Debes detener cryptsvc primero (Tarea 12).
9) ¿Por qué vuelve a ofrecerme la misma actualización?
O bien la actualización nunca se completa (falla/hace rollback), o Windows no puede registrar el estado instalado debido a problemas del component store.
Los event logs y CBS te dirán cuál. Los bucles de re-oferta suelen ser component store, no descarga.
10) ¿Cuándo debería dejar de hacer troubleshooting y re-imaginar?
Si DISM con fuente conocida falla, SFC no puede reparar, y CBS muestra corrupción persistente de paquetes, estás perdiendo tiempo en una máquina que ya no se confía a sí misma.
La instalación de reparación in-place es el paso cortés; re-imaginar es el paso definitivo.
Siguientes pasos (cómo mantenerlo arreglado)
Una vez que rompas el bucle, no te vayas. Haz la solución duradera:
- Imponer reinicios tras la instalación de parches. Al banner le encantan las máquinas que nunca reinician.
- Monitorear espacio en disco en endpoints. C: con 2 GB libres es una falla predecible, no un accidente.
- Limpieza de deriva de políticas: si usas WSUS, mantenlo sano; si no lo usas, elimina las claves y deja de fingir.
- Estandarizar playbooks de reparación: DISM → SFC → reset de caché, con logs capturados antes y después.
- Registrar códigos de error desde eventos de WindowsUpdateClient Operational. La GUI es para sensaciones; los logs son para hechos.
Si no haces nada más: ejecuta las comprobaciones de diagnóstico rápido, arregla primero problemas de política/fuente, luego repara la salud del servicing, y finalmente resetea cachés.
Ese orden evita thrash innecesario y te saca del bucle con el menor daño colateral.