Qué es el archivo Pending.xml y por qué puede bloquear Windows Update

Cuando Windows Update se queda bloqueado por culpa del archivo pending.xml, la sensación de atasco es total: el sistema pide reiniciar una y otra vez, las actualizaciones fallan sin dar mucha pista y herramientas como sfc /scannow se niegan a ejecutarse porque «hay un reinicio pendiente». Es un problema bastante más común de lo que parece, tanto en equipos domésticos como en entornos profesionales con servidores y controladores de dominio.

En este artículo vas a encontrar una guía que recopila y reorganiza soluciones probadas por soporte de Microsoft, técnicos de fabricantes como Dell y administradores de sistemas. Verás desde los métodos más seguros (limpieza de caché de Windows Update, comprobación de disco, SFC y DISM) hasta opciones avanzadas como tratar con pending.xml en C:\Windows\WinSxS o reparar la «tienda de componentes» copiando archivos desde otro equipo sano.

Qué es pending.xml y por qué puede bloquear Windows Update

Dentro de la carpeta C:\Windows\WinSxS hay un archivo llamado pending.xml que Windows utiliza para registrar operaciones pendientes tras una actualización: cambios de archivos del sistema, reemplazo de componentes, ajustes en la tienda de componentes, etc. Ese archivo indica al sistema lo que debe terminar de aplicar en el siguiente reinicio, de ahí que muchas veces veas mensajes tipo «Preparando Windows» o «Aplicando actualizaciones» al arrancar.

El problema viene cuando este archivo se corrompe, se queda a medias o contiene instrucciones que ya no tienen sentido porque la actualización falló. En esos casos, Windows insiste en que hay tareas pendientes, algunas herramientas como el Comprobador de archivos del sistema no arrancan y Windows Update puede encadenar errores (incluido el conocido 80073712, que indica corrupción en la tienda de componentes).

En escenarios más avanzados, como servidores o controladores de dominio, un pending.xml defectuoso puede provocar que determinadas actualizaciones críticas nunca terminen de instalarse, y el administrador se vea atrapado entre la necesidad de actualizar y la imposibilidad de reiniciar a la ligera por motivos de producción.

Síntomas típicos cuando pending.xml bloquea las actualizaciones

Aunque no siempre aparece un mensaje claro, hay una serie de síntomas bastante característicos cuando pending.xml está dando guerra. No es obligatorio que se den todos, pero si reconoces varios, es muy probable que el problema vaya por ahí.

• Windows pide reiniciar una y otra vez para completar actualizaciones, pero tras el reinicio nada cambia.
• Al ejecutar sfc /scannow, el sistema responde que «hay un reinicio pendiente» y no realiza el análisis.
• Las actualizaciones aparecen como Pendiente de instalación y nunca pasan a instaladas, o fallan sin código de error claro.
• A veces se muestran códigos como 80073712 indicando corrupción en la tienda de componentes.
• En algunos casos aparecen mensajes de error de tiempo de ejecución mencionando rutas como C:\Windows\WinSxS\pending.xml.
• En equipos de marca (Dell, Alienware, Inspiron, Latitude, OptiPlex, Vostro, XPS, etc.) el problema puede afectar a módulos OEM preinstalados o a drivers que dependen de actualizaciones concretas.

Cuando mezclas estos síntomas con la imposibilidad de ejecutar herramientas de reparación, queda claro que hay algo atascado en el mecanismo de actualización y que suele estar relacionado con pending.xml y la caché de Windows Update.

Comprobar primero lo básico: reinicios y servicio de Windows Update

Aunque parezca de perogrullo, antes de meterse a tocar archivos delicados conviene revisar las cosas simples que a veces se pasan por alto. Especialmente si estás ayudando a un familiar o usuario no técnico, es buena idea empezar por aquí.

En primer lugar, asegúrate de que el equipo ha realizado un reinicio completo, no una mera reanudación desde suspensión o hibernación. En portátiles es muy frecuente que el usuario cierre la tapa y piense que se ha apagado, cuando en realidad solo ha hibernado, dejando las operaciones pendientes en el aire.

Además, es imprescindible comprobar que el servicio Windows Update está activo y configurado correctamente:

1. Pulsa Windows + R, escribe services.msc y pulsa Aceptar.
2. Localiza el servicio Windows Update, abre sus propiedades con clic derecho.
3. En «Tipo de inicio», asegúrate de que está en Automático.
4. En la pestaña «Iniciar sesión», selecciona Cuenta del sistema local.
5. En «Recuperación», pon «Reiniciar el servicio» al menos en el primer error para que se recupere solo.

Si tras verificar esto sigues con reinicios en bucle o actualizaciones atascadas, entonces ya hay que pasar a soluciones más profundas y específicas.

