WSL startet nicht nach Verschieben: Fehler 0xffffffff & Encrypted beheben

Sie haben Ihre Distribution auf ein anderes Laufwerk gebracht und nun startet WSL nicht nach dem Verschieben? Stattdessen sehen Sie Fehlercodes wie:

• The specified file is encrypted and the user does not have the ability to decrypt it.
• process exited with code 4294967295 (0xffffffff)
• Unspecified error

Ausgangslage: WSL startet nicht nach Verschieben auf ein anderes Laufwerk

Typisch in diesem Szenario: Die Distro verschwindet aus „Apps & Features“, die Start‑Kachel funktioniert nicht mehr, und WSL bringt diffuse Fehler. Die gute Nachricht: Ihre Linux‑Daten stecken in aller Regel unverändert in einer ext4.vhdx – nur an einem Ort und mit Attributen, mit denen WSL nichts anfangen kann. In diesem Leitfaden erklären wir, was passiert ist, wie Sie Ihre Distro zuverlässig retten und wie Sie WSL künftig korrekt und sicher auf ein anderes Laufwerk verschieben.

Was schiefgelaufen ist: WindowsApps vs. WpSystem, EFS und NTFS‑Komprimierung

Wenn Sie eine aus dem Microsoft Store installierte App (und dazu zählen die gängigen WSL‑Distros wie Ubuntu) per „Verschieben“ auf ein anderes Laufwerk umziehen, richtet Windows auf dem Ziel:

• einen Ordner „WindowsApps“ ein (App‑Binärdateien), und
• eine Struktur „WpSystem“ für benutzerspezifische App‑Daten.

Die eigentlichen WSL‑Nutzdaten – die virtuelle Linux‑Festplatte ext4.vhdx – liegen nicht in WindowsApps, sondern tief in der WpSystem‑Struktur: WpSystem[SID]\AppData\Local\Packages[Paketfamilienname]\LocalState\ext4.vhdx.

In vielen Setups ist diese WpSystem‑Struktur mit erweiterten Rechtemodellen versehen. Häufig tragen Dateien dort das NTFS‑Attribut „verschlüsselt“ (EFS) und nicht selten auch „komprimiert“. Genau das ist der Kern des Problems:

• WSL2 nutzt eine VHDX‑Datei, die vom Host unter Systemkonten (u. a. Virtual Machine Worker Process) geöffnet wird. Liegt die ext4.vhdx unter EFS, kann der Systemprozess sie nicht entschlüsseln – die Distro startet nicht.
• NTFS‑Komprimierung auf VHDX‑Dateien ist ebenfalls problematisch. Virtuelle Festplatten sollten weder EFS‑verschlüsselt noch NTFS‑komprimiert sein.

Kurz: Durch das Windows‑„Move“ erbt die ext4.vhdx Attribute/ACLs, die das Öffnen durch WSL verhindern.

Wichtig: Fassen Sie den Ordner WindowsApps nicht an, nehmen Sie keine Besitzübernahmen vor und ändern Sie dort keine Berechtigungen. Das kann den Microsoft Store und andere Apps dauerhaft beschädigen. Ihre WSL‑Daten liegen ohnehin in WpSystem – dort setzen wir an.

Diagnose: Warum WSL nicht nach Verschieben startet

• Beim Starten der Distro sehen Sie „The specified file is encrypted …“ oder „0xffffffff“.
• In „Apps & Features“ taucht die Distro gar nicht mehr auf.
• wsl –list –verbose zeigt die Distro nicht an – oder meldet sie ohne Status.

Prüfen Sie zunächst, ob WSL die Distro überhaupt noch kennt:

wsl --list --verbose

• Wird die Distro noch gelistet, ist „nur“ der Zugriff auf die VHDX gestört.
• Ist die Liste leer: Die Registrierung ist weg, die VHDX selbst existiert aber sehr wahrscheinlich noch auf dem Ziel‑Laufwerk.

Die ext4.vhdx finden: Der richtige Pfad in WpSystem

Öffnen Sie den Datei‑Explorer und navigieren Sie zum Laufwerk, auf das Sie verschoben haben (Beispiel: N:).

