Wie Sie mit Windows Sandbox die App-Validierung beschleunigen

Bei der Windows-App-Entwicklung sind die Gründe, warum die Validierung langsam wird, meist ähnlich.

• Der eigene Entwicklungsrechner ist „verschmutzt“, sodass sich Probleme bei der Erstinstallation nicht reproduzieren lassen
• Etwas tritt in der Kundenumgebung auf, aber nicht auf dem eigenen PC
• „Als Administrator ausgeführt funktioniert es“ – aber welche Rechtegrenze wirklich nötig ist, bleibt unsichtbar
• Man möchte das Verhalten bei fehlenden Rechten oder Abhängigkeiten testen, aber nicht die gewohnte Umgebung beschädigen
• Es stürzt bei wenig Speicher oder ohne GPU ab, aber eine vollständige VM dafür jedes Mal aufzusetzen, lohnt sich nicht

In solchen Fällen ist die Windows Sandbox recht gut zu gebrauchen.

Sie ist nicht so schwergewichtig wie eine vollständige VM, startet schnell, und beim Schließen wird jedes Mal alles sauber gelöscht – das passt gut zur Anforderung, „mit demselben Windows-Build in wenigen Minuten eine saubere Testumgebung neu aufzubauen“.

Öffnet man jedoch gedankenlos jedes Mal nur eine leere Sandbox, steigt die Effizienz nicht sonderlich. Was in der Praxis wirklich etwas bringt, ist der Betrieb, bei dem für jedes Testszenario eine eigene .wsb-Datei festgelegt wird, ein schreibgeschützter Eingabeordner von einem nur beschreibbaren Sammelordner getrennt wird und zwischen Administrator-, Standardbenutzer- und eingeschränkten Profilen gewechselt wird.

In diesem Artikel wird diese Vorgehensweise mit Fokus auf die Windows-App-Entwicklung geordnet. Der Inhalt setzt auf den offiziellen Informationen von Microsoft auf, die mit Stand April 2026 einsehbar sind.

Voraussetzungen für diesen Artikel

In diesem Artikel verwendete Begriffe

Begriffe, die im Englischen stehen bleiben, sind hier vorab zusammengefasst.

Inhaltsverzeichnis

• Zunächst das Fazit
• Warum die Windows Sandbox gut zur Entwicklungsvalidierung passt
• Einschränkungen, die man zuerst kennen sollte
• Eine Verzeichnisstruktur, die sich vorab lohnt
• Den Smoke-Test in einer sauberen Umgebung zu einem einzigen Doppelklick machen
• Vorgehen zur Isolierung von Problemen mit Administratorrechten
• Absichtlich einen Zustand mit fehlenden Rechten oder Abhängigkeiten schaffen
• Eine ressourcenknappe Umgebung schaffen
• Ab Windows 11 24H2 lässt sich auch die CLI gut einsetzen
• Betriebliche Hinweise, die man nicht übersehen sollte
• Zusammenfassung
• Verwandte Artikel
• Referenzen

Zunächst das Fazit

Die Schlussfolgerungen zuerst.

• Die Windows Sandbox eignet sich für die Reproduktion sauberer Umgebungen, die Erstinstallationsprüfung, die Isolierung von Problemen mit Administratorrechten und das Aufspüren fehlender Abhängigkeiten.
• Statt jedes Mal von Hand in der GUI zu arbeiten, ist es schneller, für jeden Verwendungszweck eine eigene .wsb-Datei anzulegen.
• Bei der Host-Freigabe verringert die Trennung Eingabe als read-only, nur Ausgabe als read-write die Zahl der Unfälle.
• Die Standard-Sandbox-Sitzung lässt sich nur schwer unverändert für Tests als Standardbenutzer nutzen. Wer Standardbenutzer-Tests durchführen möchte, legt in der Sandbox einen eigenen Benutzer an und startet die App mit diesem.
• Für die Reproduktion von wenig Speicher oder fehlender GPU helfen in der .wsb das Einstellen von MemoryInMB und das Deaktivieren von VGpu (virtuelle GPU-Freigabe).
• Wer jedoch CPU-Kontingente, Speicherplatzengpässe, mehrere gleichzeitige Instanzen oder die Reproduktion einer anderen OS-Version benötigt, ist mit einer vollständigen VM besser bedient als mit der Windows Sandbox.

