Qué son setupact.log y setuperr.log y cómo usarlos

Si alguna vez te ha fallado una actualización de Windows y no sabías por dónde empezar, estos dos ficheros te van a sonar a partir de hoy: setupact.log y setuperr.log. Son el diario de a bordo del instalador de Windows y, usados con cabeza, te permiten averiguar qué pasó, cuándo y por qué.

En las líneas siguientes te explico con detalle qué son, dónde se guardan según la fase de instalación, cómo se leen y cómo cruzar su información con otros registros clave (BlueBox.log, MIG, CBS, DISM y más). Además, verás un caso real con errores 0x8007042B y 0x00000570, pistas forenses para distinguir si un usuario intentó reinstalar o actualizar desde un USB, y un método práctico para recopilar todos los logs incluso si el equipo no arranca.

¿Qué son setupact.log y setuperr.log?

En cada fase de una instalación o actualización, Windows genera varios archivos de registro; de todos ellos, el más completo es setupact.log (acciones del instalador) y el más sintético es setuperr.log (lista de errores). Ambos son fundamentales para diagnosticar fallos durante upgrades, instalaciones limpias, OOBE o reversiones.

Por defecto las carpetas que los contienen están ocultas, así que tendrás que mostrar elementos ocultos en el Explorador o recopilar los registros con una herramienta o desde un entorno de recuperación. Aunque hay más ficheros útiles, el punto de partida casi siempre es revisar setuperr.log primero y después profundizar en setupact.log.

Dónde se guardan según la fase de instalación

La ubicación de estos registros depende de la fase en la que esté el proceso. Esta pista es crítica porque la extensión del código de error (por ejemplo 0x2000D, 0x4001C…) te dice en qué tramo falló y, por tanto, en qué carpeta buscar.

Ubicaciones típicas por fase para setupact.log (y, por extensión, setuperr.log):

• Fase de nivel inferior: \$Windows.~BT\Sources\Panther
• OOBE (experiencia rápida): \$Windows.~BT\Sources\Panther\UnattendGC
• Reversión (rollback): \$Windows.~BT\Sources\Rollback
• Pre-inicialización (antes del nivel inferior): \Windows
• Post-actualización (después de OOBE): \Windows\Panther

Además, durante un intento de actualización vía Windows Update o WSUS, el archivo BlueBox.log en \Windows\Logs\MoSetup recoge la comunicación entre setup.exe y Windows Update, siendo clave en errores como 0xC1900107 o fallos de nivel inferior.

Cómo se estructura una línea de estos registros

Una entrada típica de setupact.log o setuperr.log incluye cuatro piezas: fecha y hora, nivel de registro, componente y mensaje. Entender esta estructura acelera muchísimo el análisis.

• Fecha y hora: por ejemplo, 2023-09-08 09:20:05.
• Nivel: Info, Warning, Error, Fatal (o equivalente a error irrecuperable).
• Componente: abreviaturas como CONX, MOUPG, PANTHR, SP, IBSLIB, MIG, DISM, CSI, CBS.
• Mensaje: descripción de la acción o del fallo (p.ej., “la operación se completó correctamente”).

En instalaciones y actualizaciones, los componentes SP (Setup Platform), MIG (Migration Engine) y CONX (Compatibility) suelen ser los más jugosos para diagnosticar, así que presta atención a sus eventos y a sus marcas de tiempo.

Ejemplo real (formato simplificado) de una línea con advertencia del componente MIG: 2023-09-08 09:23:50, Warning, MIG, No se pudo reemplazar el objeto C:\Users\name\Cookies. No se puede quitar el objeto de destino. donde el mensaje explica la causa de la advertencia y el componente apunta hacia la migración.

Método práctico para analizarlos

Pasos orientativos:

