Cómo acelerar la validación de aplicaciones con Windows Sandbox

En el desarrollo de aplicaciones para Windows, los motivos por los que la validación se vuelve lenta suelen ser parecidos.

• El equipo de desarrollo local está “sucio” y no reproduce los problemas de la primera instalación
• El problema ocurre en el entorno del cliente, pero no en el propio PC
• “Funciona si se ejecuta como administrador”, pero no queda claro dónde está realmente el límite de privilegios necesario
• Se quiere probar el comportamiento cuando faltan permisos o dependencias, pero sin dañar el entorno habitual
• La aplicación falla con poca memoria o sin GPU, pero no amerita levantar una VM completa cada vez

En estos casos, Windows Sandbox resulta bastante útil.

No es tan pesado como una VM completa, se inicia rápido y, al cerrarlo, desaparece limpiamente cada vez, por lo que encaja bien con el requisito de «recrear en pocos minutos un entorno de validación limpio con la misma compilación de Windows».

Sin embargo, si simplemente se abre un Sandbox nuevo cada vez sin pensar en nada más, la eficiencia no mejora tanto. Lo que realmente funciona en la práctica es una operación en la que se fija un .wsb para cada escenario de validación, se separan las carpetas de entrada de solo lectura de las carpetas de recogida de solo escritura, y se distinguen los perfiles de administrador, de usuario estándar y con restricciones.

En este artículo se organiza esa forma de trabajar centrándose en el desarrollo de aplicaciones para Windows. El contenido se basa en la información oficial de Microsoft disponible en abril de 2026.

Contexto de este artículo

Terminología usada en este artículo

Antes de continuar, se resumen los términos que aparecen en inglés.

Índice

• Primero, la conclusión
• Por qué Windows Sandbox encaja bien con la validación en desarrollo
• Limitaciones que conviene conocer primero
• Una estructura de directorios que conviene preparar de antemano
• Reducir la prueba de humo en un entorno limpio a un solo doble clic
• Procedimiento para aislar problemas de permisos de administrador
• Crear intencionalmente un estado con falta de permisos o dependencias
• Crear un entorno cercano a la falta de recursos
• Desde Windows 11 24H2, también es fácil trabajar con la CLI
• Puntos que no conviene pasar por alto en el uso diario
• Resumen
• Artículos relacionados
• Referencias

Primero, la conclusión

Antes que nada, se presentan las conclusiones.

• Windows Sandbox es adecuado para reproducir entornos limpios, verificar la primera instalación, aislar problemas de permisos de administrador y detectar dependencias faltantes.
• Es más rápido separar un .wsb por cada finalidad que hacer todo manualmente por la GUI cada vez.
• En las carpetas compartidas con el host, separar la entrada como read-only y solo la salida como read-write reduce los incidentes.
• La sesión predeterminada de Sandbox no es fácil de usar tal cual para la validación con usuario estándar. Si desea validar con un usuario estándar, cree otro usuario dentro del Sandbox e inicie la aplicación con ese usuario.
• Para reproducir la falta de memoria o la ausencia de GPU, resultan útiles MemoryInMB y deshabilitar VGpu (uso compartido de GPU virtual) en el .wsb.
• Sin embargo, si necesita llegar a cuotas de CPU, saturación de disco, múltiples instancias simultáneas o reproducir otra versión de SO, una VM completa es más adecuada que Windows Sandbox.

En resumen, Windows Sandbox es un entorno de validación «ligero pero desechable», «rápido pero limitado a la misma familia de SO» y «limitado pero suficientemente útil en la práctica». Entender esta posición de antemano evita usarlo donde no corresponde.

Por qué Windows Sandbox encaja bien con la validación en desarrollo

Hay cuatro razones por las que Windows Sandbox encaja bien con el desarrollo de aplicaciones para Windows.

Se reinicia por completo cada vez que se cierra

Esta es la razón más importante.

Probar el instalador varias veces, romper la configuración, tocar el registro, instalar y desinstalar prerrequisitos. Si este tipo de trabajo se hace directamente en el equipo de desarrollo, poco a poco se convierte en «un entorno del que ya no se sabe qué tiene instalado».