• Aktivieren Sie „Ausgeblendete Elemente“.
• Öffnen Sie N:\WpSystem. In der Regel kommen Sie dort ohne Besitzübernahme hinein.
• Gehen Sie in den Ordner Ihrer SID (lange Zahlen‑/Buchstabenfolge) > AppData > Local > Packages.
• Suchen Sie den Paketfamiliennamen Ihrer Distro, z. B. CanonicalGroupLimited.Ubuntu…
• Öffnen Sie LocalState – dort liegt die ext4.vhdx.

Tipp: Im Zweifel hilft PowerShell beim Suchen:

Get-ChildItem N:\WpSystem -Recurse -Filter ext4.vhdx -ErrorAction SilentlyContinue

Attribut‑Check: EFS/Komprimierung erkennen

Prüfen Sie, ob die Datei verschlüsselt/komprimiert ist:

Get-Item "N:\WpSystem\<SID>\AppData\Local\Packages\<PFN>\LocalState\ext4.vhdx" | Select Name,Length,Attributes

Enthält „Attributes“ die Flags Encrypted und/oder Compressed, kann WSL die Datei so nicht öffnen.

Der sichere Rettungsweg: Kopieren, entschlüsseln, wieder registrieren

Die WpSystem‑Ordner sind speziell geschützt. Häufig lassen sich dort EFS/Komprimierung gar nicht entfernen – der Dialog quittiert mit „The parameter is incorrect“. Die Lösung: Wir kopieren die VHDX an einen neutralen Ort, heben dort die Attribute auf und registrieren die Distro neu.

Schritt 1: WSL anhalten und ext4.vhdx herauskopieren

1) WSL stoppen:

wsl --shutdown

2) Neutralen Ordner anlegen, z. B. N:\WSL_Rescue\

3) ext4.vhdx aus LocalState nach N:\WSL_Rescue\ kopieren (nicht ausschneiden). Beim Einfügen erscheint mit etwas Glück ein Dialog „ohne Verschlüsselung kopieren“ – bestätigen Sie das. Falls nicht, geht es im nächsten Schritt weiter.

Schritt 2: EFS/Komprimierung am neutralen Ort entfernen

Versuchen Sie zuerst den Explorer (Eigenschaften > Erweitert). Alternativ per Kommandozeile:

• EFS entfernen:

cipher /d N:\WSL_Rescue\ext4.vhdx

• NTFS‑Komprimierung entfernen:

compact /u N:\WSL_Rescue\ext4.vhdx

• Prüfen:

Get-Item N:\WSL_Rescue\ext4.vhdx | Select Name,Length,Attributes

Jetzt sollten weder Encrypted noch Compressed gesetzt sein.

Schritt 3: Distro wieder „anmelden“ – drei funktionierende Varianten

Es gibt mehrere Wege, Ihre Distro aus der geretteten VHDX wieder lauffähig zu machen. Wählen Sie die Methode, die Ihre WSL‑Version unterstützt.

Variante A: wsl –import-in-place (wenn verfügbar)

Neuere WSL‑Versionen (aus dem Microsoft Store) unterstützen die Direktregistrierung einer bestehenden VHDX:

wsl --import-in-place Ubuntu-Rescued N:\WSL_Rescue\ext4.vhdx

• Ubuntu-Rescued ist der frei wählbare Distributionsname.
• Pfad ist die entschlüsselte VHDX.

Anschließend starten:

wsl -d Ubuntu-Rescued

Wenn Ihr wsl.exe den Schalter –import-in-place nicht kennt (prüfbar per wsl –help), nutzen Sie Variante B.

Variante B: „Swap‑Methode“ mit einer frischen Dummy‑Installation

1) Sauberes Ubuntu installieren:

wsl --install -d Ubuntu

2) WSL stoppen:

wsl --shutdown

3) Den Ordner der neu installierten Distro öffnen (Paketfamiliennamen ermitteln und LocalState aufrufen):

Get-AppxPackage *Ubuntu* | Select PackageFamilyName
explorer.exe "%LOCALAPPDATA%\Packages\<GefundenerPaketname>\LocalState"

4) In diesem LocalState die erzeugte Dummy‑ext4.vhdx löschen.

5) Ihre gerettete N:\WSL_Rescue\ext4.vhdx dort hinein kopieren.

6) Start testen:

wsl

