There was a problem with WSL: Docker stoppte beim App-Umzug

Beim Verschieben von ChatGPT auf ein anderes Laufwerk über die Windows-Einstellungen stoppte Docker mit einem WSL-Fehler. Die Protokolle verzeichneten, dass das gesamte Laufwerk beim Vorbereiten des App-Speicherorts ausgehängt wurde. Allein ein Neustart von Docker stellte die Engine wieder her.

Der angezeigte WSL-Fehler

Nach dem ChatGPT-Umzug zeigte Docker Desktop den folgenden Fehler. In den Einzelheiten war außerdem zu sehen, dass Dockers WSL-Startprozess mit Exitcode 135 geendet hatte.

There was a problem with WSL
An error occurred while running a WSL command.
Please check your WSL configuration and try again.

exit status 135

Docker Desktop hatte Version 4.95.0, WSL Version 2.7.14.0. Dockers Daten-VHDX lag bereits vor dieser Migration auf Laufwerk D und hatte eine logische Größe von etwa 273GB. Wir verschoben Dockers Daten nicht zusammen mit der ChatGPT-App.

Die langen Fehlerdetails enthielten auch Protokolle des Starts am Vorabend. Die anfängliche Warnung über eine fehlende Datei componentsVersion.json lag vor einer anschließenden Laufzeit von etwa 11 Stunden. Statt die erste auffällige Warnung als direkte Ursache anzusehen, untersuchten wir Ereignisse um den tatsächlichen Stoppzeitpunkt von Docker.

Diese Unterscheidung beeinflusst die passende Abhilfe. Obwohl die Meldung zur Prüfung der WSL-Konfiguration aufforderte, war hier der Verlust des Zugriffs auf einen aktiven virtuellen Datenträger das Kernproblem, nicht eine falsche WSL-Einstellung. Vor Einstellungsänderungen oder erneuter Registrierung von WSL glichen wir Zeitstempel ab und untersuchten Windows-Ereignisse.

Das gesamte Laufwerk D wurde beim Vorbereiten des Ziels ausgehängt

Entscheidend war, NTFS-, AppXDeploymentServer- und VHDMP-Protokolle zusammen mit dem gewöhnlichen System-Protokoll zu vergleichen. Die folgende Tabelle zeigt gespeicherte Ereigniszeiten, auf Millisekunden gerundet, in japanischer Standardzeit.

Laufwerk D wurde ausgehängt, bevor das Verschieben des ChatGPT-Pakets selbst begann. Während Windows den Speicherort für Apps vorbereitete, war das gesamte Laufwerk betroffen. Selbst wenn die zu verschiebende App geschlossen ist, kann Docker beeinträchtigt werden, sofern sein virtueller Datenträger auf demselben Laufwerk geöffnet bleibt.

Als Anforderer verzeichnete NTFS svchost.exe. Der Abgleich der Ereignis-Prozess-ID mit demselben, bereits vor dem Fehler laufenden Prozess und den Windows-Dienstinformationen identifizierte StorSvc, den Speicherdienst. Dieser war vom AppX-Prozess zur Registrierung des App-Speicherorts getrennt; wir behandelten die beiden nicht als einen Prozess.

Vom Beginn des Aushängens bis zum abgeschlossenen Wiedereinhängen vergingen etwa 3.3 Sekunden. Vom erfolgreichen Aushängen bis zum abgeschlossenen Wiedereinhängen waren es etwa 0.17 Sekunden. Wir können daher nicht behaupten, Laufwerk D sei 3.3 Sekunden lang vollständig verschwunden gewesen. Das Problem war, dass selbst ein kurzer Vorgang den Zugriff auf geöffnete Dateien unterbrechen und Apps anschließend am Weiterarbeiten hindern konnte.

Was 0xC000026E zeigte

In Microsofts NTSTATUS-Definitionen bedeutet 0xC000026E den Status STATUS_VOLUME_DISMOUNTED. Er weist darauf hin, dass ein Vorgang auf einem ausgehängten Volume versucht wurde. Dieser Wert erschien auch bei den fehlgeschlagenen Lesezugriffen auf Dockers VHDX.