• Identifica el código de error de instalación (Setup lo devuelve cuando falla).
• Con la parte de extensión (por ejemplo, 0x2000D, 0x4001C…), deduce tipo de fase y carpeta de log a inspeccionar.
• Abre el archivo en un editor de texto y busca la última coincidencia del código (ir al final, buscar hacia arriba).
• Revisa varias líneas por encima y localiza cadenas críticas como Shell application requested abort o Abandoning apply due to error for object, que suelen marcar el punto de no retorno.
• Decodifica los errores de Win32 que veas (por ejemplo, 0x00000570 = ERROR_FILE_CORRUPT).
• Toma nota de las marcas de tiempo y cruza con otros logs de la misma franja (MIG, BlueBox, CBS, DISM, setupapi.*).

Esta metodología, por simple que parezca, es el camino más corto entre un fallo genérico y un diagnóstico accionable que te diga qué tocar.

Caso real: error 0x8007042B:0x2000D por archivo corrupto

Imagina que ves un error compuesto 0x8007042B: 0x2000D. La parte 0x2000D te indica una fase concreta, y la parte 0x8007042B es un código de resultado que puedes rastrear en los logs.

En setuperr.log aparecen líneas como: Error 0x00000570 al recopilar/aplicar objeto: File, C:\ProgramData\Microsoft\Crypto\RSA\S-1-5-18 , acompañadas de eventos MIG con Error 1392 y la frase Shell application requested abort. Todo apunta a que el archivo citado está corrupto (ERROR_FILE_CORRUPT).

Al saltar a setupact.log y alinear por marca de tiempo, se encuentra la misma secuencia: comienzo del Gather MIG, errores de lectura sobre ese fichero del almacén de claves del sistema y solicitud de aborto de la operación por parte de la aplicación de shell. Resultado: el marco de migración falla y la cola de operaciones se abandona con 0x8007042B.

Solución práctica en este caso: el archivo C:\ProgramData\Microsoft\Crypto\RSA\S-1-5-18\ es un artefacto del certificado del sistema local y puede eliminarse de forma segura, tras lo cual la actualización vuelve a progresar sin ese stopper.

Como efecto colateral, otros registros pueden reflejar el entorno de fallo. Por ejemplo, un setupapi.dev.log puede mostrar un intento de actualizar un controlador del chipset Intel QM87 (LynxPoint) y terminar en Exit status: FAILURE(0xC1900101), típico de problemas de controladores o compatibilidad que provocan reversiones genéricas; para análisis de fallos y BSOD considera usar WhoCrashed.

Otros archivos de registro útiles en instalaciones y actualizaciones

Aunque setupact y setuperr son la base, hay más piezas que conviene tener a mano porque completan el puzzle con migración, controladores y reversiones.

• miglog.xml (\Windows\Panther): detalle de lo migrado y útil para problemas de datos tras la actualización.
• BlueBox.log (\Windows\Logs\MoSetup): diálogo entre Setup y Windows Update, clave en WU/WSUS, errores 0xC1900107 y fallos previos al nivel inferior.
• Setupmem.dmp, setupapi.dev.log, registros de eventos (.evtx) en \$Windows.~BT\Sources\Rollback: se recogen durante la reversión. Sirven para analizar registros de BSOD en Windows en el proceso (mini dump), fallos de dispositivo (0x30018) y reinicios inesperados (0xC1900101).
• setupapi.app.log, setupapi.dev.log, setupapi.offline.log (\Windows\inf): todo lo relacionado con Plug and Play, instalación de drivers y errores de controlador en distintas fases.
• CBS.log y Sessions.xml: cuando hay mantenimiento (online u offline), DISM y CBS dejan aquí la traza de cada sesión y los detalles finos.

Consejo rápido: si Setuperr.log no da pistas suficientes, ve directo a setupapi.* y a BlueBox.log, y cruza por marca de tiempo con lo que viste en setupact.log. A menudo, el culpable es un controlador, no el sistema entero.

Escenario: instalación inicial de Windows