Ihr altes System sollte wieder starten – unter dem Namen der frisch installierten Distro.

Variante C: Klassischer Import aus RootFS‑Tarball (sauberer Neuaufbau)

Wenn Sie ohnehin „neu, aber korrekt“ auf ein anderes Laufwerk umziehen möchten, ist der saubere Weg:

1) Ihre alte Distro retten (siehe oben) und separat sichern.
2) Offizielles RootFS Ihrer Wunsch‑Distribution herunterladen (z. B. Ubuntu‑RootFS für WSL).
3) Zielordner anlegen, z. B. N:\WSL\Ubuntu24\
4) Importieren:

wsl --import Ubuntu-24.04 N:\WSL\Ubuntu24 "C:\Pfad\zum\ubuntu-<Version>-wsl.rootfs.tar.gz" --version 2

Damit erzeugen Sie eine neue, saubere Distro auf N:\ – ohne Store‑Wrapper, ohne WpSystem, ohne EFS.

Fehlerbehebung: Wenn WSL immer noch nicht startet

„The parameter is incorrect“ beim Entfernen der Verschlüsselung

Das passiert fast immer, solange die Datei in WpSystem liegt. Kopieren Sie die VHDX erst in einen neutralen Ordner (z. B. N:\WSL_Rescue) und entfernen Sie dort EFS/Komprimierung.

„Unspecified error“ bei wsl –import

• Stellen Sie sicher, dass Sie das richtige Importverfahren nutzen. wsl –import erwartet einen TAR‑(GZ)‑RootFS. Für VHDX verwenden Sie –import-in-place (falls vorhanden) oder die Swap‑Methode.
• Pfade ohne Leerzeichen und mit ausreichend Rechten verwenden; PowerShell als Administrator starten.
• Sicherstellen, dass die VHDX nicht mehr verschlüsselt/komprimiert ist und dass kein anderer Prozess sie geöffnet hält (wsl –shutdown vorher ausführen).

Distro nicht in „Apps & Features“, aber VHDX vorhanden

Das ist erwartbar, wenn die Store‑Registrierung beschädigt ist. Registrieren Sie die VHDX mit –import-in-place neu oder nutzen Sie die Swap‑Methode.

Explorer fragt nach Besitzübernahme von WindowsApps

Abbrechen. WindowsApps nicht anfassen. Die Nutzdaten liegen in WpSystem – und selbst dort ändern wir nichts „in place“, sondern kopieren heraus.

Best Practices: Sicherstellen, dass WSL nach dem Verschieben startet

Die Windows‑„Move“‑Funktion ist für viele UWP‑Apps gedacht – für WSL‑Distros führt sie in der Praxis häufig zu genau den beschriebenen Problemen. Für WSL gibt es bewährte, robuste Wege.

Methode 1: Export/Import (empfohlen, universell)

1) Distro‑Status prüfen:

wsl --list --verbose

2) Distro exportieren:

wsl --export <DistroName> D:\Backups\<DistroName>.tar

3) Alte Distro abmelden (löscht nur die Registrierung, nicht Ihre Export‑Datei):

wsl --unregister <DistroName>

4) Auf Ziel‑Laufwerk importieren:

wsl --import <DistroName> N:\WSL\<DistroName> D:\Backups\<DistroName>.tar --version 2

5) Start testen:

wsl -d <DistroName>

Vorteile: Keine WpSystem‑Beteiligung, Sie bestimmen den Speicherort selbst. Die resultierende VHDX liegt im von Ihnen gewählten Verzeichnis und erbt keine problematischen Attribute.

Methode 2: –import-in-place (wenn verfügbar)

Haben Sie bereits eine VHDX und möchten diese direkt registrieren:

wsl --import-in-place <NeuerName> N:\WSL\<NeuerName>\ext4.vhdx

Achten Sie darauf, dass die VHDX zuvor nicht verschlüsselt/komprimiert ist und sich nicht mehr in WpSystem befindet.

Methode 3: Store‑freie Neuinstallation via RootFS

Für wiederholbare Installationen ohne Store‑Abhängigkeiten (z. B. in Dev/CI‑Umgebungen): RootFS‑Tarball der gewünschten Distribution laden und per –import installieren. Sie können so mehrere definierte Instanzen (Ubuntu‑22.04, Ubuntu‑24.04, Debian etc.) nebeneinander legen und versionieren.