Kurz gesagt ist die Windows Sandbox eine Testumgebung, die „leicht, aber wegwerfbar“, „schnell, aber auf dieselbe OS-Familie beschränkt“ und „begrenzt, aber für die Praxis durchaus ausreichend“ ist. Wer sich diese Position vorab klarmacht, setzt sie an der richtigen Stelle ein.

Warum die Windows Sandbox gut zur Entwicklungsvalidierung passt

Es gibt vier Gründe, warum die Windows Sandbox gut zur Windows-App-Entwicklung passt.

Beim Schließen wird jedes Mal alles zurückgesetzt

Das ist der wichtigste Punkt.

Installationsprogramme wiederholt ausprobieren, Einstellungen kaputt machen, an der Registrierung herumspielen, Voraussetzungen installieren und wieder entfernen – macht man das auf dem eigentlichen Entwicklungsrechner, wird daraus nach und nach „eine Umgebung, bei der niemand mehr weiß, was installiert ist“.

In der Sandbox verschwindet beim Schließen alles. Deshalb lassen sich Probleme, die nur bei der Erstinstallation auftreten, und Probleme, die nur deshalb unsichtbar sind, weil eine Voraussetzung zufällig lokal vorhanden ist, leichter finden.

Eine saubere Umgebung derselben Windows-Familie lässt sich sofort erstellen

Die Windows Sandbox setzt voraus, dass sie dieselbe Windows-Build-Familie wie der Host verwendet. Das ist zwar eine Einschränkung, bedeutet umgekehrt aber auch, dass sich sofort eine saubere Umgebung derselben Familie wie das lokale Windows 11 erstellen lässt.

Bei einer Konstellation wie „der Kunde nutzt Windows 11 24H2, wir auch“ lässt sich damit ziemlich bequem arbeiten.

Leichter als eine vollständige VM, mit geringerem Verwaltungsaufwand

Vollständige VMs unter Hyper-V oder VMware sind leistungsfähig, aber wenn der Zweck jedes Mal nur

• die Installationsschritte zu prüfen
• zu prüfen, wie UAC-Eingabeaufforderungen erscheinen
• Fehler bei fehlenden Rechten zu prüfen
• Protokolle bei fehlenden Abhängigkeiten zu prüfen
• einen Smoke-Test in sauberer Umgebung durchzuführen

ist, sind sie oft eher zu schwergewichtig.

Die Windows Sandbox bringt kaum OS-Image-Verwaltung oder Snapshot-Pflege mit sich, weshalb ihre Stärke darin liegt, dass sich „ich möchte kurz etwas reproduzieren“-Tests leicht umsetzen lassen.

Szenarien lassen sich mit .wsb und der CLI festlegen

Der eigentliche Wert der Sandbox liegt nicht nur darin, „gefahrlos etwas auszuprobieren“, sondern darin, dasselbe Vorgehen beliebig oft unter denselben Bedingungen wiederholen zu können.

• Netzwerk an / aus
• Freigegebene Ordner read-only / read-write
• Wenig Speicher
• Keine GPU-Freigabe
• Keine Zwischenablagefreigabe
• Ausführung eines bestimmten Skripts beim Start

Legt man das in einer .wsb-Datei oder über die CLI ab Windows 11 24H2 fest, wird aus dem Test statt „spontaner Handarbeit“ ein „wiederholbares Vorgehen“.

Einschränkungen, die man zuerst kennen sollte

Die Sandbox ist praktisch, eignet sich aber nicht für alles. Das sollte man vorab wissen.

Es gibt Einschränkungen bei den nutzbaren Editionen

Die Windows Sandbox lässt sich unter Windows Pro / Enterprise / Education nutzen. Unter der Home-Edition steht sie nicht zur Verfügung.

Da interne Entwicklungsrechner oft mit Pro laufen, Vertriebsrechner oder private PCs aber häufig mit Home, stolpert man hier leicht.

Es gibt Virtualisierungsvoraussetzungen