Auch die WSL-Kernelaufzeichnungen zeigten READ-Fehler bei Zugriffen auf virtuelle Datenträger, das Offlinegehen des Geräts und einen containerd-Absturz mit Signal 7. Die Windows-Aufzeichnungen zum virtuellen Datenträger und das spätere WSL-Herunterfahren ergaben eine konsistente zeitliche Abfolge.

Microsofts Dokumentation zum Aushängen von Volumes erklärt, dass auch bei einem verwendeten Volume ein Aushängen versucht werden kann, mit unvorhersehbaren Folgen für zugreifende Prozesse. Das Verhalten dieses Falls passt zu dieser allgemeinen Eigenschaft. Einen Aufrufstack mit genau diesem API-Aufruf haben wir jedoch nicht erfasst; ein bestimmter interner Windows-Aufrufpfad ist daher nicht nachgewiesen.

Im Begründungsfeld des Ereignisses stand User request. Das betrachteten wir nicht als Beweis dafür, dass jemand auf „USB auswerfen“ geklickt hatte. Die Prüfung des anfordernden Dienstes und der Zeitfolge stellte den Zusammenhang mit der Vorbereitung des App-Speicherorts durch Windows her.

Die untersuchten USB-, PnP- und zugehörigen Protokolle desselben Zeitraums enthielten keine Belege für physisches Trennen und Wiederverbinden. Während der Untersuchung meldete das Laufwerk zudem Healthy. Das garantiert keine fehlerfreie SSD; der hier direkt ermittelte Fehlerpfad war jedoch das Aushängen durch den Speicherdienst mit anschließend gescheiterten VHDX-Zugriffen.

Der von Microsoft dokumentierte Mechanismus PackageVolume ist eine unterstützte Art der App-Speicherung. Dennoch bedeutete die integrierte Verschiebefunktion nicht, dass andere Apps auf diesem Laufwerk unterbrechungsfrei weiterlaufen konnten.

Unity hatte zur selben Zeit ebenfalls einen E/A-Fehler

Auf demselben Laufwerk lag ein Unity-Projekt, und Unity Bug Reporter erschien. Application-Error-Aufzeichnungen zeigten einen Absturz von Unity Data Store um 13:20:47–49, vor dem Docker-Neustart. Die Ausnahme war 0xC0000006, der zugrunde liegende E/A-Status 0xC000026E.

Microsoft definiert 0xC0000006 als STATUS_IN_PAGE_ERROR. Das bedeutet, dass benötigte Daten wegen eines E/A-Fehlers nicht in den Speicher geladen werden konnten. Der zugrunde liegende Status enthielt denselben Aushängewert wie Dockers Fehler. Das stützt die Schlussfolgerung, dass Unity von derselben Nichtverfügbarkeit des Laufwerks betroffen war.

Das Dateinamensfeld des Ereignisses war jedoch leer. Deshalb identifizierten wir nicht die konkrete Datei, auf die Unity nicht zugreifen konnte. Dass Unity.dll in einem späteren Absturzprotokoll auftauchte, belegte für sich allein weder eine beschädigte DLL noch eine notwendige Neuinstallation.

Wir starteten Unity nicht sofort neu. Separat gesichert wurden 5 Dateien mit insgesamt etwa 8MB, darunter eine bestehende Szenensicherung, Protokolle und Dumps. Die Szenensicherung trug den Zeitstempel 08:31 desselben Tages; das belegt keine Sicherung ungespeicherter Arbeit unmittelbar vor dem Absturz. Während der Untersuchung überschrieben wir das ursprüngliche Projekt nicht mit den gesicherten Dateien.

Diese Abfolge schließt auch die Erklärung aus, der Docker-Neustart habe zuerst Unity beschädigt. Der erste Unity-Data-Store-Absturz lag vor dem Docker-Neustart. Zur Ursachenprüfung mussten Ereigniszeiten in den Protokollen verglichen werden; die Reihenfolge angezeigter Fenster allein genügte nicht.

Ein Docker-Neustart stellte die Engine wieder her