Con Sandbox, al cerrarlo todo desaparece. Por eso resulta más fácil encontrar problemas que solo ocurren en la primera instalación o problemas que quedan ocultos porque un prerrequisito ya estaba instalado por casualidad.

Se puede crear rápidamente un entorno limpio de la misma familia de Windows

Windows Sandbox parte de la base de usar una compilación de Windows de la misma familia que el host. Esto es una limitación, pero, visto de otro modo, también significa que se puede crear de inmediato un entorno limpio de la misma familia que el Windows 11 local.

En una situación como «el cliente usa Windows 11 24H2 y nosotros también», resulta bastante manejable.

Más ligero que una VM completa, con menor coste de administración

Las VM completas de Hyper-V o VMware son potentes, pero si el uso de cada vez se limita a

• Verificar el procedimiento de instalación
• Comprobar cómo aparece el UAC
• Comprobar el error cuando faltan permisos
• Comprobar el registro cuando faltan dependencias
• Prueba de humo en un entorno limpio

suelen resultar algo pesadas para eso.

Windows Sandbox evita en gran medida tener que gestionar imágenes de SO o manejar instantáneas, y esa es su fortaleza: facilita avanzar con validaciones de «quiero reproducir esto rápido».

Se pueden fijar escenarios con .wsb y la CLI

El verdadero valor de Sandbox no es solo «poder probar con seguridad», sino poder repetir la prueba las veces que haga falta en las mismas condiciones.

• Con o sin red
• Carpeta compartida read-only / read-write
• Poca memoria
• Sin uso compartido de GPU
• Sin uso compartido del portapapeles
• Ejecutar un script determinado al iniciar

Si se fijan estos aspectos con .wsb o con la CLI de Windows 11 24H2 en adelante, la validación pasa de ser «un trabajo improvisado» a «un procedimiento repetible».

Limitaciones que conviene conocer primero

Es útil, pero hay cosas para las que no está pensado. Conviene tenerlo claro desde el principio.

Hay restricciones sobre las ediciones compatibles

Windows Sandbox se puede usar en las ediciones Pro / Enterprise / Education de Windows. No está disponible en la edición Home.

Es fácil tropezar con esto porque, aunque los equipos de desarrollo internos sean Pro, los equipos de ventas o los PC personales suelen ser Home.

Existen requisitos de virtualización

Para usarlo hace falta tener la virtualización habilitada y disponer de una cantidad mínima de RAM, disco y núcleos de CPU. Aunque es ligero, no es completamente gratuito en recursos.

Sandbox usa la misma familia de SO que el host

Esto es bastante importante en la práctica.

Windows Sandbox no es adecuado para validar otra versión de SO.

• Si el host es Windows 11, no sirve como entorno para reproducir Windows 10
• Si el cliente usa una compilación antigua, esa diferencia no se puede cubrir

Por eso, para la validación de compatibilidad con otra versión de SO o problemas dependientes de compilaciones antiguas, conviene elegir una VM completa desde el principio.

No se pueden iniciar varias instancias a la vez

Actualmente, Windows Sandbox no está pensado para ejecutar varias instancias simultáneamente.

Si desea ejecutar una matriz de pruebas en paralelo, resulta más natural usar Hyper-V u otra solución similar.

La red y el portapapeles están habilitados de forma predeterminada

Este punto es fácil de pasar por alto.

Windows Sandbox tiene la conexión de red habilitada de forma predeterminada. El uso compartido del portapapeles también está habilitado de forma predeterminada.

Es decir, si se inicia sin pensar en nada más, no se obtiene «un mundo completamente cerrado». Para revisar archivos de origen desconocido o reproducir la falta de dependencias, es más seguro controlarlo explícitamente desde el principio con .wsb.

Desde Windows 11 24H2, algunas aplicaciones inbox no están disponibles