Härtung und Performance: So läuft WSL stabil

• Keine EFS/Komprimierung: Legen Sie Ihre WSL‑Verzeichnisse auf einem Volume ohne NTFS‑Komprimierung an und setzen Sie auf Ordnern wie N:\WSL\ keine EFS‑Verschlüsselung.
• Kein Cloud‑Sync: Speichern Sie VHDX‑Dateien nicht in OneDrive/Dropbox/Share‑Ordnern. Synchronisation und File‑Locking kollidieren mit VMs.
• Kein Netzlaufwerk: VHDX auf UNC/Netzfreigaben sind fehleranfällig und langsam. Besser lokal (oder auf einer dedizierten NVMe) betreiben.
• Virenscanner anpassen: Schließen Sie das Verzeichnis, in dem die VHDX liegt, nach Möglichkeit von „Echtzeit‑Scans“ aus. Das reduziert I/O‑Latenzen und vermeidet Lock‑Konflikte.
• Regelmäßige Backups: Exportieren Sie Ihre Distro regelmäßig:

wsl --export <DistroName> N:\WSL\Backups\<DistroName>_$(Get-Date -Format yyyyMMdd).tar

• Versionsstand aktuell halten: Nutzen Sie die WSL‑Version aus dem Microsoft Store und halten Sie sie up‑to‑date. Neue Funktionen wie –import-in-place und Bugfixes helfen genau bei solchen Szenarien.

Praxisbeispiele: Zwei bewährte Migrationspfade im Detail

Beispiel A: Von C:\ nach N:\ umziehen (ohne Store‑„Move“)

Angenommen, Ihre Distro heißt Ubuntu und liegt auf C:. Ziel ist N:\WSL\Ubuntu.

1) Export:

wsl --shutdown
wsl --export Ubuntu D:\Temp\Ubuntu.tar

2) Import auf N:\:

New-Item -ItemType Directory -Path N:\WSL\Ubuntu | Out-Null
wsl --import Ubuntu N:\WSL\Ubuntu D:\Temp\Ubuntu.tar --version 2

3) Test:

wsl -d Ubuntu

4) D:\Temp\Ubuntu.tar nach erfolgreichem Test archivieren oder löschen.

Beispiel B: Defekte „verschobene“ Distro retten und sauber neu aufsetzen

Die Distro wurde „verschoben“ und ist nun defekt. Vorgehen:

1) ext4.vhdx in N:\WpSystem\…\LocalState finden.
2) wsl –shutdown.
3) VHDX nach N:\WSL_Rescue\ kopieren und dort EFS/Komprimierung entfernen.
4) Neuinstallation via RootFS auf N:\WSL\Ubuntu24\ per –import.
5) Benutzerdaten aus der geretteten VHDX in die neue Distro migrieren.

Tipp für Schritt 5: Mounten Sie beide Instanzen parallel (alte via Swap‑Methode oder import‑in‑place), kopieren Sie Home‑Verzeichnisse und relevante Konfigurationen, und dekontaminieren Sie dabei alte Paketquellen/PPAs für einen „Clean State“.

Fehlersuche: Wenn es trotzdem hakt

• Fehler bleibt „The specified file is encrypted …“ obwohl Sie entschlüsselt haben? Prüfen Sie, ob der neue Ordner selbst verschlüsselt ist (Ordner‑Eigenschaften > Erweitert). Entfernen Sie EFS auf Ordnerebene und wiederholen Sie den Attribut‑Check der VHDX.
• Immer noch 0xffffffff? Prüfen Sie, ob andere Prozesse die VHDX offen halten. Tools wie „Ressourcenmonitor > Datenträger“ helfen beim Aufspüren. Danach erneut wsl –shutdown.
• WSL stürzt sofort ab („Unspecified error“) beim Import? Aktualisieren Sie WSL aus dem Microsoft Store und testen Sie erneut. Nutzen Sie bei VHDX unbedingt –import-in-place (falls vorhanden) oder die Swap‑Methode.
• Distro startet, aber Inhalte fehlen? Stellen Sie sicher, dass Sie die richtige ext4.vhdx (mit aktuellem Zeitstempel und erwarteter Größe) verwendet haben. In WpSystem können mehrere Paketversionen/Ordner liegen.

