Как ускорить проверку приложений с помощью Windows Sandbox

В разработке Windows-приложений причины замедления проверки обычно похожи.

• рабочая машина разработчика «загрязнена», поэтому проблемы первичной установки не воспроизводятся;
• проблема возникает в окружении заказчика, но не на вашем ПК;
• «работает, если запустить от имени администратора», но реальная граница необходимых прав не видна;
• хочется проверить поведение при нехватке прав или зависимостей, но не хочется ломать повседневное окружение;
• приложение падает при малом объёме памяти или без GPU, но каждый раз поднимать полноценную ВМ - перебор.

В таких случаях Windows Sandbox оказывается весьма удобным.

Он легче полноценной ВМ, быстро запускается и полностью очищается при каждом закрытии, поэтому хорошо сочетается с требованием «хочу за несколько минут пересоздавать чистое окружение проверки на той же сборке Windows».

Однако если бездумно каждый раз открывать пустой Sandbox, эффективность повышается не так сильно. На практике реально работает подход, при котором для каждого сценария проверки закрепляется свой .wsb, входная папка только для чтения отделена от выходной папки только для записи, а профили администратора, обычного пользователя и ограниченного окружения используются по отдельности.

В этой статье мы разберём этот подход применительно именно к разработке Windows-приложений. Материал опирается на официальную информацию Microsoft, доступную по состоянию на апрель 2026 года.

Сначала вывод

Сначала перечислим выводы.

• Windows Sandbox хорошо подходит для воспроизведения чистого окружения, проверки первичной установки, локализации проблем с правами администратора и выявления недостающих зависимостей.
• Быстрее не выполнять всё вручную через GUI каждый раз, а разделить .wsb по назначению.
• При общем доступе с хостом меньше проблем возникает, если вход разрешён только для чтения, а для записи открыт только выход.
• Стандартная сессия Sandbox неудобна для проверки от имени обычного пользователя. Если нужна такая проверка, создайте отдельного пользователя внутри Sandbox и запускайтесь от его имени.
• Для воспроизведения нехватки памяти или отсутствия GPU эффективны параметры .wsb - MemoryInMB и отключение VGpu / vGPU.
• Но если нужны квоты CPU, нехватка места на диске, несколько одновременных запусков или воспроизведение другой версии ОС, для этого лучше подходит полноценная ВМ, а не Windows Sandbox.

Иными словами, Windows Sandbox - это окружение проверки «лёгкое, но одноразовое», «быстрое, но той же линейки ОС», «ограниченное, но вполне достаточное на практике». Если заранее понять эту позицию, будет проще не ошибиться с выбором применения.

Почему Windows Sandbox хорошо сочетается с проверкой при разработке

Есть четыре причины, по которым Windows Sandbox хорошо подходит для разработки Windows-приложений.

Закрытие сбрасывает всё каждый раз

Это самая весомая причина.

Многократные попытки установки, порча настроек, изменения в реестре, добавление и удаление зависимостей - если делать это на реальной машине разработчика, она постепенно превращается в «окружение, где непонятно, что вообще установлено».

В Sandbox всё исчезает при закрытии. Поэтому легче найти проблемы, возникающие только при первичной установке, и проблемы, скрытые тем, что нужная зависимость случайно уже стоит на вашей машине.

Можно быстро создать чистое окружение той же линейки Windows

Windows Sandbox исходит из того, что использует ту же линейку сборки Windows, что и хост. Это ограничение, но оно же означает, что можно мгновенно создать чистое окружение той же линейки, что и ваш Windows 11.

Если ситуация такая, что «у заказчика тоже Windows 11 24H2, и у нас Windows 11 24H2», работать с этим довольно удобно.

Легче полноценной ВМ и дешевле в администрировании

Полноценные ВМ на Hyper-V или VMware мощны, но если каждый раз задача сводится к:

• проверке процедуры установки;
• проверке того, как выглядит запрос UAC;
• проверке ошибки при нехватке прав;
• проверке логов при нехватке зависимостей;
• дымовому тестированию в чистом окружении,

то это часто оказывается излишне тяжеловесным.

Windows Sandbox почти не требует управления образами ОС и работы со снапшотами, поэтому его сила в том, что проверка «хочу быстро воспроизвести» реально продвигается.

Сценарии можно закрепить через .wsb и CLI

Настоящая ценность Sandbox не столько в «возможности безопасно попробовать», сколько в том, что можно повторять при одних и тех же условиях сколько угодно раз.