Für die Nutzung müssen die Virtualisierungsfunktionen aktiviert sein und ein Mindestmaß an RAM, Speicherplatz und CPU-Kernen vorhanden sein. So leicht sie ist, völlig kostenlos ist sie nicht.

Die Sandbox verwendet dieselbe OS-Familie wie der Host

Das ist in der Praxis recht wichtig.

Die Windows Sandbox eignet sich nicht für die Validierung einer anderen OS-Version.

• Ist der Host Windows 11, wird daraus keine Windows-10-Reproduktionsumgebung
• Nutzt der Kunde einen älteren Build, lässt sich diese Lücke nicht schließen

Für Kompatibilitätsprüfungen zwischen OS-Versionen oder Probleme, die an alte Builds gebunden sind, sollte deshalb von vornherein eine vollständige VM gewählt werden.

Mehrere Instanzen lassen sich nicht gleichzeitig starten

Derzeit eignet sich die Windows Sandbox nicht dafür, mehrere Instanzen gleichzeitig laufen zu lassen.

Wer eine Testmatrix parallel durchlaufen möchte, ist mit Hyper-V oder Ähnlichem besser bedient.

Netzwerk und Zwischenablage sind standardmäßig aktiviert

Das übersieht man leicht.

Die Windows Sandbox hat standardmäßig eine aktive Netzwerkverbindung. Auch die Zwischenablagefreigabe ist standardmäßig aktiviert.

Startet man sie also gedankenlos, ist sie keine „vollständig geschlossene Welt“. Für die Prüfung unbekannter Dateien oder die Reproduktion fehlender Abhängigkeiten ist es sicherer, dies von Anfang an explizit über .wsb zu steuern.

Ab Windows 11 24H2 lassen sich einige Inbox-Apps nicht nutzen

In der Sandbox unter Windows 11 24H2 und neuer lassen sich einige Inbox-Store-Apps wie Editor, Terminal, Rechner und Fotos nicht nutzen.

Deshalb ist es sinnvoll, Startautomatisierung und Hilfsvorgänge auf cmd.exe, powershell.exe und explorer.exe aufzubauen.

Eine Verzeichnisstruktur, die sich vorab lohnt

Statt die freigegebenen Ordner jedes Mal spontan festzulegen, spart es viel Aufwand, vorab einen einzigen Ablageort für Tests anzulegen.

Zum Beispiel eine Struktur wie diese.

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

Die Rollen teilen sich so auf.

• AppUnderTest: das Testobjekt. Freigabe read-only
• Scripts: Startskripte. Freigabe read-only
• Outbox: Protokolle, Dumps, exportierte Ergebnisse. Freigabe read-write

Bei dieser Aufteilung ist der einzige Ort, an dem die Sandbox auf den Host zurückschreiben kann, Outbox, was recht sicher ist.

Zusätzlich werden auch die .wsb-Dateien je Szenario festgelegt.

Allein damit sinken die Einstiegskosten für Tests erheblich.

Den Smoke-Test in einer sauberen Umgebung zu einem einzigen Doppelklick machen

Als Erstes lohnt es sich, eine Sandbox für Smoke-Tests in sauberer Umgebung anzulegen.

Beispiel: 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>

Für diesen Zweck sind diese 4 Punkte wichtig.

• Das Verteilungsobjekt liegt in AppUnderTest
• Dieser Ordner wird read-only freigegeben
• Nur Protokolle und Ergebnisse werden nach Outbox geschrieben
• Will man Netzwerkabhängigkeiten nicht sehen, wird das Netzwerk von Anfang an getrennt

So lässt sich durch bloßes Austauschen des Verteilungsobjekts und Doppelklicken der .wsb jedes Mal eine saubere Erstprüfung durchführen.

Woran man den Erfolg erkennt

Bei der ersten Nutzung ist am schwersten zu erkennen, „wie weit man kommen muss, damit es als Erfolg gilt“. Hier die Prüfpunkte im Überblick.