En el Sandbox de Windows 11 24H2 en adelante, algunas aplicaciones inbox de la Store, como el Bloc de notas, la Terminal, la Calculadora o Fotos, no están disponibles.

Por eso, es más seguro diseñar la automatización de inicio y las operaciones auxiliares partiendo de cmd.exe, powershell.exe y explorer.exe.

Una estructura de directorios que conviene preparar de antemano

En lugar de decidir la carpeta compartida sobre la marcha cada vez, resulta mucho más cómodo preparar de antemano un único lugar dedicado a la validación.

Por ejemplo, una estructura como esta.

C:\SandboxFixtures\
├─ AppUnderTest\
│  ├─ MyAppInstaller.msi
│  ├─ MyApp.exe
│  └─ sample-data\
├─ Scripts\
│  └─ Prep-StandardUser.ps1
├─ Outbox\
├─ 00-clean-smoke.wsb
├─ 10-standard-user.wsb
├─ 20-restricted-runtime.wsb
└─ 30-low-resource.wsb

Los roles se dividen así.

• AppUnderTest: la aplicación bajo prueba. Compartida como read-only
• Scripts: scripts de inicio. Compartida como read-only
• Outbox: registros, volcados y resultados exportados. Compartida como read-write

Con esta separación, el único lugar al que Sandbox puede escribir en el host queda limitado a Outbox, lo cual es bastante seguro.

Además, los .wsb también se fijan por escenario.

Solo con esto, el coste de iniciar la validación baja considerablemente.

Reducir la prueba de humo en un entorno limpio a un solo doble clic

Lo primero que conviene preparar es un Sandbox para la prueba de humo en un entorno limpio.

Ejemplo: 00-clean-smoke.wsb

<Configuration>
  <Networking>Disable</Networking>

  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\AppUnderTest</HostFolder>
      <SandboxFolder>C:\Work\AppUnderTest</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Outbox</HostFolder>
      <SandboxFolder>C:\Work\Outbox</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>

  <LogonCommand>
    <Command>explorer.exe C:\Work\AppUnderTest</Command>
  </LogonCommand>
</Configuration>

Para este uso, conviene tener claros estos cuatro puntos.

• Coloque el material de distribución en AppUnderTest
• Muestre esa carpeta como read-only
• Escriba solo los registros y resultados en Outbox
• Si no quiere ver dependencias de red, desactívela desde el principio

Con esto, basta con sustituir el material de distribución y hacer doble clic en el .wsb para obtener, cada vez, una validación inicial limpia.

Qué debe aparecer para considerar que fue un éxito

Lo más difícil de entender la primera vez es «hasta dónde hay que llegar para considerarlo un éxito». A continuación se enumeran los puntos de comprobación.

Al hacer doble clic en el .wsb, se abre en una ventana un escritorio distinto al del host. Su contenido es un Windows en estado inicial, con el fondo de pantalla predeterminado y un escritorio vacío. No se heredan el fondo de pantalla del host, las aplicaciones instaladas ni la cuenta con la que se ha iniciado sesión. Si se llega hasta aquí, el inicio en sí ha sido exitoso.

A continuación se ejecuta el comando escrito en LogonCommand. Con el 00-clean-smoke.wsb anterior, se abre el Explorador de archivos dentro del Sandbox y se muestra el contenido de C:\Work\AppUnderTest.

Para saber con certeza si se ha iniciado con la configuración prevista, lo mejor es ejecutar comandos dentro del Sandbox. Abra powershell.exe desde el menú Inicio dentro del Sandbox y ejecute lo siguiente en orden.

# 1) Comprobar si las carpetas compartidas aparecen en el lugar previsto
Get-ChildItem C:\Work

# 2) El lado de entrada debería ser de solo lectura. Si da error, es lo esperado
New-Item -Path C:\Work\AppUnderTest\write-test.txt -ItemType File

# 3) El lado de salida debería permitir escritura. Si tiene éxito, es lo esperado
New-Item -Path C:\Work\Outbox\write-test.txt -ItemType File

# 4) Si la intención era desactivar la red, la comunicación debería fallar
Test-NetConnection -ComputerName www.microsoft.com -Port 443