• сеть включена / отключена;
• общая папка read-only / read-write;
• малый объём памяти;
• без общего доступа к GPU;
• без общего буфера обмена;
• выполнение определённого сценария при запуске.

Если закрепить всё это в .wsb или через CLI, доступный начиная с Windows 11 24H2, проверка превращается из «спонтанной работы» в «повторяемую процедуру».

Ограничения, которые стоит понимать заранее

Инструмент удобный, но подходит не для всего. Это лучше зафиксировать заранее.

Ограничение по доступным редакциям

Windows Sandbox доступен на редакциях Windows Pro / Enterprise / Education. На редакции Home использовать нельзя.

Внутренние машины разработчиков часто работают на Pro, а вот у отдела продаж или на личных ПК может стоять Home - это частая точка, где можно споткнуться.

Требования к виртуализации

Для использования нужны включённая виртуализация и определённый минимум ОЗУ, места на диске и ядер CPU. Как бы легковесен он ни был, полностью бесплатным ресурс не назовёшь.

Sandbox работает на той же линейке ОС, что и хост

На практике это довольно важно.

Windows Sandbox не подходит для проверки другой версии ОС.

• если хост - Windows 11, окружением-воспроизведением Windows 10 он не станет;
• если у заказчика старая сборка, эту разницу не закрыть.

Поэтому для проверки совместимости с другой версией ОС или проблем, привязанных к старой сборке, с самого начала стоит выбирать полноценную ВМ.

Нельзя запустить несколько экземпляров одновременно

На данный момент Windows Sandbox не подходит для одновременного запуска нескольких экземпляров.

Если нужно параллельно прогонять тестовую матрицу, естественнее использовать Hyper-V или аналог.

По умолчанию сеть и буфер обмена включены

Этот момент легко упустить.

Сетевое подключение в Windows Sandbox по умолчанию включено. Общий доступ к буферу обмена тоже включён по умолчанию.

То есть, если запустить его без раздумий, это не «полностью изолированный мир». Для проверки неизвестных файлов или воспроизведения нехватки зависимостей безопаснее с самого начала явно управлять этим через .wsb.

Начиная с Windows 11 24H2 часть встроенных приложений недоступна

В Sandbox на Windows 11 24H2 и новее часть встроенных Store-приложений - «Блокнот», «Терминал», «Калькулятор», «Фотографии» и другие - недоступна.

Поэтому автоматизацию при запуске и вспомогательные операции безопаснее строить, опираясь на cmd.exe, powershell.exe, explorer.exe.

Структура каталогов, которую полезно подготовить заранее

Вместо того чтобы каждый раз на месте решать, какие папки расшарить, гораздо удобнее заранее создать одно место для хранения фикстур проверки.

Например, такую структуру.

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

Роли распределяются так:

• AppUnderTest: объект проверки. Общий доступ read-only
• Scripts: сценарии запуска. Общий доступ read-only
• Outbox: логи, дампы, результаты экспорта. Общий доступ read-write

При таком разделении место, куда Sandbox может писать на хост, ограничивается папкой Outbox, что довольно безопасно.

Кроме того, .wsb тоже закрепляются по сценариям.

Уже одно это заметно снижает стоимость старта проверки.

Дымовое тестирование в чистом окружении - одним двойным щелчком

В первую очередь стоит создать Sandbox для дымового тестирования в чистом окружении.

Пример: 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>

Для этого применения важны четыре момента:

• поместить дистрибутив в AppUnderTest;
• показать эту папку только для чтения;
• выводить в Outbox только логи и результаты;
• если не нужна зависимость от сети, отключить её с самого начала.

Так, просто заменив дистрибутив и дважды щёлкнув по .wsb, вы каждый раз получаете чистую первичную проверку.

Какие проблемы легко находятся таким образом

На этом этапе часто находятся такие проблемы:

• необходимый DLL или runtime, стоявший на машине разработчика, отсутствует в продакшене;
• зависимость от WebView2 или VC++ Redistributable оказывается неявной;
• каталог или конфигурационный файл, создаваемые только при первом запуске, создаются не там;
• приложение падает при попытке записать данные времени выполнения в Program Files;
• предполагаются сертификаты, шрифты или настройки, которые «случайно были на машине разработчика».

Важно обязательно выводить всё, что происходит в Sandbox, в Outbox. В момент закрытия всё исчезает, поэтому логи и дампы нельзя оставлять внутри как есть.

