¿Tu actualización a Windows 11 24H2 falla con 0xC1900101-0x30017 y “Access is denied” al instalar WinSetupMon.sys? Aquí tienes una guía práctica y probada para resolverlo: activa Secure Boot/UEFI, elimina bloqueos de antivirus/virtualización, y reintenta con el build final.
Resumen del caso
Al intentar actualizar de Windows 11 23H2 a 24H2, el proceso avanza ~40%, el equipo se reinicia, revierte cambios y Windows muestra 0xC1900101-0x30017 (fase FIRSTBOOT). En los registros de Panther/Rollback aparecen múltiples “IOCTLSTORAGEQUERYPROPERTY failed: 0x32” y, sobre todo, un error de copia/instalación de WinSetupMon.sys con 0x80070005 (Access is denied). Este patrón suele indicar un bloqueo por configuración de arranque (Secure Boot/UEFI), controladores/servicios de terceros o plataformas de virtualización que interfieren con los controladores de Setup durante la fase de primer arranque.
Diagnóstico rápido
- Código de error visible:
0xC1900101-0x30017(fallo de controlador en FIRST_BOOT). - Claves de los logs:
WsmInstall: Failed to copy ... WinSetupMon.sys → 0x80070005 (Access is denied)IOCTLSTORAGEQUERY_PROPERTY failed: 0x32(habitual y no determinante por sí mismo)
- Conclusión: Denegación de acceso provocada típicamente por política/seguridad/servicio de terceros o por un modo de firmware no alineado (CSM/Legacy) que impide cargar el monitor de Setup.
| Señal | Qué significa | Qué hacer |
|---|---|---|
0xC1900101-0x30017 | Fallo de controlador durante FIRST_BOOT. | Revisar Secure Boot/UEFI, desactivar CSM, quitar antivirus/virtualización, reintentar. |
0x80070005 al copiar WinSetupMon.sys | Denegación de acceso por bloqueo de archivo/servicio/política. | Desinstalar antivirus/drive monitors, hacer arranque limpio, asegurarse de UEFI puro. |
IOCTLSTORAGEQUERY_PROPERTY 0x32 | Consulta no soportada por el dispositivo (ruido habitual). | No es la causa raíz; enfocar en Secure Boot/terceros/virtualización. |
Solución en orden de impacto (probado)
- Arranque seguro/UEFI (la solución que más casos resuelve)
- Activar Secure Boot en BIOS/UEFI y desactivar CSM/Legacy (dejar UEFI only).
- En placas con selector Other OS / Secure UEFI Boot, elegir Secure UEFI Boot.
- Varias instalaciones completan inmediatamente tras este cambio, sin más ajustes.
- Versión de instalación (build)
- Reintentar con el build de liberación de 24H2 usando Windows Update o el Asistente oficial. Algunas pre-releases fallan donde el build final funciona.
- Controladores/seguridad de terceros
- Desinstalar completamente antivirus de terceros (Kaspersky, ESET, etc.) con su removal tool.
- Quitar adaptadores residuales (p. ej., Kaspersky Security Data Escort Adapter, TAP/TUN) en el Administrador de dispositivos.
- Desinstalar temporalmente apps que monten letras de unidad (Google Drive for Desktop, etc.).
- Plataformas de virtualización
- Desinstalar temporalmente Hyper‑V, Windows Sandbox y Virtual Machine Platform.
- Después de actualizar a 24H2, volver a habilitarlas. En un caso, fue necesario “Restablecer este PC (conservar archivos)” para usar Hyper‑V sin fallos tras la actualización.
- Controladores y hardware
- Actualizar BIOS/chipset y drivers del fabricante (aunque sean 2020–2022).
- Desconectar discos/periféricos no esenciales y dejar solo la unidad del sistema durante la actualización.
- Realizar arranque limpio para evitar bloqueos de servicios durante FIRST_BOOT.
- Si continúa fallando
- Esperar a que Windows Update libere 24H2 si hay safeguard hold.
- “Restablecer este PC” → Conservar mis archivos → descarga en la nube; o volver a 23H2 temporalmente y reintentar más adelante.
Qué es WinSetupMon.sys y por qué falla
WinSetupMon.sys es un controlador temporal usado por Windows Setup para supervisar operaciones críticas durante la actualización. No es un driver de NVIDIA. El código 0x80070005 (Access is denied) aparece cuando un servicio/driver/entorno impide su copia, carga o registro en la fase FIRST_BOOT. Los culpables típicos son:
- Firmware en modo Legacy/CSM o Secure Boot desactivado.
- Antivirus/EDR o “file system filters” de terceros.
- Plataformas de virtualización y sandboxing (Hyper‑V, Sandbox, Virtual Machine Platform, a veces WSL2).
- Letra de unidad “artificial” montada por aplicaciones en segundo plano.
Comprobaciones previas esenciales
- Verificar UEFI/Secure Boot en Windows
- Presiona Win + R → escribe
msinfo32→ Enter. - Comprueba Modo de BIOS: UEFI, y Estado de Arranque seguro: Activado.
- Si no, entra a la BIOS/UEFI y ajusta:
- CSM/Legacy: Disabled / UEFI only.
- Secure Boot: Enabled (modo Standard o Windows UEFI).
- Presiona Win + R → escribe
- Suspender BitLocker (si está activo)
- Panel de control → Cifrado de unidad BitLocker → Suspender protección en la unidad del sistema. Reanudar al finalizar la actualización.
- Revisar los registros de Setup
C:\$WINDOWS.~BT\Sources\Panther\setupact.logC:\$WINDOWS.~BT\Sources\Rollback\setupact.log- Busca entradas con
WinSetupMon.sysy0x80070005para confirmar el patrón.
Procedimiento recomendado paso a paso
- Ajusta la BIOS/UEFI
- Activa Secure Boot y desactiva CSM/Legacy.
- Si el firmware ofrece “Other OS / Secure UEFI Boot”, selecciona Secure UEFI Boot.
- Guarda cambios, reinicia y verifica con
msinfo32.
- Prepara Windows antes de reintentar
- Desinstala antivirus de terceros con su removal tool. Reinicia.
- Quita adaptadores virtuales (TAP/TUN/escort) en el Administrador de dispositivos. Si persisten, ocúpate de las claves residuales después del reinicio.
- Desinstala temporalmente plataformas de virtualización:
- “Activar o desactivar las características de Windows” → desmarca Hyper‑V, Windows Sandbox, Virtual Machine Platform, Windows Hypervisor Platform.
- Opcional (equivalente por línea de comandos):
DISM /Online /Disable-Feature /FeatureName:Microsoft-Hyper-V-All /NoRestart DISM /Online /Disable-Feature /FeatureName:VirtualMachinePlatform /NoRestart DISM /Online /Disable-Feature /FeatureName:HypervisorPlatform /NoRestart DISM /Online /Disable-Feature /FeatureName:Containers-DisposableClientVM /NoRestart bcdedit /set hypervisorlaunchtype off - Desinstala apps que monten unidades (Google Drive for Desktop, etc.).
- Desconecta discos SATA/USB no esenciales y periféricos prescindibles.
- Limpia paquetes de controladores:
- Ejecuta el Liberador de espacio en disco como administrador → “Limpiar archivos del sistema” → marca “Paquetes de controladores de dispositivo”.
- Arranque limpio:
msconfig→ pestaña Servicios → marca “Ocultar todos los servicios de Microsoft” → Deshabilitar todos.- Pestaña Inicio de Windows → abre Administrador de tareas → deshabilita elementos de inicio no críticos.
- Ejecuta la actualización
- Usa Windows Update o el Asistente de instalación oficial (build de liberación/estable) para instalar 24H2.
- Restaura lo necesario tras actualizar
- Vuelve a habilitar Hyper‑V, Virtual Machine Platform, Sandbox y reinstala antivirus y apps de unidades virtuales.
- Si tras reactivar Hyper‑V aparecieran fallos, considera “Restablecer este PC (conservar archivos)” y luego reconfigurar.
Guía de BIOS/UEFI: nombres y dónde mirar
| Ajuste | Cómo debería quedar | Alias comunes en BIOS/UEFI |
|---|---|---|
| Modo de arranque | UEFI only | Boot Mode: UEFI; Launch CSM: Disabled; Legacy Support: Off |
| Secure Boot | Enabled (Standard/Windows UEFI) | Secure Boot: On; OS Type: Windows UEFI Mode; Other OS → evitar |
| Gestión de claves | Install default keys o “Factory keys” | PK/KEK/DB/DBX → cargar valores por defecto si está en Custom |
| Compatibilidad legacy | Disabled | CSM: Off; Legacy ROMs: Disabled |
Consejo: si cambias de Legacy/CSM a UEFI y tu disco del sistema aún es MBR, convierte a GPT antes (mbr2gpt /convert /allowFullOS) tras una copia de seguridad. Muchos equipos con 23H2 ya están en GPT/UEFI, pero verifica en msinfo32.
Limpieza de antivirus y adaptadores residuales
- Desinstala el antivirus desde Aplicaciones y reinicia.
- Ejecuta su herramienta oficial de limpieza para eliminar controladores de filtro y servicios persistentes.
- Abre Administrador de dispositivos → Ver → Mostrar dispositivos ocultos → elimina adaptadores como “Security Data Escort”, TAP/TUN, o controladores en conflicto.
- Explora controladores en la Driver Store si es necesario:
pnputil /enum-drivers > C:\drivers.txt rem Revisa C:\drivers.txt (oemXXX.inf sospechosos) y usa: pnputil /delete-driver oemXXX.inf /uninstall /force
Deshabilitar y reactivar virtualización de forma segura
Para minimizar interferencias durante FIRST_BOOT:
DISM /Online /Disable-Feature /FeatureName:Microsoft-Hyper-V-All /NoRestart
DISM /Online /Disable-Feature /FeatureName:VirtualMachinePlatform /NoRestart
DISM /Online /Disable-Feature /FeatureName:HypervisorPlatform /NoRestart
DISM /Online /Disable-Feature /FeatureName:Containers-DisposableClientVM /NoRestart
bcdedit /set hypervisorlaunchtype off
shutdown /r /t 0
Tras completar 24H2, vuelve a habilitar desde “Características de Windows” o con DISM (cambiando /Disable-Feature por /Enable-Feature) y restaura bcdedit /set hypervisorlaunchtype auto.
Arranque limpio y liberación de controladores
- msconfig
- Oculta los servicios de Microsoft y deshabilita el resto.
- Deshabilita el inicio de apps no críticas en el Administrador de tareas.
- Limpiador de disco
- Ejecuta como administrador → “Limpiar archivos del sistema” → marca “Paquetes de controladores de dispositivo”.
- Integridad de sistema (opcional, por si hay corrupción):
sfc /scannow DISM /Online /Cleanup-Image /RestoreHealth
Rutas de logs y qué buscar
C:\$WINDOWS.~BT\Sources\Panther\setupact.logC:\$WINDOWS.~BT\Sources\Panther\setuperr.logC:\$WINDOWS.~BT\Sources\Rollback\setupact.logysetuperr.log
Indicadores clave:
- Entradas con
WinSetupMon.sysy errores0x80070005. - Secuencias de driver install y First_Boot fallidas.
- Eventos de servicios de seguridad/virtualización iniciando hooks durante la instalación.
Checklist rápida de solución
- UEFI puro y Secure Boot activado.
- Antivirus y filtros de terceros desinstalados con herramienta oficial.
- Hyper‑V, Sandbox y Virtual Machine Platform desactivados temporalmente.
- Sin unidades virtuales montadas por apps.
- Periféricos/discos no esenciales desconectados.
- Arranque limpio aplicado.
- Instalación desde Windows Update/Asistente (build release).
Preguntas frecuentes
¿“WinSetupMon.sys” es de NVIDIA?
No. Es un controlador temporal de Windows Setup. Aunque su nombre pueda confundirse, no pertenece a un fabricante de GPU.
¿Los mensajes “IOCTLSTORAGEQUERY_PROPERTY failed: 0x32” son críticos?
Normalmente no. Suelen ser consultas de propiedades no soportadas por ciertos dispositivos. El error decisivo es la denegación de acceso al instalar/cargar WinSetupMon.sys.
¿Puedo dejar desactivado Secure Boot?
No es recomendable. Varios casos reportan que la actualización solo completa con Secure Boot habilitado y CSM desactivado (UEFI puro). Posteriormente puedes mantener Secure Boot activo; mejora seguridad y compatibilidad con 24H2.
¿Debo formatear?
No es el primer paso. Antes prueba lo anterior. Como últimos recursos: esperar a que WU libere 24H2 (si hay safeguard hold) o “Restablecer este PC (conservar archivos)”.
Plan de recuperación si algo sale mal
- El sistema revierte a 23H2 automáticamente si falla FIRST_BOOT.
- Restaura ajustes revertidos (por ejemplo, vuelve a activar servicios que deshabilitaste para poder trabajar) y prepara un nuevo intento con el checklist depurado.
- Si un componente como Hyper‑V queda inestable tras actualizar, utiliza Restablecer este PC (conservar archivos), reinstala funciones y configura de nuevo.
Ejemplo de flujo de trabajo recomendado
- Verifica en
msinfo32: UEFI + Secure Boot: Activado. Ajusta BIOS si no. - Suspende BitLocker (si aplica).
- Desinstala antivirus con herramienta oficial + elimina adaptadores residuales.
- Deshabilita Hyper‑V/Sandbox/Virtual Machine Platform y
hypervisorlaunchtype→off. - Desconecta unidades externas y apps que monten letras.
- Arranque limpio + limpieza de paquetes de controladores.
- Reinicia y ejecuta el setup de 24H2 desde Windows Update o Asistente.
- Tras éxito, reactivas Hyper‑V/VM Platform/Sandbox, reinstalas antivirus, reanudas BitLocker.
Notas importantes
- Si tu firmware tiene modo Custom de Secure Boot, instala las claves por defecto (PK/KEK/DB/DBX) o cambia a Standard/Windows UEFI.
- Si el sistema arrancaba en Legacy/CSM con MBR, migra a GPT con
mbr2gptantes de activar Secure Boot. - Evita tener software que “vigile” el sistema de archivos durante la actualización (protecciones de comportamiento, DLP, sandbox de terceros).
- Los controladores del chipset (INF/ME/SMBus/SATA/NVMe) actualizados del fabricante reducen fricciones en FIRST_BOOT.
Tabla de acciones y su efecto esperado
| Acción | Impacto sobre el problema | Cuándo aplicarla |
|---|---|---|
| Activar Secure Boot y UEFI only | Elimina bloqueos de carga del monitor de Setup | Siempre, como primer paso |
| Desinstalar antivirus con removal tool | Quita filtros que niegan acceso/capturan handles | Siempre, si usas antivirus de terceros |
| Deshabilitar Hyper‑V/Sandbox/VM Platform | Evita hooks del hipervisor durante FIRST_BOOT | Si usas virtualización o WSL2 |
| Desinstalar apps de unidades virtuales | Quita montajes que confunden al instalador | Si tienes Google Drive u otras similares |
| Arranque limpio | Reduce conflictos de servicios de terceros | Antes de cada intento de actualización |
| Actualizar BIOS/chipset y drivers | Mitiga incompatibilidades de controladores | Si hay versiones estables disponibles |
| Usar build de liberación | Evita fallos de pre-release | Siempre que sea posible |
TL;DR práctico
- Paso 1: Activa Secure Boot, desactiva CSM (UEFI puro) y verifica en
msinfo32. - Paso 2: Quita antivirus/EDR, deshabilita Hyper‑V/Sandbox/VM Platform, elimina unidades virtuales.
- Paso 3: Arranque limpio, desconecta discos extras, limpia paquetes de drivers.
- Paso 4: Reintenta con el build de release desde Windows Update/Asistente.
- Si persiste: “Restablecer este PC (conservar archivos)” o espera a que WU libere 24H2 si hay safeguard hold.
Créditos de las soluciones: Lo que más resolvió en los casos reales fue forzar UEFI + Secure Boot y eliminar bloqueos de terceros (antivirus/virtualización/unidades virtuales). El error de WinSetupMon.sys con 0x80070005 es coherente con un “Access denied” impuesto por esos componentes durante FIRST_BOOT, no con fallos de almacenamiento (IOCTL 0x32 suele ser secundario).