Der Fehler 0x80370106 weist bei der Windows-Sandbox auf einen schwerwiegenden Fehler der gestarteten virtuellen Umgebung hin. Der Code allein verrät jedoch nicht, ob die Ursache bei der Virtualisierung, einer Sandbox-Konfiguration oder beschädigten Windows-Komponenten liegt. Starte die Windows-Sandbox zunächst direkt über das Startmenü und nicht über eine gespeicherte Konfigurationsdatei. Prüfe danach, ob Windows die benötigte Virtualisierung tatsächlich nutzen kann. Sicherheitsfunktionen wie die Speicherintegrität solltest du nicht versuchsweise abschalten.
Die folgende Prüfreihenfolge trennt einen Fehler der Sandbox selbst von Problemen ihrer technischen Grundlage. Nach jeder Änderung folgt ein erneuter Startversuch. Sobald die Sandbox wieder funktioniert, sind weitere Reparaturen unnötig.
Den Startfehler eingrenzen, bevor du Windows veränderst
Notiere zuerst den vollständigen Fehlertext einschließlich aller zusätzlichen Angaben. Bei 0x80370106 sind Begleitmeldungen und Ereignisse aussagekräftiger als der Zahlencode allein. Andere Sandbox-Fehlercodes können ähnlich aussehen, aber auf eine andere Fehlerklasse hinweisen.
Öffne mit Windows-Taste + R den folgenden Befehl. Er liest die Windows-Version aus und verändert nichts:
winverNotiere Version und Betriebssystembuild sowie die Edition. Die Windows-Sandbox gehört zu den unterstützten Pro-, Enterprise- und Education-Editionen, nicht zur Home-Edition. Falls die Funktion auf einem Home-System durch ein nachträgliches Skript eingerichtet wurde, ist das keine regulär unterstützte Ausgangslage. Weitere Reparaturskripte aus unbekannter Herkunft sind dafür kein verlässlicher Lösungsweg.
Führe anschließend diese erste Prüfung durch:
- Speichere offene Arbeiten und starte Windows über Neu starten neu. Das ist insbesondere nach dem Aktivieren von Windows-Features erforderlich.
- Suche im Startmenü nach Windows-Sandbox und starte den Eintrag direkt. Verwende für diese Gegenprobe keine Datei mit der Endung
.wsb. - Beobachte, ob der Fehler sofort erscheint oder erst nach einem sichtbaren Sandbox-Fenster. Notiere die Uhrzeit für die spätere Ereignisprüfung.
- Falls eine normale Sandbox startet, teste erst danach wieder deine eigene Konfigurationsdatei. Scheitert nur diese, fahre mit dem Konfigurationsabschnitt fort.
Ein sofortiger Abbruch kann zu fehlenden Voraussetzungen oder einem Problem beim Erstellen der Umgebung passen. Ein bereits geöffnetes Fenster mit anschließendem Abbruch lenkt die Prüfung stärker auf den Betrieb der gestarteten Umgebung. Diese Beobachtungen sind Hinweise, keine eindeutigen Bauteil- oder Dienstdiagnosen.
Hardwarevirtualisierung und laufenden Hypervisor unterscheiden
Die Windows-Sandbox benötigt Hardwarevirtualisierung und den Windows-Hypervisor. Eine aktivierte BIOS- beziehungsweise UEFI-Option allein beweist noch nicht, dass der Hypervisor beim Windows-Start geladen wurde. Prüfe beide Ebenen getrennt.
Virtualisierung im Task-Manager prüfen
Öffne den Task-Manager mit Strg + Umschalt + Esc. Wechsle zu Leistung und wähle CPU. Bei Windows 10 musst du gegebenenfalls zuerst die erweiterte Ansicht öffnen. Im CPU-Bereich findest du auf üblichen unterstützten Systemen den Status der Virtualisierung.
- Aktiviert: Die Firmware stellt Windows die Virtualisierungsfunktion bereit. Prüfe als Nächstes den Hypervisor.
- Deaktiviert: Prüfe im Geräte- oder Mainboardhandbuch die Einstellung für Intel Virtualization Technology beziehungsweise AMD SVM. Die Bezeichnung und Position unterscheiden sich je nach Firmware.
- Windows läuft selbst in einer virtuellen Maschine: Der äußere Hypervisor muss die Virtualisierungserweiterungen an die Windows-VM weiterreichen. Eine Änderung innerhalb des Gast-UEFI reicht dafür nicht.
Ändere im UEFI ausschließlich die zugehörige Virtualisierungsoption. Schalte weder TPM noch Secure Boot ab und ändere nicht den Speichermodus des Laufwerkscontrollers. Bei einem mit BitLocker geschützten Gerät sollte vor Firmwareänderungen der Wiederherstellungsschlüssel zugänglich sein. Breche ab, wenn du die Einstellung nicht sicher zuordnen kannst; eine Firmwareaktualisierung ist kein erster Reparaturschritt für diesen Sandbox-Fehler.
Für die Windows-Sandbox sind außerdem ausreichende Ressourcen nötig. Zur grundlegenden Ausstattung gehören mindestens 4 GB Arbeitsspeicher, zwei CPU-Kerne und etwa 1 GB freier Speicherplatz. 8 GB RAM bieten mehr Spielraum. Ein Rechner, der diese Untergrenzen gerade erreicht und gleichzeitig mehrere virtuelle Maschinen betreibt, hat möglicherweise zu wenig freie Ressourcen. Beende für den Test andere VMs regulär, statt ihre Prozesse im Task-Manager abzuschießen.
Erkennen, ob der Windows-Hypervisor geladen wurde
Öffne die Systeminformationen über Windows-Taste + R:
msinfo32Prüfe die Systemübersicht. Wenn Windows einen laufenden Hypervisor erkennt, erscheint dort ein entsprechender Hinweis. In diesem Zustand werden die einzelnen Hyper-V-Anforderungen möglicherweise nicht mehr separat dargestellt. Das ist kein Fehler und kein Beleg für fehlende Prozessorunterstützung.
Wird kein Hypervisor erkannt, prüfe die angezeigten Hyper-V-Anforderungen, etwa Virtualisierung in der Firmware, hardwaregestützte Datenausführungsverhinderung und Adressübersetzung der zweiten Ebene. Ein negativer Eintrag führt zunächst zur entsprechenden Hardware- oder Firmwareprüfung. Werden die Anforderungen erfüllt, ist die Startkonfiguration der nächste Prüfpunkt.
Eine deaktivierte Hypervisor-Startoption korrigieren
Eine frühere Anpassung für andere Virtualisierungssoftware kann verhindern, dass Windows seinen Hypervisor lädt. Prüfe diese Möglichkeit nur dann weiter, wenn die Firmwarevirtualisierung aktiviert ist, aber kein laufender Hypervisor erkannt wird.
Öffne die Eingabeaufforderung als Administrator. Verwende für die folgenden BCDEdit-Befehle ausdrücklich diese Shell. Der erste Befehl liest ausschließlich den Starteintrag des laufenden Windows aus:
bcdedit /enum {current}Suche nach hypervisorlaunchtype. Der Wert Off verhindert den automatischen Start des Hypervisors. Der Wert Auto ist mit dessen automatischem Start vereinbar, garantiert aber noch keinen erfolgreichen Betrieb. Fehlt die Zeile, ist das allein kein Beweis für eine deaktivierte Startoption.
Bevor du einen gefundenen Wert Off änderst, notiere ihn und sichere die Startkonfiguration. Der folgende Befehl erstellt im Stammverzeichnis des Systemlaufwerks eine Sicherungsdatei. Verwende einen noch nicht vorhandenen Dateinamen:
bcdedit /export %SystemDrive%\bcd-sandbox-backupFahre nur fort, wenn der Export erfolgreich war. Auf einem verwalteten Firmen-PC solltest du die Änderung mit der IT abstimmen. Halte bei aktivem BitLocker den Wiederherstellungsschlüssel bereit.
Dieser Befehl verändert den aktuellen Windows-Starteintrag und erlaubt den automatischen Hypervisor-Start:
bcdedit /set {current} hypervisorlaunchtype autoNach der Erfolgsmeldung ist ein Neustart erforderlich. Prüfe anschließend in den Systeminformationen, ob der Hypervisor erkannt wird, und starte dann die Windows-Sandbox.
War vorher ausdrücklich Off gesetzt und musst du genau diesen Zustand wiederherstellen, lautet der Rückweg:
bcdedit /set {current} hypervisorlaunchtype offAuch diese Änderung wird erst nach einem Neustart wirksam. Sie kann neben der Sandbox weitere Funktionen beeinträchtigen, die den Windows-Hypervisor benötigen. Importiere nicht pauschal die gesamte BCD-Sicherung, um nur diesen einzelnen Wert zurückzustellen.
Windows-Feature und zugehörige Dienste gezielt prüfen
Die Windows-Sandbox muss als optionales Windows-Feature vollständig aktiviert sein. Es ist nicht nötig, vorsorglich sämtliche Hyper-V-Verwaltungswerkzeuge, die Windows-Hypervisor-Plattform und die Plattform für virtuelle Computer zusätzlich anzuhaken. Diese Komponenten haben unterschiedliche Aufgaben und ersetzen keine Fehlerdiagnose.
Öffne mit Windows-Taste + R die Windows-Features:
optionalfeaturesPrüfe den Eintrag Windows-Sandbox. Ist er nicht aktiviert, aktiviere ihn, bestätige die Installation und starte Windows neu. Fehlt der Eintrag ganz, prüfe zuerst Edition und Unterstützung des Systems. In einer verwalteten Umgebung können außerdem Richtlinien oder die Bereitstellung von Windows-Komponenten eine Rolle spielen.
Alternativ kannst du den Featurestatus in einer PowerShell mit Administratorrechten auslesen. Dieser Befehl verändert nichts:
Get-WindowsOptionalFeature -Online -FeatureName Containers-DisposableClientVMDer Status Enabled bedeutet, dass das Feature aktiviert ist. Ein Status mit Pending weist auf eine noch ausstehende Verarbeitung hin; starte Windows neu, bevor du weitere Reparaturen versuchst. Meldet Windows einen unbekannten Featurenamen, ist das kein Anlass, fremde Installationspakete nachzuladen. Prüfe die unterstützte Windows-Ausgabe und die Komponentenbereitstellung.
Für den Betrieb der virtuellen Umgebung ist unter anderem der Dienst Hyper-V-Hostcomputerdienst mit dem internen Namen vmcompute relevant. Sein Zustand lässt sich in derselben administrativen PowerShell auslesen:
Get-Service -Name vmcomputeEin gestoppter Dienst beweist noch keinen Defekt, weil Dienste bedarfsgesteuert starten können. Prüfe seinen Zustand erneut direkt nach einem fehlgeschlagenen Sandbox-Start. Ist der Dienst ausdrücklich deaktiviert oder fehlt er trotz aktivierter Sandbox, untersuche Richtlinien und Featureinstallation. Stelle nicht sämtliche Virtualisierungsdienste pauschal auf Automatisch.
Nur eine .wsb-Datei scheitert: Konfiguration isolieren
Startet die Windows-Sandbox aus dem Startmenü, während eine bestimmte .wsb-Datei scheitert, funktionieren wesentliche Teile der Virtualisierungsgrundlage bereits. Die Untersuchung sollte dann bei den Einstellungen dieser Datei bleiben, statt die Bootkonfiguration zu verändern.
Erstelle zunächst eine Kopie deiner bisherigen Konfigurationsdatei. Eine minimale Gegenprobe besteht aus folgender vollständiger Konfiguration:
<Configuration>
</Configuration>Speichere sie im Editor mit dem Dateityp Alle Dateien beispielsweise als Sandbox-Test.wsb. Prüfe im Explorer bei eingeblendeten Dateinamenerweiterungen, dass die Datei nicht versehentlich auf .wsb.txt endet. Öffne sie anschließend per Doppelklick.
Funktioniert die minimale Datei, übernimm jeweils nur eine Einstellung aus deiner ursprünglichen Konfiguration und teste erneut. Besonders aufschlussreich sind Einstellungen für virtuelle Grafik, eingebundene Hostordner und automatische Startbefehle. Prüfe bei eingebundenen Ordnern, ob der Hostpfad existiert und dein Konto darauf zugreifen darf. Ein Startbefehl innerhalb der Sandbox muss zu den dort tatsächlich verfügbaren Programmen und Pfaden passen.
Falls die bisherigen Beobachtungen auf die virtuelle Grafik hindeuten, kannst du deren Deaktivierung separat testen:
<Configuration>
<VGpu>Disable</VGpu>
</Configuration>Startet nur diese Variante, ist der Grafikpfad ein sinnvoller Ansatz für die weitere Treiberprüfung. Das beweist jedoch keinen bestimmten Treiberdefekt. Der Rückweg besteht darin, die Testdatei zu entfernen oder wieder die gesicherte Originaldatei zu verwenden. Die Windows-weite Grafikkonfiguration wird durch diese Datei nicht dauerhaft geändert.
Fehlerzeitpunkt auswerten statt Dienste auf Verdacht umzubauen
Bleibt 0x80370106 trotz erfüllter Voraussetzungen bestehen, helfen Ereignisse zum genauen Startzeitpunkt bei der nächsten Entscheidung. Öffne die Ereignisanzeige über Windows-Taste + R:
eventvwr.mscUntersuche unter Windows-Protokolle die Bereiche System und Anwendung. Suche nach Warnungen und Fehlern unmittelbar zum notierten Startversuch. Unter Anwendungs- und Dienstprotokolle > Microsoft > Windows können zusätzlich Protokolle zu Hyper-V und zur Host-Compute-Infrastruktur vorhanden sein. Welche Kanäle sichtbar sind, hängt von den installierten Komponenten ab.
Erfasse Ereignisquelle, Ereignis-ID und vollständigen Meldungstext. Eine zusätzliche Meldung über Ressourcenmangel führt zu einer anderen Maßnahme als eine Meldung über einen fehlgeschlagenen Dienststart oder ein beschädigtes Paket. Exportiere relevante Ereignisse bei Bedarf für die IT oder den Microsoft-Support, statt nur einen Screenshot des Zahlencodes weiterzugeben.
Ein Vergleich mit anderen Virtualisierungsfunktionen kann ebenfalls helfen: Scheitert beispielsweise zusätzlich eine bereits eingerichtete WSL-2-Umgebung beim Start ihrer VM, spricht das für eine gemeinsame technische Ebene. Funktioniert WSL 2, ist damit aber nicht jede Sandbox-Komponente geprüft. Die Produkte teilen Infrastruktur, sind jedoch nicht identisch.
Beschädigte Komponenten reparieren und die Sandbox neu bereitstellen
Eine Komponentenreparatur ist sinnvoll, wenn die Hardwarevoraussetzungen erfüllt sind, der Hypervisor läuft und auch die Standard-Sandbox scheitert. Öffne dafür eine Eingabeaufforderung als Administrator und führe zuerst diesen Befehl aus:
DISM /Online /Cleanup-Image /RestoreHealthDISM prüft und repariert den Komponentenspeicher der laufenden Windows-Installation. Abhängig von der Konfiguration benötigt es dafür Windows Update oder eine bereitgestellte Reparaturquelle. Lasse den Vorgang bis zur Abschlussmeldung laufen. Bei einem Fehler über fehlende Quelldateien ist eine zur Installation passende Reparaturquelle nötig; beliebige ISO-Dateien oder wiederholte identische Durchläufe lösen dieses Problem nicht zuverlässig.
Nach erfolgreichem DISM-Abschluss folgt die Prüfung geschützter Systemdateien:
sfc /scannowWerden Dateien erfolgreich repariert, starte Windows neu und teste die Sandbox. Meldet SFC nicht reparierbare Dateien, sind die Reparaturprotokolle und die Windows-Wartung der nächste Ansatz. Beide Befehle verändern bei Bedarf Systemkomponenten; es gibt dafür keinen einfachen Gegenbefehl. Sie ersetzen keine Datensicherung vor weitergehenden Systemreparaturen.
Bleibt der Fehler bestehen, kannst du das Sandbox-Feature einmal kontrolliert neu bereitstellen:
- Schließe eine gegebenenfalls noch geöffnete Sandbox. Sichere benötigte Dateien daraus auf dem Host, denn ihr temporärer Inhalt bleibt beim Schließen nicht erhalten.
- Öffne die Windows-Features und entferne ausschließlich das Häkchen bei Windows-Sandbox.
- Bestätige die Änderung und starte Windows neu.
- Aktiviere Windows-Sandbox wieder und führe den angeforderten Neustart aus.
- Teste den Standardstart aus dem Startmenü, bevor du eigene Konfigurationsdateien verwendest.
Der gewünschte Endzustand ist wieder die aktivierte Sandbox. Falls bereits das Entfernen oder Hinzufügen des Features fehlschlägt, notiere diesen zusätzlichen Fehlercode. Lösche keine Hyper-V-Verzeichnisse, virtuellen Datenträger oder Windows-Komponentenordner von Hand.
Sonderfälle: Windows als Gast und verwaltete Rechner
Läuft Windows 10 oder Windows 11 selbst in einer VM, benötigt die Sandbox verschachtelte Virtualisierung. Der äußere Hypervisor muss diese Funktion für die ausgeschaltete Windows-VM bereitstellen können und entsprechend konfiguriert sein. Innerhalb des Windows-Gasts installierte Features können eine fehlende Freigabe durch den Host nicht ausgleichen.
Prüfe dafür die Dokumentation des tatsächlich verwendeten Hypervisors unter Nested Virtualization beziehungsweise verschachtelte Virtualisierung. Bei einer gemieteten oder zentral verwalteten VM entscheidet zusätzlich die bereitgestellte VM-Klasse beziehungsweise die Hostkonfiguration. Ohne Zugriff auf diese Ebene endet die sinnvolle Selbsthilfe bei der zuständigen Administration.
Auf einem Firmen-PC können Sicherheitsrichtlinien, Komponentenquellen und Virtualisierungseinstellungen zentral vorgegeben sein. Werden Änderungen zurückgesetzt oder scheitern sie an fehlenden Berechtigungen, solltest du keine Registry- oder Richtlinienumgehung versuchen. Übergib der IT Windows-Edition und Build, den vollständigen Fehlertext, den Startzeitpunkt und die Ergebnisse der bereits ausgeführten Prüfungen.
Für die weitere Bearbeitung beim Microsoft-Support sind die Hilfebereiche Windows Sandbox, Windows Sandbox configuration und bei einem Windows-Gast Nested virtualization passende Prüfpunkte. Erst wenn die daraus ableitbaren Voraussetzungen erfüllt sind und die gezielte Komponentenreparatur erfolglos bleibt, ist eine Reparaturinstallation von Windows zu erwägen. Ein Zurücksetzen des gesamten PCs ist für den Fehlercode 0x80370106 keine angemessene erste Maßnahme.