Nachdem wir lokal ausreichend Protokolle zur Ursachenklärung aufbewahrt und den erneuten Zugriff auf Laufwerk D bestätigt hatten, starteten wir nur Docker Desktop genau einmal neu. Dafür verwendeten wir Dockers offizielle CLI. Der folgende Befehl beeinflusst laufende Docker-Arbeit; prüfen Sie vorher, was gespeichert oder gestoppt werden muss.

docker desktop restart --timeout 45

Dockers offizielle Dokumentation zum Neustart beschreibt --timeout als Option zur Begrenzung der Wartezeit des Befehls. Sie garantiert keine Wiederherstellung innerhalb von 45 Sekunden. Dieser Aufruf endete mit Exitcode 0.

Anschließend prüften wir mit docker version die Server-Antwort und erhielten Engine 29.8.2. Auch die WSL-Bestandsliste zeigte docker-desktop wieder als Running. Das neue Backend startete in der Minute 13:27.

Die abgerufene Bestandsliste enthielt 108 Container: 1 laufend, 106 beendet und 1 erstellt. Beendete Container starteten wir nicht gesammelt. Dass die Engine antwortet, bedeutet noch nicht, dass die Datenbanken und Dienste jedes Projekts wieder wie zuvor funktionieren. Funktionsprüfungen der benötigten Dienste blieben daher bei den jeweiligen Verantwortlichen.

Zur Wiederherstellung gehörten weder Zurücksetzen auf Werkseinstellungen, Datenlöschung, Aufheben der WSL-Registrierung noch Neuinstallation. Auch WSL insgesamt fuhren wir nicht herunter, da dies mehr als Docker betroffen hätte, und luden keinen vollständigen Diagnosedatensatz extern hoch. Entscheidend war, nicht direkt vom Fehlerfenster zu einem möglichen Datenverlust zu springen.

Hilfreiche Protokolle zur Ursachenklärung

Anfangs zeigte die alleinige Prüfung des System-Protokolls die entscheidenden Aushängeereignisse nicht. Dass sie dort fehlten, bedeutete nicht, dass Windows nichts aufgezeichnet hatte. Die zeitliche Ordnung folgender Protokolle verband die Vorbereitung des App-Umzugs mit E/A-Fehlern anderer Apps.

Wer dasselbe Symptom untersucht, kann den Umfang eingrenzen, indem zuerst Zeitpunkt der Aktion, Ziellaufwerk, Speicherort des Docker-Datenträgers und Fehlertext festgehalten werden. Prüfen Sie, welche Protokollkanäle auf dem Computer verfügbar sind, und lesen Sie zunächst vorhandene Aufzeichnungen. Bei dieser Nachuntersuchung aktivierten wir keine Diagnoseeinstellungen und wiederholten nicht den fehlerauslösenden Vorgang.

Dieser Artikel veröffentlicht weder Benutzername, Benutzer-SID, Geräteseriennummern, Zugangsdaten noch Container-Umgebungsvariablen. Beim Teilen von Protokollen macht die Beschränkung auf nötige Zeiten, Fehlercodes und Vorgangsnamen auch die Ursache leichter nachvollziehbar.

Was vor einem Laufwerkswechsel festzulegen ist

Unsere Schwäche war der Fokus auf Beenden und Sichern von ChatGPT. Die Anleitung vor dem Umzug berücksichtigte die Auswirkungen auf Docker und Unity, die bereits auf Laufwerk D liefen, nicht ausreichend. Künftig würden wir für ähnliche Aufgaben auf Laufwerksebene ermitteln, was beendet werden muss.