Ein Doppelklick auf die .wsb öffnet eine eigene, vom Host getrennte Arbeitsoberfläche als ein einziges Fenster. Der Inhalt ist ein Windows im Ausgangszustand mit Standardhintergrund und leerer Arbeitsoberfläche. Der Hintergrund des Hosts, installierte Apps und das angemeldete Konto werden nicht übernommen. Ist das erreicht, war der Start selbst bereits erfolgreich.

Anschließend wird der in LogonCommand eingetragene Befehl ausgeführt. Bei der obigen 00-clean-smoke.wsb öffnet sich in der Sandbox der Explorer, und der Inhalt von C:\Work\AppUnderTest wird angezeigt.

Ob die Sandbox tatsächlich mit der beabsichtigten Konfiguration gestartet ist, lässt sich zuverlässig prüfen, indem man in der Sandbox einen Befehl ausführt. Öffnen Sie im Startmenü der Sandbox powershell.exe und führen Sie der Reihe nach Folgendes aus.

# 1) Ist der freigegebene Ordner an der vorgesehenen Stelle sichtbar?
Get-ChildItem C:\Work

# 2) Die Eingabeseite sollte schreibgeschützt sein. Ein Fehler bedeutet, es funktioniert wie beabsichtigt
New-Item -Path C:\Work\AppUnderTest\write-test.txt -ItemType File

# 3) Die Ausgabeseite sollte beschreibbar sein. Erfolg bedeutet, es funktioniert wie beabsichtigt
New-Item -Path C:\Work\Outbox\write-test.txt -ItemType File

# 4) Wurde das Netzwerk absichtlich getrennt, sollte die Verbindung fehlschlagen
Test-NetConnection -ComputerName www.microsoft.com -Port 443

# 5) Als wer läuft es gerade? In der Standardsitzung als Administratorkonto
whoami
whoami /groups

Die Datei write-test.txt aus Schritt 3 erscheint auch auf der Hostseite in C:\SandboxFixtures\Outbox. Ist das der Fall, bestätigt das, dass der Rückweg für Protokolle und Dumps funktioniert.

Funktioniert es nicht, prüfen Sie in dieser Reihenfolge:

• Ein Doppelklick tut nichts, oder es kommt zu einem Fehler → Möglicherweise ist das XML der .wsb fehlerhaft. Richten Sie sich bei den Elementnamen nach der Schreibweise in der Microsoft-Learn-Dokumentation zur Konfigurationsdatei.
• In C:\Work ist nichts vorhanden → Der unter HostFolder angegebene Pfad auf der Hostseite existiert nicht. Der angegebene freigegebene Ordner muss auf der Hostseite tatsächlich existieren.
• Im Startmenü fehlt „Windows-Sandbox“ → Entweder sind die Voraussetzungen nicht erfüllt, oder das Windows-Feature ist nicht aktiviert. Prüfen Sie die Tabelle mit den Voraussetzungen zu Beginn dieses Artikels.

Probleme, die sich hier leicht finden lassen

In diesem Stadium finden sich häufig Probleme wie diese.

• Eine auf dem Entwicklungsrechner vorhandene DLL / Laufzeitumgebung fehlt in der Produktion
• Die Voraussetzung von WebView2 oder dem VC++-Redistributable-Paket ist unausgesprochen
• Das Verzeichnis oder die Konfigurationsdatei, die nur beim ersten Start angelegt wird, landet am falschen Ort
• Die App versucht, Laufzeitdaten unter Program Files zu schreiben, und stürzt ab
• Ein Zertifikat, eine Schriftart oder eine Einstellung, die „beim Entwickler zufällig vorhanden war“, wird vorausgesetzt

Wichtig ist, alles, was auf der Sandbox-Seite passiert, unbedingt nach Outbox auszugeben. Da beim Schließen alles verschwindet, dürfen Protokolle und Dumps nicht einfach darin verbleiben.

Eine Variante mit Netzwerk als separate Datei vorhalten

Handelt es sich beim Ziel um einen Web-Installer oder eine App mit Online-Authentifizierung, zeigt eine dauerhaft getrennte Netzwerkverbindung nur eine andere Art von Problemen.

In diesem Fall ist es übersichtlicher, mit derselben Struktur eine separate Datei wie 01-clean-online.wsb anzulegen und „die Reproduktion mit Offline-Annahme“ nicht mit „der Reproduktion mit Online-Annahme“ zu vermischen.