Держите отдельный файл и для варианта с сетью

Если объект проверки - веб-установщик или приложение с онлайн-аутентификацией, отключённая сеть покажет вам только другой класс проблем.

В этом случае лучше создать отдельный файл с той же конфигурацией, например 01-clean-online.wsb, и не смешивать «воспроизведение офлайн-сценария» с «воспроизведением онлайн-сценария» - так проще держать всё в порядке.

Порядок локализации проблем с правами администратора

В разработке Windows-приложений вопросы прав администратора часто перепутываются между собой.

• нужны ли они только при установке;
• нужны ли они и во время выполнения;
• нужны ли они только для изменения части настроек;
• или же дело просто в неудачном месте сохранения данных.

Саму эту тему мы уже разбирали в следующих статьях.

• Когда Windows реально требует прав администратора - UAC, защищённые области и способы распознавания на уровне архитектуры
• Как конкретно выделить в Windows-приложении «только операции, требующие прав администратора»

Здесь мы сосредоточимся на том, как ускорить проверку с помощью Sandbox.

На что смотреть в первую очередь

В Sandbox сначала стоит проверить такие границы:

• пишет ли инсталлятор в Program Files или HKLM;
• есть ли регистрация службы, установка драйвера, изменение настроек брандмауэра;
• пытается ли updater подменять файлы в масштабе всей машины;
• не пытается ли приложение писать настройки, логи, кэш времени выполнения в защищённые области;
• есть ли интеграция с ОС вроде расширений оболочки или регистрации COM.

Цель - разделить «операции, которым действительно нужны права администратора» и «операции, у которых просто неудачное место записи».

Стандартное состояние Sandbox не даёт проверки от имени обычного пользователя

Этот момент важен.

Команда входа Windows Sandbox выполняется от имени учётной записи контейнера. В документации Microsoft Learn тоже указано, что эта учётная запись контейнера должна быть учётной записью администратора.

То есть стандартную сессию Sandbox неудобно использовать напрямую для «воспроизведения от имени обычного пользователя».

Если нужно корректно локализовать проблемы с правами администратора, удобнее создать внутри Sandbox отдельного обычного пользователя и запускать приложение от его имени.

Пример: 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>

Пример: 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'

При такой конфигурации к моменту запуска Sandbox обычный пользователь уже готов, и можно сразу попробовать:

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

Что это позволяет увидеть

Такой подход позволяет легче увидеть проблемы вроде:

• сбоя из-за сохранения настроек времени выполнения рядом с EXE;
• сбоя при попытке записи в HKLM;
• предположения updater о работе в масштабе всей машины;
• сохранения логов внутри Program Files;
• того, что только одной кнопке нужны права администратора, а всё приложение исходит из необходимости повышения прав.

Проблемы с правами администратора иногда можно найти уже при ревью кода. Но когда вы своими глазами видите, где именно всё застревает при реальном запуске от имени обычного пользователя, граница архитектуры становится намного отчётливее.

Намеренное создание состояния с нехваткой прав или зависимостей

Помимо простого «не администратор», если намеренно убрать часть удобств окружения, становятся видны скрытые зависимости.

Пример: 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>

Что нужно проверить в этом профиле

Этот ограниченный профиль подходит для таких проверок:

• нет ли скрытой зависимости, из-за которой приложение не запускается без сети;
• не предполагается ли передача файлов через буфер обмена;
• не написан ли UI или обработка отчётов исходя из того, что виден принтер по умолчанию;
• нет ли лишних зависимостей у операций, которые «кое-как» работали даже через RDP-сессию;
• нет ли небрежной реализации, предполагающей свободную запись в общую папку.

Особенно в бизнес-приложениях часто бывает так, что «на моей машине всё нормально работало», а на реальном месте эксплуатации:

• есть ограничения сети;
• есть ограничения буфера обмена;
• нет принтера;
• есть ограничения на запись в общую папку.

Если заранее приблизить условия Sandbox к этому миру, потом меньше проблем с обращениями от заказчика.

Не открывайте общий доступ к папкам слишком широко

Это тоже довольно важно.

Общие папки (mapped folder) в Sandbox удобны, но изменения в общей папке с правом на запись сохраняются на хосте даже после закрытия Sandbox.

Поэтому безопаснее избегать такого общего доступа:

• расшаривание целиком C:\Users;
• открытие всего репозитория на запись;
• небрежное открытие Downloads или Documents на запись.

Базовый подход - двухуровневая схема:

• входные данные - в узкой папке, только для чтения;
• только выходные данные - в выделенном Outbox, с правом записи.

Создание окружения, близкого к нехватке ресурсов

У Windows Sandbox нет большой свободы в управлении ресурсами. Тем не менее его можно использовать для «лёгкой проверки с ограниченными ресурсами».

Пример: 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>

Какие проблемы становятся заметнее

С этим профилем легче заметить такие проблемы:

• чрезмерное потребление памяти при запуске;
• отсутствие запаса по памяти при чтении больших файлов;
• крайне тяжёлый рендеринг без общего доступа к GPU;
• плохое поведение фолбэков в WPF / WebView2 / обработке изображений / обработке видео;
• проблемы UI, «невидимые на машине с мощным GPU».

По спецификации конфигурации Microsoft, значение MemoryInMB меньше 2048 МБ автоматически поднимается до минимума, необходимого для загрузки. То есть реалистично считать примерно 2 ГБ нижней границей для проверки при малом объёме памяти в Windows Sandbox.

Случаи, когда одного Sandbox недостаточно

И наоборот, вот в чём одного Windows Sandbox немного не хватает:

• жёстко ограничить использование CPU;
• точно создать нехватку места на диске;
• создать задержку I/O;
• прогонять матрицу по нескольким размерам памяти;
• запускать длительные soak-тесты в постоянном режиме.

Для этого проще сразу перейти на полноценную ВМ вроде Hyper-V.

Sandbox хорош вплоть до «лёгкого ограниченного окружения», но не является «платформой для точного нагрузочного тестирования».

Начиная с Windows 11 24H2 удобно работать и через CLI

В новом Windows Sandbox начиная с Windows 11 24H2 доступен и CLI.

Доступны примерно такие команды:

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

Например, в минимальном виде это выглядит так.

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

Заметим, что в официальных примерах Windows Sandbox CLI используется Disabled, а в описании схемы конфигурационного файла .wsb указано Disable / Enable / Default. Если встраиваете встроенный --config в рабочий процесс, проверьте, какое написание принимается на конкретной машине с Windows 11 24H2 или новее.

Если известен ID работающего Sandbox, можно подключиться так:

wsb connect --id <sandbox-id>

Когда уместен CLI

CLI работает хорошо в таких случаях:

• нужно встроить запуск Sandbox в собственный сценарий воспроизведения;
• нужно вызывать часто используемые настройки из batch-файла или PowerShell;
• нужно добавить общий доступ к папке для уже работающего Sandbox;
• нужно немного автоматизировать локальную процедуру проверки.

Почему .wsb всё же стоит сохранить

Тем не менее на данный момент отказываться от .wsb не стоит.

Причина проста: они читаются как названия сценариев.

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

При такой организации назначение файла понятно любому, кто на него взглянет.

CLI удобен, но с точки зрения эксплуатации удобнее всего распределение ролей вида «условия определяются в .wsb, а запуск оборачивается через CLI».

Замечания по CLI

У wsb exec на данный момент есть ограничения на получение I/O процесса, а при выполнении в контексте уже вошедшего пользователя также нужна активная пользовательская сессия.

Иными словами, не стоит слишком рассчитывать на него как на полностью headless-платформу для автоматического тестирования. Он удобен для автоматизации локального воспроизведения, но не является типом инструмента, который можно напрямую поставить вместо CI.

Замечания по эксплуатации, которые нельзя упускать

В заключение соберём только те моменты, на которых часто спотыкаются на практике.

Сводить общие папки к минимуму

Sandbox изолирован, но общие папки (mapped folder) связаны с хостом. Папка, расшаренная на запись, влияет на хост.

Не открывайте широкий общий доступ, сводите доступный на запись общий ресурс только к Outbox. Это базовое правило.

Собирайте логи и дампы до закрытия

Само собой разумеется, но после закрытия всё исчезает. Именно поэтому лучше с самого начала закрепить Outbox как место вывода.

Не ограничивайтесь «стандартной сессией Sandbox как есть» для проверки от имени обычного пользователя

Если нужно корректно локализовать проблемы с правами администратора, лучше запускать от имени отдельного пользователя. Если оставить это расплывчато, останется риск ситуации «в Sandbox работало, а у заказчика от имени обычного пользователя падает».

