WSL2 – Corruption totale du VHDX suite à un verrou P9NP empêchant le démontage (analyse complète)

### Windows Version

Windows 10/11

### WSL Version

In-box WSL2 (pré‑Store, version exacte inconnue)

### Are you using WSL 1 or WSL 2?

- [x] WSL 2
- [ ] WSL 1

### Kernel Version

_No response_

### Distro Version

_No response_

### Other Software

_No response_

### Repro Steps

Bonjour,
Je soumets un rapport complet concernant une corruption totale d’un conteneur VHDX utilisé par WSL2.
Après analyse approfondie (qemu‑nbd, fdisk, mount, VirtualBox, R‑Studio), il apparaît que la corruption est structurelle et irréversible, et qu’elle est survenue après un verrou P9NP empêchant WSL de démonter proprement le conteneur.

Je joins ci‑dessous le rapport final détaillé.

### Expected Behavior

Je m’attendais à ce que WSL démonte proprement le conteneur VHDX, libère les handles UNC, et permette un accès normal au système de fichiers ext4 via \\wsl$ ou via le montage interne.
Le VHDX aurait dû rester cohérent, avec un journal ext4 rejouable et une structure GPT intacte.
📄 Rapport final – Corruption totale du VHDX WSL suite à un verrou P9NP et démontage impossible
1. Contexte
Windows 10/11

WSL2 (Ubuntu)

Système de fichiers ext4 stocké dans un conteneur VHDX

Dossier utilisateur contenant des fichiers critiques (ex : zest)

Le VHDX était fonctionnel avant l’apparition du bug

2. Symptômes initiaux
Accès impossible à \\wsl$ (Access Denied)

Présence du provider P9NP dans les logs Windows

WSL incapable de démonter proprement le VHDX

Instances WSL fantômes impossibles à fermer

wsl --shutdown inefficace

Verrous persistants sur le conteneur

Messages d’erreur indiquant des handles UNC non libérés

À ce stade, le VHDX était encore intact et les données récupérables.

3. Hypothèse initiale (confirmée)
Le provider Windows P9NP a pris la main sur \\wsl$, empêchant WSL de :

flusher le journal ext4

démonter proprement le VHDX

fermer les handles

synchroniser les métadonnées

4. Symptômes après crash
VHDX impossible à monter

VirtualBox → échec d’ouverture

qemu‑nbd → disque brut de 1 To

fdisk → aucune partition

mount → impossible

R‑Studio → ext4 = 0 bytes

5. Analyse technique
Header VHDX corrompu

GPT effacée

Superblock ext4 absent

Journal irrécupérable

Structure interne détruite

Le disque est interprété comme un blob brut de 1 To

6. Conclusion
Le conteneur VHDX a subi une corruption structurelle totale, causée par :

Un verrou P9NP empêchant WSL de démonter proprement

Une fermeture forcée du service WSL

Une réécriture partielle du header VHDX

La perte de la table GPT

La destruction du superblock ext4

Aucune récupération filesystem n’est possible.

7. Impact
Perte totale du système de fichiers ext4

Perte du dossier utilisateur (zest)

Perte de l’arborescence, des permissions, des métadonnées

Perte de données irréversible

8. Recommandations pour Microsoft
Corriger l’ordre des providers UNC (P9NP vs WSL)

Empêcher P9NP de verrouiller \\wsl$

Ajouter une protection du VHDX en cas de crash

Ajouter un outil de réparation VHDX pour WSL

Améliorer la gestion des handles UNC

### Actual Behavior

Au lieu de cela, WSL a refusé de démonter le VHDX à cause d’un verrou P9NP.
Le conteneur est resté dans un état “dirty”, puis a été corrompu après un redémarrage forcé.
Résultats observés :

\\wsl$ → Access Denied

P9NP présent dans les logs

wsl --shutdown inefficace

VirtualBox → impossible d’ouvrir le VHDX

qemu‑nbd → disque brut de 1 To, aucune partition

fdisk → aucune table GPT

mount → impossible

R‑Studio → ext4 = 0 bytes, aucune structure valide

Le VHDX est devenu irrécupérable.

### Diagnostic Logs

_No response_

No source files, tests, exact WSL version, kernel version, or diagnostic logs are provided. Start by collecting those details and reproducing the P9NP lock, UNC access failure, and VHDX state before and after shutdown; done requires a confirmed failure path and a scoped fix or documented limitation.

Written by the indexing model from the issue text.