En una instalación desde cero que culmina en el escritorio (la famosa primera experiencia del usuario), los registros se van escribiendo a medida que el disco se formatea y monta. Antes de eso, en Windows PE, los logs son temporales y pueden no persistir.

Si falla algo en esta ruta, empieza siempre por Setuperr.log y continúa con Setupact.log. Recuerda que hay varias instancias de setupact según fase: en X:\Windows\Panther durante especialización, en %windir%\panther en OOBE/LogonUI y en %windir%\panther\unattendGC para OOBE automatizada.

En paralelo, verás eventos del sistema en los registros clásicos de Windows: HardwareEvents.evtx, Application.evtx, Security.evtx y System.evtx, que ayudan a correlacionar lo que pasó a nivel de kernel, servicios y aplicaciones.

Escenario: mantenimiento sin conexión (offline) con DISM

Cuando agregas o quitas actualizaciones, drivers o idiomas sin arrancar Windows, estás en mantenimiento offline. Es ideal para mantener imágenes en un servidor sin tener que recapturarlas constantemente.

La herramienta reina aquí es DISM, que escribe su actividad en DISM.log (\Windows\Logs\DISM o donde indiques con /LogPath) y se coordina con Sessions.xml para registrar las sesiones y con CBS.log para detalles de bajo nivel si hace falta.

Si algo peta offline, revisa primero DISM.log. Si no hay un error claro, salta a Sessions.xml y después a CBS.log. El trio te dirá qué paquete, controlador o componente ha fallado y en qué paso exacto.

Escenario: mantenimiento en línea (online)

En online servicing arrancas el sistema y añades drivers, aplicaciones o paquetes aprovechando todas las dependencias y servicios del SO (Plug and Play, .NET, co-instaladores de drivers, etc.). Es la vía ideal para paquetes .msi o KB.exe y para drivers complejos.

Los logs de referencia son los mismos: DISM.log como principal, CBS.log cuando DISM te redirige para más detalle y Sessions.xml como libro de registro de cada acción en esa sesión.

SetupDiag: diagnóstico automatizado

SetupDiag es un analizador autónomo que revisa los logs de Windows Setup y sugiere la causa raíz de un fallo de actualización. Desde Windows 10 2004, se ejecuta automáticamente con parámetros como /ZipLogs:False /Format:xml /Output:%windir%\logs\SetupDiag\SetupDiagResults.xml y apunta resultados al registro en HKLM\SYSTEM\Setup\SetupDiag\Results.

Úsalo como atajo cuando no tienes tiempo para el análisis manual; aun así, conviene validar su diagnóstico cruzando con setupact, setuperr y BlueBox.log por las marcas de tiempo clave.

Investigación forense: ¿reinstalación desde USB o simple actualización/controladores?

Si ves que setupact.log y setuperr.log aparecen justo después de que el usuario conectara un USB, hay que distinguir dos escenarios: arranque de setup.exe desde ese USB para instalar/actualizar, o simplemente conexión del USB y instalación de drivers (que también genera actividad en setupapi.*).

Pistas para confirmar intento de instalación/upgrade desde USB:

• Creación de la carpeta \$Windows.~BT\Sources\Panther y actividad intensa en setupact.log de esa ruta.
• Entradas de MOUPG/PANTHR/SP indicando preparación de la actualización y fases como Downlevel, SafeOS u OOBE.
• Presencia de BlueBox.log y consultas a WU/WSUS si el instalador valida compatibilidad o descarga componentes.
• Eventos con códigos de extensión 0x2000D, 0x4001C–0x4001F o reversiones 0xC1900101, típicos de escenarios de actualización.
• Archivos como miglog.xml y actividad MIG (migración de perfiles/datos).

Señales de que solo se instalaron controladores al conectar el USB:

• Actividad concentrada en \Windows\inf\setupapi.dev.log y setupapi.app.log sin rastro de \$Windows.~BT.
• Mensajes relacionados con hardware IDs (PCI\VEN_…, USB\VID_…) y selección de INF, con estados de salida que no usan la semántica de Setup (por ejemplo, Exit status: FAILURE(0xC1900101) en contexto de drivers, no de upgrade).
• Eventos del Kernel-PnP y DeviceSetupManager en registros de eventos del sistema, sin entradas de migración u OOBE.

