Instalando Cowork en Windows 11 Home… y todo lo que salió mal
En Ryzer nos encontramos recientemente con un caso bastante curioso.
El objetivo era instalar Cowork, pero el equipo utilizaba Windows 11 Home. El problema es que esta edición de Windows no dispone de Hyper-V, una característica necesaria para este tipo de entornos.
La solución parecía sencilla: actualizar Windows Home a Windows 11 Pro.
Sin embargo, una vez realizada la actualización comenzaron los verdaderos problemas.
Paso 1. Actualizar Windows 11 Home a Windows 11 Pro
Lo primero fue convertir la instalación existente de Windows 11 Home en Windows 11 Pro.
Tras introducir la clave correspondiente y completar la actualización, el sistema pasó correctamente a la edición Professional.
Hasta aquí, todo parecía normal.
Paso 2. Instalar las características de virtualización
Una vez disponible Windows 11 Pro, comenzamos a habilitar los componentes necesarios.
Entre ellos:
- Hyper-V
- Plataforma de máquina virtual
- Plataforma del hipervisor
Después del reinicio empezaron los problemas.
El error
Nada más arrancar Windows apareció un pantallazo azul.
El código era:
HYPERVISOR_ERROREl equipo reiniciaba continuamente.
En algunos intentos incluso solicitaba la clave de recuperación de BitLocker antes de volver a mostrar el mismo error.
El sistema no llegaba a cargar el escritorio.
Primeras comprobaciones
Como ocurre en este tipo de incidencias, comenzamos descartando problemas habituales.
Reparación del almacén de componentes
Ejecutamos:
DISM /Online /Cleanup-Image /RestoreHealthLa reparación finalizó correctamente.
También puede ejecutarse posteriormente:
sfc /scannowAunque en este caso el error continuaba apareciendo.
Comprobación de Hyper-V
También revisamos distintos componentes relacionados con Hyper-V.
Por ejemplo:
New-VMSwitch -Name "Cowork" -SwitchType Internaly
Get-VMSwitchExtension -VMSwitchName "Cowork"Todo parecía encontrarse en un estado aparentemente correcto.
Comprobación del controlador VFP
Uno de los sospechosos era el controlador de filtrado virtual.
Comprobamos su existencia:
Test-Path C:\Windows\System32\drivers\vfpext.sysAunque inicialmente parecía no existir, comprobamos posteriormente que seguía presente dentro del almacén WinSxS.
Por tanto, no se trataba realmente de un archivo perdido.
Recuperación desde Hiren’s Boot PE
Al no iniciar Windows con normalidad utilizamos un USB de Hiren’s Boot PE para acceder al sistema.
Desde allí fue posible ejecutar herramientas de diagnóstico y reparación sin necesidad de reinstalar Windows.
Este paso resultó especialmente útil para continuar investigando el problema.
La solución definitiva
Después de revisar numerosos componentes encontramos el verdadero origen.
Aunque Hyper-V estaba instalado, Windows no tenía correctamente habilitadas todas las plataformas necesarias para el funcionamiento del hipervisor.
La solución consistió en activar explícitamente estas características:
Las tres opciones marcadas en rojo son estas:
- Contenedores (
Containers)- Instala el soporte de Windows para ejecutar contenedores (como Windows Containers y algunas funciones relacionadas con Docker).
- Claude Cowork puede utilizar componentes de esta infraestructura.
- Plataforma del hipervisor de Windows (
Windows Hypervisor Platform)- Proporciona una API para que aplicaciones de terceros utilicen el hipervisor de Windows.
- Lo usan programas como VMware Workstation, VirtualBox (versiones recientes), emuladores de Android y aplicaciones que necesitan virtualización sin depender directamente de Hyper-V.
- Plataforma de máquina virtual (
Virtual Machine Platform)- Es la infraestructura base que utilizan:
- WSL2 (Windows Subsystem for Linux 2)
- Windows Sandbox
- Docker Desktop
- Algunas funciones de IA y virtualización, entre ellas Claude Cowork según su documentación.
- Es la infraestructura base que utilizan:
Tras reiniciar el sistema:
- desapareció el BSOD;
- Windows volvió a iniciar correctamente;
- Hyper-V quedó operativo;
- Cowork pudo utilizarse con normalidad.
Cómo comprobar que todo está habilitado
Podemos verificar el estado de las características de virtualización mediante:
Get-WindowsOptionalFeature -Online |
Where-Object FeatureName -match "Hyper|Virtual"Los componentes necesarios deberían aparecer como:
State : EnabledConclusiones
Aunque la actualización de Windows 11 Home a Windows 11 Pro suele completarse sin incidencias, en algunos equipos la configuración de la plataforma de virtualización puede quedar incompleta.
Si tras instalar Hyper-V o preparar el entorno para utilizar Cowork aparece un HYPERVISOR_ERROR, merece la pena comprobar que las características VirtualMachinePlatform y HypervisorPlatform están correctamente habilitadas antes de plantearse una reinstalación completa del sistema.
En nuestro caso, activar ambos componentes resolvió definitivamente el problema.
Comandos utilizados
Reparar la imagen de Windows
DISM /Online /Cleanup-Image /RestoreHealthComprobar archivos del sistema
sfc /scannowHabilitar Virtual Machine Platform
Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -AllHabilitar Hypervisor Platform
Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -AllVerificar características instaladas
Get-WindowsOptionalFeature -Online |
Where-Object FeatureName -match "Hyper|Virtual"El comando bcdedit /set {current} hypervisorlaunchtype off es una herramienta de diagnóstico y recuperación que modifica el Boot Configuration Data (BCD) de Windows, encargado de controlar el proceso de arranque del sistema. Su función es impedir temporalmente que el hipervisor de Hyper-V se cargue al iniciar Windows, sin desinstalar Hyper-V ni eliminar ninguna de sus características o servicios. Esto resulta especialmente útil cuando, tras habilitar Hyper-V u otras funciones de virtualización, el equipo deja de arrancar correctamente o muestra errores durante el inicio. Al evitar la carga del hipervisor, Windows puede iniciarse con normalidad para continuar con las tareas de diagnóstico o configuración. Una vez resuelto el problema, el comportamiento habitual se restaura mediante el comando bcdedit /set {current} hypervisorlaunchtype auto, que vuelve a cargar automáticamente el hipervisor en cada arranque.