Не злоупотребляйте им для проверки различий версий ОС

Sandbox подходит для чистой проверки в рамках той же линейки ОС, но не является средством воспроизведения старых версий Windows. Если нужно посмотреть на другую ОС, с самого начала берите полноценную ВМ.

На корпоративно управляемых машинах возможны ограничения политиками

Настройки, управляемые групповой политикой (Group Policy), иногда невозможно изменить из .wsb. Если на строго управляемой корпоративной машине «настройка не применяется», быстрее всего сначала заподозрить контроль через политику.

Итог

Использование Windows Sandbox заметно ускоряет такие виды проверки в разработке Windows-приложений:

• локализацию проблем с правами администратора;
• проверку первичной установки в чистом окружении;
• выявление зависимостей от сети и общих ресурсов;
• воспроизведение нехватки прав и зависимостей;
• лёгкую ограниченную проверку при малом объёме памяти / без GPU.

Если свести это к практически работающей форме, получится примерно пять пунктов:

1. Создать фиксированные AppUnderTest, Scripts, Outbox
2. Разделить .wsb по сценариям
3. Сделать вход только для чтения, а выход - только для записи
4. Проверку от имени обычного пользователя проводить от отдельного пользователя
5. Если нужны CPU / диск / старая ОС, переходить на полноценную ВМ

Достоинство Sandbox не в универсальности, а в том, что он позволяет свести подготовку перед проверкой к минимуму, каждый раз возвращая окружение в чистое состояние.

Закрепив сценарии в соответствии с этой особенностью, проще превратить работу не в «одноразовое воспроизведение», а в повторяемую процедуру проверки.

Похожие статьи

• Когда Windows реально требует прав администратора - UAC, защищённые области и способы распознавания на уровне архитектуры
• Как конкретно выделить в Windows-приложении «только операции, требующие прав администратора»
• Как выбрать способ распространения Windows-приложения - таблица решений MSI / MSIX / ClickOnce / xcopy / собственный updater
• Введение в сбор дампов сбоев Windows-приложений - как выбирать между WER / ProcDump / WinDbg

Похожие темы

• Технические темы по Windows

Услуги, связанные с этой темой

• Разработка Windows-приложений
• Техническая консультация и ревью архитектуры
• Связаться с нами

Источники

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

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Для какой проверки подходит Windows Sandbox?

Хорошо подходит для проверки первичной установки в чистом окружении, локализации проблем с правами администратора, выявления зависимостей от сети и общих папок, воспроизведения нехватки прав или зависимостей, а также для лёгкой проверки в условиях ограничений вроде малого объёма памяти или отсутствия GPU. Его сильные стороны - меньшая тяжеловесность по сравнению с полноценной ВМ, быстрый запуск и полная очистка при каждом закрытии. С другой стороны, для воспроизведения другой версии ОС, одновременного запуска нескольких экземпляров или точного воспроизведения квот CPU и нехватки места на диске лучше подходит полноценная ВМ.

Есть ли условия для использования Windows Sandbox?

Доступен на редакциях Windows Pro / Enterprise / Education. На Home использовать нельзя. Также требуется включённая виртуализация и определённый минимум ОЗУ, места на диске и ядер CPU. Sandbox работает на той же линейке сборки Windows, что и хост, поэтому если хост - Windows 11, воспроизвести окружение Windows 10 не получится.

Что можно настроить в файле .wsb?

Можно зафиксировать включение или отключение сети, режим read-only / read-write для общих папок, лимит памяти (MemoryInMB), отключение vGPU, отключение общего буфера обмена, команду при запуске (LogonCommand) и другое. Если разделить .wsb по назначению, можно любое количество раз воссоздавать среду проверки с одинаковыми условиями одним двойным щелчком. При этом значение MemoryInMB меньше 2048 МБ автоматически поднимается до минимума, необходимого для загрузки, поэтому реалистично считать 2 ГБ нижней границей для проверки при малом объёме памяти.

Можно ли проверить работу приложения от имени обычного (не администратора) пользователя в Windows Sandbox?

В стандартной сессии Sandbox это сделать неудобно. Команда входа (logon command) в Sandbox выполняется от имени учётной записи контейнера, а эта учётная запись, согласно документации, должна быть учётной записью администратора. Если нужно воспроизвести нехватку прав у обычного пользователя, удобнее всего создать такого пользователя внутри Sandbox через сценарий запуска и запустить приложение от его имени командой runas.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.