Vorgehen zur Isolierung von Problemen mit Administratorrechten

Bei der Windows-App-Entwicklung vermischen sich Fragen zu Administratorrechten stark.

• Werden sie nur bei der Installation benötigt?
• Werden sie auch zur Laufzeit benötigt?
• Werden sie nur für bestimmte Einstellungsänderungen benötigt?
• Oder liegt es eigentlich nur an einem falschen Speicherort?

Dieses Thema selbst haben wir bereits in folgenden Artikeln geordnet.

• Wann Windows tatsächlich Administratorrechte benötigt – UAC, geschützte Bereiche und wie man es am Design erkennt
• Wie man in einer Windows-App konkret „nur die Vorgänge, die Administratorrechte benötigen“ abtrennt

Hier konzentrieren wir uns darauf, wie sich mit der Sandbox der Test beschleunigen lässt.

Worauf zuerst zu achten ist

In der Sandbox möchte man zuerst Grenzen wie diese prüfen.

• Schreibt der Installer nach Program Files oder HKLM?
• Gibt es eine Dienstregistrierung, eine Treiberinstallation oder Änderungen an der Firewall-Konfiguration?
• Versucht das Update-Programm, Dinge maschinenweit zu ersetzen?
• Versucht die App, Laufzeiteinstellungen, Protokolle oder Caches in geschützte Bereiche zu schreiben?
• Gibt es OS-Integration wie Shell-Erweiterungen oder COM-Registrierung?

Ziel ist also, „Vorgänge, die wirklich Administratorrechte benötigen“ von „Vorgängen, bei denen nur der Laufzeit-Speicherort falsch ist“ zu trennen.

Der Standardzustand der Sandbox allein ergibt noch keinen Standardbenutzer-Test

Das ist wichtig.

Der Anmeldebefehl der Windows Sandbox läuft unter dem Benutzerkonto des Containers. Auch die Dokumentation von Microsoft Learn besagt, dass dieser Container-Benutzer ein Administratorkonto sein soll.

Das bedeutet: Die Standard-Sandbox-Sitzung lässt sich nur schwer unverändert für „die Reproduktion als Standardbenutzer“ nutzen.

Wer Probleme mit Administratorrechten sauber isolieren möchte, ist besser beraten, in der Sandbox einen separaten Standardbenutzer anzulegen und die App mit diesem zu starten.

Beispiel: 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>

Beispiel: 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'

Mit dieser Einrichtung steht ab dem Moment, in dem die Sandbox startet, ein Standardbenutzer bereit, sodass sich direkt Folgendes ausprobieren lässt.

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

Was sich dadurch zeigt

Mit dieser Vorgehensweise lassen sich Probleme wie diese leichter erkennen.

• Laufzeiteinstellungen werden neben der EXE gespeichert und scheitern
• Ein Schreibvorgang nach HKLM scheitert
• Das Update-Programm setzt maschinenweiten Betrieb voraus
• Protokolle werden unter Program Files gespeichert
• Nur eine einzige Schaltfläche benötigt Administratorrechte, aber die gesamte App setzt Erhöhung voraus

Probleme mit Administratorrechten lassen sich manchmal schon durch Codereview erkennen. Doch mit eigenen Augen zu sehen, wo es beim tatsächlichen Betrieb als Standardbenutzer hakt, macht die gestalterische Grenze deutlich klarer.

Absichtlich einen Zustand mit fehlenden Rechten oder Abhängigkeiten schaffen

Nicht nur „kein Administrator zu sein“, sondern absichtlich einen Teil des Komforts der Umgebung zu entfernen, deckt versteckte Abhängigkeiten auf.

Beispiel: 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>

Was sich mit diesem Profil prüfen lässt

Dieses eingeschränkte Profil eignet sich für Prüfungen wie diese.

• Gibt es eine versteckte Abhängigkeit, ohne die ohne Netzwerk kein Start möglich ist?
• Wird vorausgesetzt, dass Dateien über die Zwischenablage eingebracht werden?
• Sind UI oder Berichtsverarbeitung so geschrieben, dass ein Standarddrucker sichtbar sein muss?
• Stecken hinter Vorgängen, die selbst über eine RDP-Sitzung lose funktionierten, unnötige Abhängigkeiten?
• Gibt es nachlässigen Code, der freien Schreibzugriff auf freigegebene Ordner voraussetzt?