# 5) Con qué usuario se está ejecutando ahora. En la sesión predeterminada es la cuenta de administrador
whoami
whoami /groups

El write-test.txt del paso 3 también aparece en C:\SandboxFixtures\Outbox del lado del host. Si se ve ahí, confirma que la ruta de recogida de registros y volcados funciona correctamente.

Cuando algo no funciona, revise en este orden.

• Si al hacer doble clic no ocurre nada, o aparece un error → Es posible que el XML del .wsb esté mal formado. Asegúrese de que los nombres de los elementos coincidan con la notación de la documentación de archivos de configuración de Microsoft Learn.
• Si C:\Work está vacío → La ruta del host indicada en HostFolder no existe. La ruta de la carpeta compartida debe ser una ruta que exista realmente en el host.
• Si “Windows Sandbox” no aparece en el menú Inicio → No se cumplen los requisitos previos, o la característica de Windows no está habilitada. Revise la tabla de contexto de este artículo.

Problemas que se detectan fácilmente con esto

En esta etapa suelen encontrarse problemas como estos.

• Faltan en producción las DLL o runtimes prerrequisito que sí estaban en el equipo de desarrollo
• El requisito de WebView2 o del paquete redistribuible de VC++ queda implícito
• El destino de creación de directorios o archivos de configuración generados solo en el primer inicio es incorrecto
• Falla al intentar escribir datos en tiempo de ejecución dentro de Program Files
• Se da por hecho un certificado, una fuente o una configuración que «ya estaba instalada en el equipo del desarrollador»

El punto clave es volcar siempre en Outbox todo lo que ocurra dentro del Sandbox. En el momento en que se cierra, todo desaparece, así que no se puede dejar los registros ni los volcados sin recoger.

Mantenga también una versión con red en un archivo aparte

Si el objetivo es un instalador web o una aplicación con autenticación en línea, mantener la red desactivada solo revelará problemas distintos.

En ese caso, resulta más claro crear otro archivo con la misma configuración, como 01-clean-online.wsb, y no mezclar «la reproducción con supuesto sin conexión» con «la reproducción con supuesto en línea».

Procedimiento para aislar problemas de permisos de administrador

En el desarrollo de aplicaciones para Windows, los temas de permisos de administrador suelen mezclarse bastante.

• ¿Solo se necesitan durante la instalación?
• ¿Se necesitan también en tiempo de ejecución?
• ¿Solo se necesitan para algunos cambios de configuración?
• ¿En realidad el problema es solo un destino de guardado incorrecto?

Este tema en sí ya se ha tratado en los siguientes artículos anteriores.

• Cuándo se necesitan realmente privilegios de administrador en Windows: UAC, áreas protegidas y cómo distinguirlo en el diseño
• Cómo aislar en el código, de forma concreta, «solo los procesos que necesitan permisos de administrador» en una aplicación de Windows

Aquí nos centraremos en cómo acelerar la validación usando Sandbox.

Los aspectos que conviene revisar primero

En Sandbox, lo primero que interesa comprobar son límites como los siguientes.

• Si el instalador escribe en Program Files o en HKLM
• Si registra servicios, instala controladores o cambia la configuración del firewall
• Si el actualizador intenta reemplazar archivos a nivel de todo el equipo
• Si intenta escribir la configuración, los registros o la caché en tiempo de ejecución en un área protegida
• Si hay integración con el sistema operativo, como extensiones de shell o registro COM

En definitiva, el objetivo es separar «los procesos que realmente necesitan permisos de administrador» de «los procesos que solo tienen un mal destino de almacenamiento en tiempo de ejecución».

El estado predeterminado de Sandbox no basta para validar con usuario estándar

Este punto es importante.

El comando de inicio de sesión de Windows Sandbox se ejecuta con la cuenta de usuario del contenedor. La propia documentación de Microsoft Learn indica que esa cuenta de usuario del contenedor debería ser una cuenta de administrador.