1. Alles identifizieren, was das Ziel verwendet. Prüfen Sie virtuelle Datenträger von Docker und VMs, Datenbanken, Editorprojekte und andere Prozesse, die Dateien auf Laufwerk D geöffnet halten.
2. Ungespeicherte Arbeit und Wiederherstellungsdaten sichern. Sorgen Sie dafür, dass aktive Arbeit wiederherstellbar ist, statt nur die App selbst zu kopieren.
3. Einen Zeitpunkt wählen, zu dem die laufwerksnutzenden Prozesse beendet werden können. Berücksichtigen Sie Arbeit in anderen Chats und von anderen Verantwortlichen; verhindern Sie neue Prozessstarts während des Umzugs.
4. Die unterstützte Windows-Verschiebefunktion verwenden. Ändern Sie nicht Eigentümer oder Berechtigungen von WindowsApps beziehungsweise WpSystem, um nur die Ordner manuell zu verschieben.
5. Umzug und andere Apps getrennt prüfen. Prüfen Sie die tatsächlich benötigten Funktionen in dieser Reihenfolge: App-Start, gespeicherte Einträge, Browser, Docker-Engine und erforderliche Dienste.

Die Protokolle bestätigten die erste Registrierung von Laufwerk D als App-Speicherort. Daraus folgt jedoch nicht, dass derselbe Fehler nach abgeschlossener Registrierung nie wieder auftreten kann. Zum Test wiederholten wir weder Registrierung noch Aushängen des produktiv genutzten Laufwerks; wir behielten die funktionierende Konfiguration bei.

Das Verschieben einer App auf Laufwerk D fasst außerdem nicht alle zugehörigen Dateien dort zusammen. Hier kamen App selbst und Hauptdaten auf Laufwerk D, während aktive CLI und weitere Komponenten auf Laufwerk C blieben. Die gesamte Speicherverteilung und Größen beschreibt unser ChatGPT- und Codex-Migrationsbericht.

Erfolgreicher Umzug bedeutet nicht, dass andere Apps unbeeinträchtigt blieben

Die ChatGPT-App selbst wurde erfolgreich auf Laufwerk D verschoben. Danach prüften wir Browseraktionen und gespeicherte Einträge. Gleichzeitig wurde bei der Vorbereitung des Ziels das gesamte Laufwerk D ausgehängt. Das verursachte Fehler bei Docker und anderen Apps mit virtuellen Datenträgern auf diesem Laufwerk. Das erfolgreiche Umzugsereignis allein belegte keine unbeeinträchtigte Umgebung.

Die Protokolle erklären den direkten Fehlerpfad dieses Falls. Welcher interne Windows-Aufrufzweig das Aushängen anforderte und ob sich das Verhalten auf anderen Computern oder Windows-Versionen wiederholt, ist nicht geklärt. Die konkrete Vorsichtsmaßnahme aus diesem Fall lautet: Vor Beginn neben der zu verschiebenden App auch aktive Prozesse beenden, die Laufwerk D verwenden.

Häufige Fragen

Behebt eine WSL-Neuinstallation „There was a problem with WSL“?

Hier war der Fehlerpfad ein verlorener Zugriff auf einen virtuellen Datenträger. Allein der Docker-Neustart stellte die Engine wieder her; WSL wurde nicht neu installiert oder deregistriert. Zuerst die Protokolle des Fehlerzeitpunkts zu prüfen schützt gespeicherte Daten besser.

Ist damit die SSD von Laufwerk D ausgefallen?

Gefunden wurde ein direkter Protokolleintrag über das Aushängen von Laufwerk D durch den Speicherdienst. Aufzeichnungen über gleichzeitiges physisches Trennen fanden wir nicht. Dieser Fall bietet keine Grundlage für die Schlussfolgerung, die SSD sei ausgefallen.

Sollte ich die integrierte Windows-Funktion zum App-Umzug vermeiden?

Das Verschieben eines Pakets auf ein anderes Volume ist eine unterstützte Windows-Funktion. Nach dieser Erfahrung würden wir Zeit für das Beenden anderer Apps am selben Ziel, Datensicherung und Funktionsprüfungen einplanen, statt diese Apps während des Umzugs weiterlaufen zu lassen.

Wenn Docker startet, ist dann alles wiederhergestellt?

Eine antwortende Engine ist von Diensten und Datenbankinhalten in einzelnen Containern zu unterscheiden. Wir bestätigten die Wiederherstellung der Engine und riefen die Bestandsliste ab; die Funktionsprüfungen benötigter Projekte bleiben separate Aufgaben.