Gerade bei Fachanwendungen kommt es häufig vor, dass „auf dem eigenen Rechner ging es problemlos“, während auf Rechnern im Feld

• Netzwerkeinschränkungen
• Einschränkungen der Zwischenablage
• kein Drucker
• Einschränkungen beim Schreiben in freigegebene Ordner

gelten. Stellt man diese Welt vorab in der Sandbox nach, gerät man später bei Rückfragen seltener ins Stocken.

Freigegebene Ordner nicht großzügig offenlegen

Auch das ist recht wichtig.

Mapped Folders in der Sandbox sind praktisch, aber Änderungen an einem schreibbar freigegebenen Ordner bleiben auf dem Host auch nach dem Schließen der Sandbox erhalten.

Deshalb sollten Freigaben wie diese vermieden werden.

• C:\Users vollständig freigeben
• Das gesamte Repository mit Schreibzugriff sichtbar machen
• Downloads oder Documents unbedacht mit Schreibzugriff freigeben

Grundsätzlich empfiehlt sich eine zweistufige Aufteilung:

• Eingaben in einem eng begrenzten Ordner, read-only
• Nur Ausgaben in einer eigenen Outbox, read-write

Eine ressourcenknappe Umgebung schaffen

Die Windows Sandbox bietet keinen großen Spielraum bei der Ressourcensteuerung. Trotzdem lässt sie sich für „leicht ressourcenbeschränkte Tests“ einsetzen.

Beispiel: 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>

Probleme, die sich hierdurch leichter zeigen

Mit diesem Profil treten Probleme wie diese eher zutage.

• Übermäßiger Speicherverbrauch beim Start
• Kein Spielraum-Check beim Einlesen großer Dateien
• Ohne GPU-Freigabe wird das Rendering extrem schwerfällig
• Schlechtes Fallback-Verhalten bei WPF / WebView2 / Bildverarbeitung / Videoverarbeitung
• UI-Probleme, die „wegen der leistungsstarken GPU vor Ort“ unsichtbar blieben

Laut Microsofts Konfigurationsspezifikation wird MemoryInMB bei Werten unter 2048 MB automatisch auf den für den Start nötigen Mindestwert angehoben. Es ist also realistisch, bei Tests mit wenig Speicher in der Windows Sandbox von etwa 2 GB als Untergrenze auszugehen.

Fälle, in denen die Sandbox allein nicht ausreicht

Umgekehrt reicht die Windows Sandbox allein hier eher nicht aus.

• CPU-Auslastung stark begrenzen
• Speicherplatzengpässe präzise erzeugen
• I/O-Verzögerungen erzeugen
• Eine Matrix über mehrere Speichergrößen durchlaufen
• Langlaufende Soak-Tests dauerhaft betreiben

Hier ist es unkomplizierter, von vornherein auf eine vollständige VM etwa unter Hyper-V zu wechseln.

Die Sandbox ist gut für „eine leicht eingeschränkte Umgebung“, aber sie ist keine „präzise Lasttestplattform“.

Ab Windows 11 24H2 lässt sich auch die CLI gut einsetzen

In der neueren Windows Sandbox ab Windows 11 24H2 steht auch eine CLI zur Verfügung.

Die verfügbaren Befehle sind ungefähr diese.

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

Im einfachsten Fall sieht der Ablauf etwa so aus.

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

Zu beachten ist, dass die offiziellen Beispiele der Windows-Sandbox-CLI Disabled verwenden, während die Schemabeschreibung der .wsb-Konfigurationsdatei Disable / Enable / Default angibt. Wenn Sie inline --config in Ihren Betrieb einbauen, prüfen Sie auf dem tatsächlichen Windows-11-24H2-Gerät oder neuer, welche Schreibweise akzeptiert wird.

Kennt man die ID der laufenden Sandbox, lässt sich damit eine Verbindung herstellen:

wsb connect --id <sandbox-id>

Wo die CLI sich eignet

Die CLI zahlt sich in Situationen wie diesen aus.

• Man möchte den Sandbox-Start in ein lokales Reproduktionsskript einbauen
• Man möchte häufig genutzte Konfigurationen aus einer Batch-Datei oder PowerShell heraus aufrufen
• Man möchte einer laufenden Sandbox eine Ordnerfreigabe hinzufügen
• Man möchte lokale Testabläufe etwas automatisieren

Warum sich .wsb-Dateien trotzdem lohnen

Trotzdem sollte man die .wsb-Dateien derzeit nicht aufgeben.

Der Grund ist einfach: Sie lassen sich als Szenarioname lesen.

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

So benannt, erkennt jeder auf einen Blick den Verwendungszweck.

Die CLI ist praktisch, doch als Arbeitsteilung ist am handhabbarsten: „Die Bedingungen werden in .wsb definiert, der Start wird von der CLI umschlossen.“

Hinweise zur CLI

wsb exec hat derzeit Einschränkungen bei der Erfassung der Prozess-I/O, und für die Ausführung im Kontext eines bereits angemeldeten Benutzers ist zudem eine aktive Benutzersitzung erforderlich.

Man sollte also nicht zu viel von ihr als vollständig headless-fähiger automatischer Testplattform erwarten. Für die Automatisierung lokaler Reproduktionen ist sie praktisch, aber kein Ersatz, den man einfach an die Stelle von CI setzt.

Betriebliche Hinweise, die man nicht übersehen sollte

Zum Schluss nur die Punkte, bei denen man sich in der Praxis leicht verheddert.

Freigegebene Ordner auf ein Minimum beschränken

Die Sandbox ist isoliert, aber Mapped Folders sind mit dem Host verbunden. Ein schreibbar freigegebener Ordner wirkt sich auf den Host aus.

Nicht großzügig freigeben; beschreibbare Freigaben allein auf die Outbox konzentrieren. Das ist der Grundsatz.

Protokolle und Dumps vor dem Schließen abholen

Selbstverständlich, aber: Ist die Sandbox geschlossen, ist es weg. Genau deshalb sollte man das Ausgabeziel von Anfang an auf die Outbox festlegen.

Standardbenutzer-Tests nicht mit „der Standard-Sandbox-Sitzung, wie sie ist“ abhandeln

Wer Probleme mit Administratorrechten sauber isolieren möchte, ist mit dem Start unter einem separaten Benutzer besser beraten. Bleibt das unklar, bleibt einem übrig: „In der Sandbox lief es, aber beim Standardbenutzer des Kunden stürzt es ab.“

Für Tests zu OS-Versionsunterschieden nicht überstrapazieren

Die Sandbox eignet sich für saubere Tests innerhalb derselben OS-Familie, ist aber kein Nachbildungsgerät für ältere Windows-Versionen. Muss eine andere OS-Version betrachtet werden, sollte von vornherein eine vollständige VM gewählt werden.

Auf firmenverwalteten Rechnern können Richtlinienbeschränkungen gelten

Über Gruppenrichtlinien gesteuerte Einstellungen lassen sich mitunter nicht über eine .wsb-Datei ändern. Wenn auf einem streng verwalteten Firmenrechner „die Einstellung nicht greift“, ist es meist am schnellsten, zuerst eine Richtliniensteuerung zu vermuten.

Zusammenfassung

Mit der Windows Sandbox lassen sich Tests wie diese in der Windows-App-Entwicklung erheblich beschleunigen.

• Isolierung von Problemen mit Administratorrechten
• Erstinstallationsprüfung in sauberer Umgebung
• Aufspüren von Netzwerk- und Freigabeabhängigkeiten
• Reproduktion fehlender Rechte und fehlender Abhängigkeiten
• Leichte Einschränkungstests in Richtung wenig Speicher / ohne GPU

Auf das in der Praxis Wirksame heruntergebrochen, sind das im Grunde diese fünf Punkte.