Es decir, la sesión predeterminada de Sandbox no es fácil de usar tal cual para «la reproducción con usuario estándar».

Si quiere aislar correctamente los problemas de permisos de administrador, resulta más claro crear otro usuario estándar dentro del Sandbox e iniciar la aplicación con ese usuario.

Ejemplo: 10-standard-user.wsb

<Configuration>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\AppUnderTest</HostFolder>
      <SandboxFolder>C:\Work\AppUnderTest</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Scripts</HostFolder>
      <SandboxFolder>C:\Work\Scripts</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Outbox</HostFolder>
      <SandboxFolder>C:\Work\Outbox</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>

  <LogonCommand>
    <Command>powershell.exe -NoExit -ExecutionPolicy Bypass -File C:\Work\Scripts\Prep-StandardUser.ps1</Command>
  </LogonCommand>
</Configuration>

Ejemplo: Prep-StandardUser.ps1

$UserName = 'wsbuser'
$Password = 'P@ssw0rd-For-Test-Only!'

$existing = Get-LocalUser -Name $UserName -ErrorAction SilentlyContinue
if (-not $existing) {
    $secure = ConvertTo-SecureString $Password -AsPlainText -Force
    New-LocalUser -Name $UserName -Password $secure -AccountNeverExpires | Out-Null
}

try {
    Remove-LocalGroupMember -Group 'Administrators' -Member $UserName -ErrorAction Stop
}
catch {
}

try {
    Add-LocalGroupMember -Group 'Users' -Member $UserName -ErrorAction Stop
}
catch {
}

Write-Host ''
Write-Host 'Standard user has been prepared.'
Write-Host "User     : $UserName"
Write-Host "Password : $Password"
Write-Host ''
Write-Host 'Run your app as the standard user with:'
Write-Host 'runas /user:wsbuser "C:\Work\AppUnderTest\MyApp.exe"'
Write-Host ''

Start-Process explorer.exe 'C:\Work\AppUnderTest'

Con esta configuración, en el momento en que se inicia el Sandbox ya está preparado el usuario estándar, así que se puede probar directamente así.

runas /user:wsbuser "C:\Work\AppUnderTest\MyApp.exe"

Qué se puede detectar con esto

Con este método resulta más fácil detectar problemas como estos.

• Falla porque guarda la configuración de tiempo de ejecución junto al EXE
• Falla al intentar escribir en HKLM
• El actualizador da por hecho un ámbito de todo el equipo
• El destino de guardado de los registros está dentro de Program Files
• Solo un botón necesita permisos de administrador, pero toda la aplicación da por hecha la elevación

A veces los problemas de permisos de administrador se detectan solo con la revisión de código. Sin embargo, ver con los propios ojos «dónde se atasca la aplicación al ejecutarla realmente con un usuario estándar» deja bastante clara la frontera de diseño.

Crear intencionalmente un estado con falta de permisos o dependencias

Más allá de «no ser administrador», si se elimina intencionalmente parte de la comodidad del entorno, salen a la luz las dependencias ocultas.

Ejemplo: 20-restricted-runtime.wsb

<Configuration>
  <Networking>Disable</Networking>
  <ClipboardRedirection>Disable</ClipboardRedirection>
  <PrinterRedirection>Disable</PrinterRedirection>
  <ProtectedClient>Enable</ProtectedClient>

  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\AppUnderTest</HostFolder>
      <SandboxFolder>C:\Work\AppUnderTest</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Outbox</HostFolder>
      <SandboxFolder>C:\Work\Outbox</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>

  <LogonCommand>
    <Command>explorer.exe C:\Work\AppUnderTest</Command>
  </LogonCommand>
</Configuration>

Qué se busca comprobar con este perfil

Este perfil restringido es adecuado para comprobaciones como estas.

• Si existe alguna dependencia oculta que impide iniciar sin red
• Si se da por hecho que los archivos se introducen a través del portapapeles
• Si la interfaz o el procesamiento de informes se escribió asumiendo que hay una impresora predeterminada visible
• Si hay dependencias innecesarias en operaciones que funcionaban “de milagro” incluso a través de una sesión RDP
• Si existe alguna implementación descuidada que asume poder escribir libremente en una carpeta compartida

