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

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

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

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

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

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

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

Исходные условия этой статьи

Термины, которые встречаются в статье

Сначала соберём термины, которые дальше остаются на английском.

Оглавление

• Сначала выводы
• Почему Windows Sandbox хорошо подходит для проверки при разработке
• Ограничения, которые стоит знать заранее
• Структура каталогов, которую лучше подготовить сразу
• Дымовой тест в чистом окружении — одним двойным щелчком
• Как локализовать проблемы с правами администратора
• Как намеренно создать нехватку прав или зависимостей
• Как приблизить окружение к нехватке ресурсов
• Начиная с Windows 11 24H2 удобно работать и через CLI
• На что нельзя закрывать глаза в эксплуатации
• Итог
• Похожие статьи
• Источники

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 22, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

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

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

• Windows Sandbox хорошо подходит для воспроизведения чистого окружения, проверки первой установки, локализации проблем с правами администратора и выявления недостающих зависимостей.
• Быстрее не кликать всё руками в GUI каждый раз, а развести .wsb по назначению.
• При общем доступе с хостом меньше сюрпризов, если исходные файлы открыты только на чтение, а на запись — только каталог результатов.
• Сессия Sandbox по умолчанию для проверки от обычного пользователя сама по себе неудобна. Если такая проверка нужна, создайте внутри Sandbox отдельного пользователя и запускайте приложение от его имени.
• Для воспроизведения нехватки памяти или отсутствия GPU работают параметры .wsb MemoryInMB и отключение VGpu (общего доступа к виртуальному GPU).
• Но если нужны квоты 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 часть inbox-приложений недоступна

В Sandbox на Windows 11 24H2 и новее часть inbox 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 — и каждый раз получается чистая первичная проверка.

По каким признакам понять, что запуск удался

Когда пользуетесь инструментом впервые, самое неочевидное — «до какого состояния это уже успех». Ниже — на что смотреть.

После двойного щелчка по .wsb откроется отдельный рабочий стол — одним окном, не рабочий стол хоста. Внутри — Windows в исходном состоянии: стандартные обои и пустой рабочий стол. Обои хоста, установленные приложения и учётная запись, под которой вы вошли на хосте, не переносятся. Если дошли до этого экрана, сам запуск уже удался.

Затем выполняется команда из LogonCommand. В примере 00-clean-smoke.wsb внутри Sandbox откроется Проводник и покажет содержимое C:\Work\AppUnderTest.

Запустился ли Sandbox в задуманной конфигурации, надёжнее всего проверить командами внутри Sandbox. Из меню «Пуск» внутри Sandbox откройте powershell.exe и выполните по порядку:

# 1) Общие папки видны по задуманным путям
Get-ChildItem C:\Work

# 2) Каталог с исходными файлами должен быть только для чтения. Ошибка записи — ожидаемый результат
New-Item -Path C:\Work\AppUnderTest\write-test.txt -ItemType File

# 3) В каталог результатов запись должна проходить. Успех — ожидаемый результат
New-Item -Path C:\Work\Outbox\write-test.txt -ItemType File

# 4) Если сеть отключена, проверка соединения должна завершиться ошибкой
Test-NetConnection -ComputerName www.microsoft.com -Port 443

# 5) От чьего имени идёт сессия. В сессии по умолчанию это учётная запись администратора
whoami
whoami /groups

Файл write-test.txt из пункта 3 появится и на хосте, в C:\SandboxFixtures\Outbox. Если он там есть, путь сбора логов и дампов работает.

Если что-то не так, смотрите в таком порядке.

• Двойной щелчок ничего не делает или выдаёт ошибку → возможно, сломан XML в .wsb. Имена элементов должны совпадать с записью в документации Microsoft Learn по конфигурационному файлу.
• В C:\Work пусто → указанного в HostFolder пути на хосте нет. Общая папка должна указывать на реально существующий путь на хосте.
• В меню «Пуск» нет пункта «Windows Sandbox» → не выполнены исходные условия или компонент Windows не включён. Сверьтесь с таблицей исходных условий в этой статье.

Какие проблемы на этом этапе находятся чаще всего

На этом шаге часто всплывает вот что.

• DLL или runtime, которые стояли на машине разработчика, в рабочей среде отсутствуют
• зависимость от WebView2 или распространяемого пакета VC++ оказалась неявной
• каталог или файл настроек, который создаётся только при первом запуске, пишется не туда
• приложение падает, когда пытается писать данные времени выполнения в 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>

Что проверять в этом профиле

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

• нет ли hidden dependency, из-за которой приложение не стартует без сети
• не предполагается ли передача файлов через буфер обмена
• не написан ли 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
• плохое поведение fallback в WPF / WebView2 / обработке изображений / обработке видео
• проблемы UI, которые «не были видны на машине с мощным GPU»

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

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

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

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

Для этого проще сразу перейти на полноценную ВМ вроде 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 as-is.

На что нельзя закрывать глаза в эксплуатации

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

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

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 по умолчанию для этого неудобна. Команда входа выполняется от учётной записи контейнера, а эта учётная запись, по документации, должна быть учётной записью администратора. Если нужно воспроизвести нехватку прав у обычного пользователя, удобнее сценарием запуска создать такого пользователя внутри Sandbox и стартовать приложение от его имени командой runas.

Об авторе

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

Го Комура

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

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