Así que sí: la creación de setupact/setuperr justo tras conectar un USB puede significar que el usuario inició una instalación desde el medio, pero debes corroborarlo buscando el árbol \$Windows.~BT, BlueBox.log, actividad MOUPG y MIG. Si todo se limita a setupapi.* y eventos PnP, estarías ante drivers y no un upgrade.

Señales de borrado intencional de evidencias y buenas prácticas

Algunas herramientas de “limpieza” prometen mejorar el sistema borrando registros, pero a menudo lo que hacen es eliminar evidencia útil para soporte y forense: setup*.log, setupapi*.log, INFCACHE, registros .evtx, entradas del Registro, etc.

Un análisis de código de una de estas utilidades muestra intenciones como borrar setupact.log, setuperr.log, setupapi.app.log, setupapi.dev.log (en \Windows, \Windows\inf, \Windows\Panther, \Windows\Panther\UnattendGC, \Windows\System32\sysprep\Panther\IE) o limpiar registros de eventos como HardwareEvents, Application, Security y System. Consulta cómo identificar artefactos en Windows para mejorar tu análisis forense.

Comandos típicos que puedes usar para comprobar la existencia de esos ficheros (desde un símbolo del sistema) son del tipo: dir /s setup*.log, dir /s setupapi*.log, dir /s INFCACHE.1 o dir /s wmiprov.log, y te ayudarán a confirmar borrados o a localizar versiones en rutas inesperadas.

Un apunte importante: manipular el Registro de Windows (hives de System y Software) o procesos sensibles como lsass.exe, smss.exe, csrss.exe, services.exe, winlogon.exe no es inocuo; si una herramienta pide ejecutarse como SYSTEM para tocar estas piezas, desconfía salvo que sea un procedimiento controlado.

Cómo recopilar los registros de Setup cuando el equipo no arranca

Si el sistema no inicia, puedes arrancar en entornos de recuperación (por ejemplo, un entorno WinPE o el Recovery — acceder al CMD durante la instalación) y copiar los logs a una unidad externa o a un recurso de red. Esto es tremendamente útil para escalar a soporte o para tu propio análisis.

Ejemplo de recopilación (ajusta la letra de unidad de destino):

xcopy /sei C:\Windows\panther t:\logs\panther

xcopy /sei C:\Windows\system32\sysprep t:\logs\sysprep

copy setupapi.log C:\Windows t:\logs

copy setupact.log C:\Windows t:\logs

copy setuperr.log C:\Windows t:\logs

copy netsetup.log C:\Windows\debug t:\logs

copy dism.log C:\Windows t:\logs

copy setupapi.app.log C:\Windows\inf t:\logs

copy setupapi.dev.log C:\Windows\inf t:\logs

copy setupapi.offline.log C:\Windows\inf t:\logs

copy CBS.log C:\Windows\logs\CBS t:\logs

Comprimir la carpeta recopilada y enviarla a soporte te permitirá un diagnóstico completo del ciclo de Setup, drivers, CBS y DISM, sin perder contexto.

El núcleo de esta historia es que Windows deja huella de cada fase de instalación y actualización, y setupact.log y setuperr.log son el mapa que te guía por esas huellas. Conocer dónde están según la fase, cómo se lee cada entrada, qué otros logs consultar (BlueBox, MIG, setupapi, CBS, DISM) y cómo correlacionar por marca de tiempo te permite pasar de un fallo opaco a una causa raíz concreta. Añade SetupDiag para ganar velocidad, usa técnicas forenses para descartar si fue solo PnP o un intento real de upgrade desde USB, y protege tus evidencias evitando «limpiadores» que borren los registros que necesitas para arreglar el problema.