Especialmente en las aplicaciones de negocio, es habitual que «en el propio equipo funcionaba con normalidad», pero en el equipo del entorno real

• Hay restricciones de red
• Hay restricciones del portapapeles
• No hay impresora
• Hay restricciones de escritura en carpetas compartidas

y sucede así con frecuencia.

Si en Sandbox se acerca de antemano a ese mismo escenario, luego resulta menos probable quedarse atascado ante una consulta del cliente.

No exponga carpetas compartidas de forma amplia

Este punto también es bastante importante.

Las carpetas asignadas (mapped folder) de Sandbox son cómodas, pero los cambios en una carpeta compartida con permiso de escritura permanecen en el host aunque se cierre el Sandbox.

Por eso, es más seguro evitar este tipo de recursos compartidos.

• Compartir C:\Users en su totalidad
• Exponer todo el repositorio con permiso de escritura
• Compartir Downloads o Documents con escritura de forma descuidada

Como norma general, se recomienda un esquema de dos niveles:

• Los datos de entrada, en una carpeta acotada (narrow) con read-only
• Solo los datos de salida, en un Outbox dedicado con read-write

Crear un entorno cercano a la falta de recursos

Windows Sandbox no ofrece un gran margen de libertad para controlar los recursos. Aun así, se puede usar para «una validación con recursos ligeramente restringidos».

Ejemplo: 30-low-resource.wsb

<Configuration>
  <VGpu>Disable</VGpu>
  <MemoryInMB>2048</MemoryInMB>
  <Networking>Disable</Networking>

  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\AppUnderTest</HostFolder>
      <SandboxFolder>C:\Work\AppUnderTest</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Outbox</HostFolder>
      <SandboxFolder>C:\Work\Outbox</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>

  <LogonCommand>
    <Command>explorer.exe C:\Work\AppUnderTest</Command>
  </LogonCommand>
</Configuration>

Problemas que se hacen más visibles con esto

Con este perfil, resulta más fácil que salgan a la luz problemas como estos.

• Consume demasiada memoria al iniciar
• No contempla margen de memoria al leer archivos grandes
• El renderizado se vuelve extremadamente lento sin uso compartido de GPU
• El comportamiento de reserva (fallback) de WPF, WebView2, procesamiento de imágenes o de vídeo es deficiente
• Problemas de interfaz que «no se veían en el propio equipo porque tenía una GPU de alto rendimiento»

Según la especificación de configuración de Microsoft, si MemoryInMB es inferior a 2048 MB, se eleva automáticamente hasta el valor mínimo necesario para iniciar. Es decir, resulta realista considerar aproximadamente 2 GB como límite inferior de referencia para la validación con poca memoria en Windows Sandbox.

Casos en los que Sandbox por sí solo no basta

Por el contrario, hay aspectos para los que Windows Sandbox por sí solo se queda un poco corto.

• Se desea limitar fuertemente el uso de CPU
• Se desea crear con precisión una falta de espacio en disco
• Se desea crear latencia de E/S
• Se desea ejecutar en forma de matriz con varios tamaños de memoria
• Se desea ejecutar de forma persistente un soak test de larga duración

Para estos casos, lo más sencillo es recurrir desde el principio a una VM completa, como Hyper-V.

Sandbox es eficaz hasta el punto de «un entorno con restricciones ligeras», pero no es «una plataforma de pruebas de carga precisas».

Desde Windows 11 24H2, también es fácil trabajar con la CLI

En el nuevo Windows Sandbox de Windows 11 24H2 en adelante, también se puede usar la CLI.

Los comandos disponibles son, aproximadamente, estos.

• wsb start
• wsb list
• wsb connect
• wsb exec
• wsb share
• wsb stop

Por ejemplo, en su forma más mínima, el flujo sería así.

wsb start --config "<Configuration><Networking>Disabled</Networking></Configuration>"
wsb list