Limpiar la caché de Windows Update y las carpetas SoftwareDistribution y Catroot2

Una de las causas más habituales de bloqueos al actualizar son los archivos dañados o incoherentes en las carpetas SoftwareDistribution y Catroot2, que Windows usa para almacenar descargas y metadatos de actualización. Restablecerlas suele resolver muchos errores sin necesidad de medidas más agresivas.

El procedimiento recomendado es detener temporalmente varios servicios relacionados con las actualizaciones, renombrar las carpetas para que Windows las recree desde cero y volver a arrancar esos servicios. Es normal que, al ejecutar los comandos, alguno devuelva error si ya estaba detenido; en general, puedes ignorar esos avisos y continuar.

Los pasos básicos son:

1. Abrir un símbolo del sistema con permisos de administrador.
2. Detener los servicios implicados ejecutando, uno por uno:net stop wuauserv
   net stop cryptSvc
   net stop bits
   net stop msiserver
3. Renombrar las carpetas para forzar su recreación:ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
   ren C:\Windows\System32\catroot2 Catroot2.old
4. Volver a iniciar los servicios de actualización:net start wuauserv
   net start cryptSvc
   net start bits
   net start msiserver

Al terminar, es recomendable realizar una limpieza de disco completa para eliminar restos y liberar espacio, lo que en muchos equipos viejos marca la diferencia entre poder instalar un Service Pack o no.

Para ello puedes usar la herramienta integrada de Windows:

1. Pulsa Windows + R, escribe cleanmgr y pulsa Intro.
2. Elige la unidad del sistema (normalmente C:) y pulsa Aceptar.
3. Marca todas las casillas salvo Descargas si no quieres vaciar esa carpeta.
4. Haz clic en «Limpiar archivos del sistema», vuelve a seleccionar la unidad.
5. De nuevo puedes marcar prácticamente todo, evitando Descargas si te interesa conservarla.
6. En la pestaña «Más opciones» puedes desinstalar programas que no uses e incluso borrar todos los puntos de restauración salvo el último, que a veces ocupan varios gigas.

Cuando el proceso haya terminado, vuelve a buscar actualizaciones desde Configuración o Panel de control y comprueba si el comportamiento ha mejorado.

Comprobar y reparar archivos del sistema: SFC, DISM y Repair-WindowsImage

Si el problema no desaparece con el simple reseteo de la caché, hay que comprobar el estado de los archivos del propio sistema operativo. Aquí entran en juego herramientas como el Comprobador de archivos de sistema (SFC) y DISM, o su equivalente en PowerShell.

La idea es que, si hay archivos críticos corruptos o diferentes de los esperados, estas utilidades puedan reemplazarlos por copias limpias desde la caché de componentes o desde la imagen oficial de Windows.

La secuencia habitual sería:

• Abrir Símbolo del sistema como administrador y ejecutar:sfc /scannow
• Si SFC se niega a correr porque «hay un reinicio pendiente», eso refuerza la sospecha de que pending.xml está bloqueando el proceso.
• En ese caso, o si SFC no repara todo, pasa a DISM con estos comandos en orden:DISM /Online /Cleanup-Image /CheckHealth
  DISM /Online /Cleanup-Image /ScanHealth
  DISM /Online /Cleanup-Image /RestoreHealth

Si prefieres trabajar con PowerShell, tienes un cmdlet equivalente:

Repair-WindowsImage -Online -RestoreHealth

Todos estos procesos pueden tardar bastante, especialmente en equipos lentos o con mucha corrupción interna. Una vez finalicen, reinicia y vuelve a intentar las actualizaciones desde Windows Update para comprobar si ya se aplican sin trabas.

La herramienta System Update Readiness y el error 80073712

En sistemas como Windows 7, Windows Vista o Windows Server 2008/2008 R2 fue muy habitual el error 80073712 al instalar Service Packs (KB936330, KB948465, KB976932, KB976932 para SP1 de Windows 7, etc.). Ese código indica que la tienda de componentes de Windows está dañada, es decir, el repositorio interno que guarda todos los bloques de sistema para añadir, quitar o reparar componentes.

Para estos casos Microsoft publicó la Herramienta de preparación para actualizaciones del sistema (System Update Readiness Tool, KB947821), que analiza la tienda de componentes (WinSxS) en busca de incoherencias y trata de corregirlas.

El flujo recomendado es:

• Descargar e instalar la herramienta System Update Readiness correspondiente a tu versión y arquitectura de Windows.
• Ejecutarla y esperar pacientemente, porque el análisis puede llevar bastante tiempo.
• Una vez termine, abrir el archivo de registro con:Bloc de notas %windir%\Logs\CBS\CheckSUR.log
• Al final del log verás un resumen del tipo:Resumo:
  Segundos ejecutados: XXXX
  Errores encontrados: N
  Errores corregidos: M