Extra: RootFS‑basierte Clean‑Installs automatisieren

Wer viele Arbeitsplätze oder Build‑Umgebungen betreibt, profitiert von einem standardisierten Ansatz ohne Store:

1) RootFS‑Tarball der gewünschten Distribution herunterladen (z. B. Ubuntu 22.04/24.04 WSL RootFS von der offiziellen Quelle).
2) Zielverzeichnis je Instanz anlegen, z. B. N:\WSL\Ubuntu24‑Dev, N:\WSL\Ubuntu24‑CI.
3) Import mit definiertem Namen:

wsl --import Ubuntu24-Dev N:\WSL\Ubuntu24-Dev C:\Images\ubuntu-24.04-wsl.rootfs.tar.gz --version 2
wsl --import Ubuntu24-CI  N:\WSL\Ubuntu24-CI  C:\Images\ubuntu-24.04-wsl.rootfs.tar.gz --version 2

4) Post‑Install‑Skripte in /etc/profile.d/ oder per Cloud‑Init‑ähnlichen Skripten (benutzerdefiniert) ausrollen: Paketquellen, Tooling, SSH‑Server, User, Limits, etc.

Sobald Sie diesen Prozess einmal sauber dokumentiert haben, entfällt die fehleranfällige „Move“‑Spielerei vollständig.

Aufräumen nach der Rettung

• Alte Store‑Reste: Wenn Sie die Distro wieder funktionsfähig registriert haben, können Sie die verwaisten Ordner unter WpSystem ignorieren. Löschen Sie dort nichts überhastet – der Ordner ist systemverwaltet.
• Rescue‑Ordner: N:\WSL_Rescue\ können Sie nach erfolgreichem Test entfernen oder als Offline‑Sicherung aufbewahren.
• Default‑Distro setzen:

wsl --set-default <DistroName>

• Alte/defekte Einträge entfernen:

wsl --unregister <AlterName>

Sicherheitshinweis: SSH‑Zugriff in/auf WSL absichern

Betreiben Sie innerhalb der WSL einen SSH‑Server (z. B. für lokale Dev‑Workflows oder Tests), dann verzichten Sie auf Passwort‑Login und nutzen Sie ausschließlich Schlüssel. Die Einrichtung erklären wir Schritt für Schritt in unserem Beitrag „SSH‑Login per Passwort deaktivieren – nur noch mit SSH‑Key erlauben“.

Kompakte Checkliste

• WSL „verschoben“ und Distro startet nicht? Nicht an WindowsApps herumschrauben.
• ext4.vhdx in WpSystem finden.
• wsl –shutdown ausführen.
• VHDX in neutralen Ordner kopieren; EFS/Komprimierung entfernen.
• Distro via –import-in-place registrieren oder Swap‑Methode verwenden.
• Künftig nur via Export/Import auf andere Laufwerke umziehen.
• Regelmäßig Backups via wsl –export anlegen.

Wenn Sie an diesem Punkt Ihre Distro wieder erfolgreich gestartet haben, lohnt sich ein kurzer Blick in Ihre eigene Migrationsstrategie. Eine saubere Export/Import‑Routine spart beim nächsten Mal Zeit und Nerven – und schützt vor genau den Berechtigungsfallen, die die Windows‑„Move“‑Funktion rund um WpSystem erzeugen kann.

Wer noch tiefer in Virtualisierungs‑ und Migrationsfragen einsteigen möchte, findet auf unserem Blog weitere praxisnahe Anleitungen. Für Themen rund um virtuelle Maschinen empfehlen wir unter anderem „Windows 10 PC als virtuelle Maschine auf Proxmox migrieren“ – die Konzepte rund um VMs, Datenträgerformate und saubere Workflows helfen auch bei WSL‑Setups. Und wenn Sie bei der Rettung oder bei einem sauberen Neuaufbau Ihrer WSL‑Umgebung Unterstützung benötigen, melden Sie sich jederzeit – auf dem Blog von ADMIN INTELLIGENCE finden Sie weitere Beiträge unter https://blog.admin-intelligence.de/ oder schreiben Sie uns direkt über https://www.admin-intelligence.de/kontakt/.