Cabe señalar que el ejemplo oficial de la CLI de Windows Sandbox usa Disabled, mientras que la descripción del esquema del archivo de configuración .wsb indica Disable / Enable / Default. Si va a incorporar --config en línea a su operación, verifique en el equipo real con Windows 11 24H2 o posterior qué notación acepta.

Cuando conozca el ID del Sandbox en ejecución,

wsb connect --id <sandbox-id>

podrá conectarse con este comando.

Situaciones en las que conviene usar la CLI

La CLI resulta útil en situaciones como estas.

• Se desea incorporar el inicio de Sandbox en un script de reproducción local
• Se desea invocar configuraciones habituales desde un archivo por lotes o PowerShell
• Se desea añadir una carpeta compartida a un Sandbox en ejecución
• Se desea automatizar un poco el procedimiento de validación local

Por qué, aun así, conviene conservar el .wsb

Sin embargo, por ahora es mejor no descartar el .wsb.

La razón es sencilla: se puede leer como el nombre del escenario.

• 00-clean-smoke.wsb
• 10-standard-user.wsb
• 20-restricted-runtime.wsb
• 30-low-resource.wsb

Así, cualquiera que lo vea entiende para qué sirve.

La CLI es útil, pero como forma de trabajo, «la definición de las condiciones va en el .wsb, y el envoltorio de inicio va en la CLI» es el reparto de roles más manejable.

Puntos a tener en cuenta con la CLI

Por el momento, wsb exec tiene limitaciones en la captura de la E/S del proceso, y si se ejecuta en el contexto de un usuario con sesión iniciada existente, también hace falta una sesión de usuario activa.

Es decir, es mejor no esperar demasiado de esto como una plataforma de pruebas automáticas completamente headless. Resulta útil para automatizar reproducciones locales, pero no es el tipo de herramienta que se pueda colocar tal cual en lugar de un CI.

Puntos que no conviene pasar por alto en el uso diario

Por último, se resumen solo los puntos en los que es fácil tropezar en la práctica.

Reduzca al mínimo las carpetas compartidas

Sandbox está aislado (isolated), pero las carpetas asignadas (mapped folder) están conectadas con el host. Una carpeta compartida con escritura afecta al host.

No comparta de forma amplia; limite los recursos compartidos con escritura únicamente a Outbox. Esto es lo básico.

Recoja los registros y volcados antes de cerrar

Es obvio, pero al cerrar todo desaparece. Precisamente por eso conviene fijar desde el principio el destino de salida en Outbox.

No se conforme con «la sesión predeterminada de Sandbox tal cual» para la validación con usuario estándar

Si quiere aislar correctamente los problemas de permisos de administrador, resulta más claro iniciar con otro usuario. Si se deja esto ambiguo, queda pendiente el caso de «funcionaba en Sandbox, pero falla con el usuario estándar del cliente».

No lo use en exceso para validar diferencias de versión de SO

Sandbox es adecuado para la validación limpia dentro de la misma familia de SO, pero no es un reproductor de versiones antiguas de Windows. Si necesita comprobar otro SO, use una VM completa desde el principio.

En equipos administrados por la empresa puede haber restricciones de directivas

Una configuración controlada por la Directiva de grupo (Group Policy) a veces no se puede cambiar desde el .wsb. En equipos internos con restricciones estrictas, si «la configuración no surte efecto», lo más rápido es sospechar primero del control por directiva.

Resumen

Usar Windows Sandbox acelera considerablemente este tipo de validaciones en el desarrollo de aplicaciones para Windows.

• Aislar problemas de permisos de administrador
• Verificar la primera instalación en un entorno limpio
• Detectar dependencias de red o de recursos compartidos
• Reproducir la falta de permisos o de dependencias
• Validación ligera con restricciones cercanas a poca memoria o sin GPU

Resumido de forma práctica, se reduce aproximadamente a estos cinco puntos.