Si la herramienta ha corregido todos los errores encontrados (M = N), en teoría ya puedes intentar de nuevo instalar el Service Pack o las actualizaciones acumulativas y deberían ir bien. El problema es que, en algunos casos, CheckSUR detecta archivos que faltan pero no puede repararlos automáticamente.

Tratar directamente con pending.xml en C:\Windows\WinSxS

Cuando todas las comprobaciones anteriores señalan a un reinicio en bucle y las herramientas insisten en que hay operaciones pendientes, a veces no queda más remedio que intervenir sobre el propio archivo pending.xml. Aquí hay que ser extremadamente prudente, porque Microsoft no recomienda borrarlo a la ligera, pero en la práctica muchos técnicos lo han tenido que hacer como último recurso intermedio.

Lo más seguro es no eliminarlo de entrada, sino intentar detener el servicio responsable y renombrarlo para dejar copia de seguridad. El servicio que suele bloquear el archivo es TrustedInstaller, también conocido como Windows Modules Installer.

Los pasos típicos serían:

1. Abrir un símbolo del sistema como administrador.
2. Detener TrustedInstaller con:net stop trustedinstaller
3. Intentar borrar el archivo:del %windir%\WinSxS\pending.xml
4. Si no te deja eliminarlo por permisos, probar a renombrarlo:ren %windir%\WinSxS\pending.xml pending.old

En ocasiones tendrás que tomar posesión del archivo (propiedades, seguridad, opciones avanzadas) y concederte control total para poder manipularlo. Ojo con esto, porque estamos hablando de un archivo de sistema muy sensible; lo recomendable es hacerlo cuando ya has agotado las vías más ortodoxas y siempre dejando copia renombrada por si hubiera que revertir.

Una vez renombrado o eliminado, reinicia el equipo. Muchas veces el sistema arranca sin seguir atrapado en el reinicio pendiente y ya te permitirá ejecutar sfc /scannow, DISM y el solucionador de problemas de Windows Update con normalidad.

Solucionador de problemas de Windows Update y limpieza adicional

Windows incorpora un solucionador de problemas específico para Windows Update que automatiza parte de lo que hemos comentado: revisa servicios, permisos, caché, claves del registro, etc. No siempre lo arregla todo, pero conviene ejecutarlo en algún punto del proceso, especialmente tras haber reseteado las carpetas de actualización o tocado pending.xml.

En Windows 10 y posteriores puedes acceder a él desde:

• Configuración > Sistema > Solucionar problemas > Otros solucionadores de problemas.
• Selecciona «Windows Update» y pulsa «Ejecutar».
• Aplica las correcciones sugeridas y reinicia el sistema.

En versiones anteriores puedes buscar directamente la palabra «Solucionar problemas» en el Panel de control y elegir la opción relacionada con Windows Update. Si lo combinas con la limpieza previa de SoftwareDistribution y Catroot2, suele detectar y corregir configuraciones incoherentes que se te podrían haber escapado.

Comprobar el estado del disco y el sistema de archivos

Aunque sea menos frecuente, hay ocasiones en las que el bloqueo de Windows Update y los errores en la tienda de componentes se deben a sectores defectuosos o corrupción en el sistema de archivos. Antes de dar por imposible un equipo, merece la pena comprobar la unidad de sistema.

Desde un símbolo del sistema con privilegios elevados puedes lanzar:

chkdsk C: /f /r

El parámetro /f repara errores lógicos y /r busca sectores dañados e intenta recuperar datos legibles. El sistema te pedirá programar la comprobación en el próximo arranque; acepta, reinicia y deja que el proceso termine, aunque pueda llevar bastante tiempo en discos grandes o muy dañados.

Tras esto, volver a ejecutar herramientas como SFC y DISM aumenta las posibilidades de que las reparaciones se apliquen correctamente y que pending.xml no vuelva a quedar a medias por culpa de un fallo de lectura o escritura en disco.

Verificación avanzada mediante el registro y la clave COMPONENTS

En algunos foros especializados y comunidades técnicas se recurre a comprobar directamente el estado de la clave de registro COMPONENTS, donde se almacena parte de la información de la tienda de componentes. Es una operación muy avanzada, pero ayuda a diagnosticar corrupción profunda cuando otras herramientas no dan suficientes pistas.

Una técnica utilizada consiste en cargar esa colmena del registro manualmente y volcar su contenido a un archivo para analizarlo o compartirlo con expertos:

• Abrir CMD como administrador.
• Ejecutar:REG LOAD HKLM\COMPONENTS C:\Windows\System32\config\COMPONENTS
  REG QUERY HKLM\COMPONENTS >1 && notepad 1

Ese archivo de texto resultante permite revisar si hay claves incoherentes relacionadas con WindowsUpdate\Auto Update u otras secciones críticas. En algunos casos, también se exportan ciertas ramas de registro a un archivo «hive» para subirlas a un técnico o servicio de soporte a través de OneDrive, Dropbox u otro sistema.

No es algo que deba hacer un usuario medio por su cuenta, pero conviene saber que existe esta vía cuando el problema afecta a servidores, controladores de dominio o entornos donde un fallo de actualización puede tener impacto serio y se trabaja con soporte avanzado.

Crear un nuevo perfil de usuario cuando el problema es de cuenta

En algunos escenarios, sobre todo en equipos domésticos o portátiles de usuario único, el fallo con Windows Update y pending.xml se combina con permisos dañados en el perfil de usuario. Esto puede impedir modificar archivos como pending.xml o acceder a determinadas rutas aunque la cuenta se muestre como administradora.

Una solución relativamente sencilla es crear un nuevo usuario con permisos de administrador y probar a realizar las operaciones problemáticas desde esa cuenta recién creada. Microsoft ofrece guías detalladas para cada versión de Windows en su soporte oficial, con pasos para añadir cuentas, cambiarles el tipo y migrar datos personales si fuera necesario.

Si desde el perfil nuevo puedes renombrar pending.xml, ejecutar SFC y DISM sin quejarse de falta de permisos y completar las actualizaciones, sabrás que el origen del atasco no estaba tanto en la tienda de componentes como en el propio usuario inicial.

Instalar la actualización problemática de forma manual

En entornos profesionales es bastante habitual que, cuando una actualización falla desde Windows Update, se descargue manualmente el paquete MSU o CAB desde el Microsoft Update Catalog y se intente instalar a mano. Además de forzar la instalación, esto tiene la ventaja de que muchas veces se obtienen mensajes de error más claros durante el proceso.

El procedimiento es simple:

• Anotar el número de KB de la actualización que aparece como pendiente o fallida (por ejemplo, KB3020388, KB3021674, etc.).
• Ir a la web Microsoft Update Catalog y buscar ese identificador.
• Descargar el archivo correspondiente a tu versión y arquitectura de Windows.
• Ejecutar el instalador manualmente y seguir las indicaciones.

Si la instalación manual también falla pero muestra un mensaje de error concreto, ese dato puede resultar clave para afinar el diagnóstico y decidir si lo que está bloqueando el proceso sigue siendo pending.xml, un problema de permisos, un driver incompatible o incluso un conflicto con software de terceros como antivirus.

Cuándo plantearse una reparación in situ o reinstalación

Hay casos extremos en los que, a pesar de haber reseteado la caché de Windows Update, ejecutado SFC, DISM, System Update Readiness, manipulado pending.xml con cuidado y revisado disco y registro, las actualizaciones siguen sin entrar o el sistema continúa lanzando errores graves. En esas circunstancias, seguir parcheando puede ser más arriesgado que tomar una decisión radical.

La opción más conservadora, siempre que dispongas del medio adecuado, es realizar una instalación de reparación (también llamada «reparar instalación» o «actualización in-place») usando un DVD o USB de Windows de la misma versión. Este procedimiento reinstala los archivos del sistema conservando programas y datos, aunque luego tengas que volver a instalar todas las actualizaciones desde cero.

En entornos de servidor o con varios controladores de dominio, planificar una ventana de mantenimiento para reinicios controlados y, si hace falta, una reparación in situ, es mucho más sensato que convivir indefinidamente con un sistema que no se actualiza. El hecho de que un servidor tenga roles FSMO o funciones críticas no significa que no se pueda reiniciar nunca; lo importante es coordinarlo y asegurarse de que hay redundancia.

Aunque pueda dar pereza, llegar a este punto suele significar que el sistema arrastra una corrupción profunda en su tienda de componentes o en su estructura de archivos que tarde o temprano te iba a explotar por otro lado, así que mejor dejarlo resuelto de raíz.

El bloqueo de Windows Update por culpa de pending.xml suele mezclar corrupción interna, operaciones pendientes a medio hacer y, muchas veces, una caché de actualizaciones hecha trizas; combinar la limpieza de SoftwareDistribution y Catroot2, la reparación con SFC/DISM o System Update Readiness, el tratamiento cuidadoso de pending.xml y, si hace falta, la reparación in situ desde un medio de instalación permite recuperar casi siempre un sistema que parecía irrecuperable, tanto en un portátil doméstico como en una máquina crítica en producción.