1. AppUnderTest, Scripts und Outbox fest anlegen
2. .wsb-Dateien je Szenario aufteilen
3. Eingaben read-only, nur Ausgaben read-write machen
4. Standardbenutzer-Tests mit einem separaten Benutzer durchführen
5. Werden CPU / Speicherplatz / ältere OS-Versionen benötigt, auf eine vollständige VM wechseln

Der Vorzug der Sandbox liegt nicht darin, alles zu können, sondern darin, die Vorbereitung vor dem Test klein zu halten und die Umgebung dabei jedes Mal sauber zurücksetzen zu können.

Legt man die Szenarien passend zu dieser Eigenschaft fest, lässt sich der Test nicht als „spontane Reproduktion vor Ort“, sondern als wiederholbares Testverfahren durchführen.

Verwandte Artikel

• Wann Windows tatsächlich Administratorrechte benötigt – UAC, geschützte Bereiche und wie man es am Design erkennt
• Wie man in einer Windows-App konkret „nur die Vorgänge, die Administratorrechte benötigen“ abtrennt
• Wie man das Verteilungsverfahren für Windows-Apps wählt – MSI/MSIX/ClickOnce/xcopy/eigenes Updateverfahren
• Einführung in die Erfassung von Windows-Absturz-Dumps – WER/ProcDump/WinDbg

Verwandte Themen

• Windows-Fachthemen

Zu diesem Thema passende Leistungen

• Windows-Anwendungsentwicklung
• Technische Beratung und Design-Review
• Kontakt

Referenzen

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

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Wofür eignet sich Windows Sandbox bei der App-Entwicklung?

Sie eignet sich für die Erstüberprüfung in einer sauberen Umgebung, die Isolierung von Problemen mit Administratorrechten, das Aufspüren von Netzwerk- und Freigabeabhängigkeiten, die Reproduktion fehlender Rechte oder Abhängigkeiten sowie leichte Einschränkungstests in Richtung wenig Arbeitsspeicher oder ohne GPU. Sie ist nicht so schwergewichtig wie eine vollständige VM, startet schnell, und beim Schließen wird jedes Mal alles sauber gelöscht. Für die Reproduktion einer anderen OS-Version, mehrere gleichzeitige Instanzen oder eine strikte Reproduktion von CPU-Kontingenten und Speicherplatzengpässen eignet sich dagegen eher eine vollständige VM.

Gibt es Voraussetzungen für die Nutzung von Windows Sandbox?

Sie lässt sich unter Windows Pro / Enterprise / Education nutzen. Unter der Home-Edition steht sie nicht zur Verfügung. Außerdem müssen die Virtualisierungsfunktionen aktiviert sein und ein Mindestmaß an RAM, Speicherplatz und CPU-Kernen vorhanden sein. Da sie mit demselben Windows-Build wie der Host läuft, wird sie auf einem Windows-11-Host nicht zu einer Windows-10-Reproduktionsumgebung.

Was lässt sich in einer .wsb-Datei einstellen?

Sie können Netzwerk ein/aus, freigegebene Ordner als read-only / read-write, ein Speicherlimit (MemoryInMB), das Deaktivieren der vGPU, das Deaktivieren der Zwischenablagefreigabe sowie einen beim Start auszuführenden Befehl (LogonCommand) fest verankern. Legt man für jeden Verwendungszweck eine eigene .wsb-Datei an, lässt sich dieselbe Testumgebung beliebig oft allein per Doppelklick neu aufbauen. Da MemoryInMB bei Werten unter 2048 MB automatisch auf den für den Start nötigen Mindestwert angehoben wird, ist es realistisch, bei Tests mit wenig Speicher von 2 GB als Untergrenze auszugehen.

Lässt sich mit Windows Sandbox das Verhalten als Standardbenutzer testen?

Mit der Standard-Sandbox-Sitzung lässt sich das nur schwer testen. Der Anmeldebefehl der Sandbox läuft unter dem Benutzerkonto des Containers, und dieser Benutzer soll laut Dokumentation ein Administratorkonto sein. Wenn Sie fehlende Rechte als Standardbenutzer reproduzieren möchten, ist es übersichtlicher, per Startskript innerhalb der Sandbox einen Standardbenutzer anzulegen und die App mit dem Befehl runas als dieser Benutzer zu starten.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.