1. Cree de forma fija AppUnderTest, Scripts y Outbox
2. Separe los .wsb por escenario
3. Configure la entrada como read-only y solo la salida como read-write
4. Realice la validación con usuario estándar usando otro usuario
5. Si necesita llegar a CPU, disco o versiones antiguas de SO, recurra a una VM completa

La virtud de Sandbox no es ser una solución para todo, sino «mantener pequeña la preparación previa a la validación y poder devolver el entorno a un estado limpio cada vez».

Si se fijan los escenarios en función de esta característica, resulta más fácil aplicarlos no como «una reproducción puntual», sino como un procedimiento de validación repetible.

Artículos relacionados

• Cuándo se necesitan realmente privilegios de administrador en Windows: UAC, áreas protegidas y cómo distinguirlo en el diseño
• Cómo aislar en el código, de forma concreta, «solo los procesos que necesitan permisos de administrador» en una aplicación de Windows
• Cómo elegir el método de distribución de aplicaciones para Windows: MSI/MSIX/ClickOnce/xcopy/actualizador propio
• Introducción a la recolección de volcados de memoria en Windows: WER/ProcDump/WinDbg

Temas relacionados

• Temas técnicos de Windows

Servicios relacionados con este tema

• Desarrollo de aplicaciones para Windows
• Consultoría técnica y revisión de diseño
• Contacto

Referencias

1. Microsoft Learn, Windows Sandbox
2. Microsoft Learn, Install Windows Sandbox
3. Microsoft Learn, Use and configure Windows Sandbox
4. Microsoft Learn, Windows Sandbox sample configuration files
5. Microsoft Learn, Windows Sandbox frequently asked questions (FAQ)
6. Microsoft Learn, Windows Sandbox versions
7. Microsoft Learn, Windows Sandbox command line interface

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Para qué tipo de validaciones es adecuado Windows Sandbox?

Es adecuado para verificar la primera instalación en un entorno limpio, aislar problemas de permisos de administrador, detectar dependencias de red o de carpetas compartidas, reproducir la falta de permisos o de dependencias, y para validaciones ligeras con restricciones cercanas a poca memoria o sin GPU. Su fortaleza es que no es tan pesado como una VM completa, se inicia rápido y, al cerrarlo, desaparece limpiamente cada vez. En cambio, para reproducir otra versión de SO, ejecutar varias instancias a la vez o reproducir con precisión cuotas de CPU o saturación de disco, es más adecuada una VM completa.

¿Hay requisitos para poder usar Windows Sandbox?

Se puede usar en las ediciones Pro / Enterprise / Education de Windows. No está disponible en la edición Home. Además, es necesario tener la virtualización habilitada y disponer de una cantidad mínima de RAM, disco y núcleos de CPU. Como funciona con una compilación de Windows de la misma familia que el host, si el host es Windows 11, no sirve como entorno para reproducir Windows 10.

¿Qué se puede configurar en un archivo .wsb?

Se puede fijar la activación o desactivación de la red, el modo read-only / read-write de las carpetas compartidas, el límite de memoria (MemoryInMB), la desactivación de la vGPU, la desactivación del uso compartido del portapapeles y el comando que se ejecuta al iniciar (LogonCommand), entre otros. Si se separa un .wsb por cada finalidad, basta con hacer doble clic para recrear las veces que haga falta un entorno de validación con las mismas condiciones. Cabe señalar que, si MemoryInMB es inferior a 2048 MB, se eleva automáticamente hasta el valor mínimo necesario para iniciar, así que es realista considerar 2 GB como límite inferior de referencia para la validación con poca memoria.

¿Se puede validar el comportamiento con un usuario estándar en Windows Sandbox?

La sesión predeterminada de Sandbox tal cual no resulta fácil de usar para la validación con usuario estándar, porque el comando de inicio de sesión de Sandbox se ejecuta con la cuenta de usuario del contenedor, y se indica que esa cuenta debería ser una cuenta de administrador. Si quiere reproducir la falta de permisos con un usuario estándar, resulta más claro crear un usuario estándar dentro del Sandbox mediante un script de inicio e iniciar la aplicación como ese usuario con el comando runas.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.