There was a problem with WSL : Docker après un déplacement

Pendant le déplacement de ChatGPT vers un autre lecteur depuis les Paramètres Windows, Docker s’est arrêté avec une erreur WSL. Les journaux ont enregistré le démontage de tout le lecteur lors de la préparation du stockage d’applications. Redémarrer uniquement Docker a rétabli le moteur.

L’erreur WSL affichée

Après le déplacement de ChatGPT, Docker Desktop a affiché l’erreur suivante. Les détails indiquaient aussi que son processus de démarrage WSL s’était terminé avec le code de sortie 135.

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 était en version 4.95.0 et WSL en version 2.7.14.0. Le VHDX de données Docker était déjà sur D avant cette migration, avec une taille logique d’environ 273Go. Nous n’avons pas déplacé les données Docker avec l’application ChatGPT.

Les détails de l’erreur incluaient aussi des journaux du démarrage de la veille au soir. Le premier avertissement concernant l’absence de componentsVersion.json précédait une période où Docker avait fonctionné environ 11 heures. Au lieu de traiter le premier avertissement visible comme la cause directe, nous avons examiné les événements proches de l’arrêt réel de Docker.

Cette distinction change le choix du remède. Le message demandait de vérifier WSL, mais le problème central était la perte d’accès à un disque virtuel actif, pas un mauvais réglage de WSL. Avant de modifier les réglages ou de réenregistrer WSL, nous avons aligné les horaires et examiné les événements Windows.

Tout le lecteur D a été démonté pendant la préparation du stockage

L’étape décisive a consisté à comparer NTFS, AppXDeploymentServer et VHDMP avec le journal System habituel. Le tableau présente les horodatages enregistrés, arrondis à la milliseconde et exprimés en heure standard du Japon.

D a été démonté avant le début du déplacement du paquet ChatGPT. Tout le lecteur était concerné pendant que Windows le préparait pour le stockage d’applications. Même si l’application déplacée était fermée, Docker pouvait être affecté si son disque virtuel sur ce lecteur restait ouvert.

Le demandeur enregistré par NTFS était svchost.exe. Nous avons comparé son identifiant avec le même processus, déjà actif avant la panne, et les informations des services Windows ; cela a identifié StorSvc, le service de stockage. Il était distinct du processus AppX chargé d’enregistrer l’emplacement : nous ne les avons pas confondus.

Environ 3.3 secondes séparent le début du démontage de la fin du remontage. Entre le démontage réussi et la fin du remontage, l’intervalle était d’environ 0.17 seconde. On ne peut donc pas dire que D a entièrement disparu pendant 3.3 secondes. Le problème est qu’une opération même brève peut rompre l’accès aux fichiers en cours d’utilisation et empêcher ensuite les applications de continuer.

Ce qu’a révélé 0xC000026E

Dans les définitions NTSTATUS de Microsoft, 0xC000026E signifie STATUS_VOLUME_DISMOUNTED. Une opération a été tentée sur un volume démonté. Cette valeur figurait aussi dans les lectures échouées du VHDX Docker.

Les journaux du noyau WSL montraient également des échecs READ du stockage virtuel, le passage hors ligne du périphérique et un plantage de containerd avec le signal 7. Les événements du disque virtuel Windows et l’arrêt final de WSL formaient une chronologie cohérente.

La documentation Microsoft sur le démontage des volumes explique qu’un démontage peut être tenté même sur un volume utilisé, avec des effets imprévisibles sur les processus concernés. Ce cas est compatible avec cette propriété générale. Nous n’avons toutefois pas capturé de pile montrant l’appel à cette API précise ; le chemin interne exact de Windows n’a donc pas été établi.

Le champ indiquant la raison de l’événement contenait User request. Nous n’y avons pas vu la preuve qu’une personne avait cliqué sur « Éjecter l’USB ». Le service demandeur et la chronologie reliaient cet événement au traitement de préparation du stockage d’applications par Windows.

Les journaux USB, PnP et associés examinés sur cette période ne contenaient pas de preuve de déconnexion puis reconnexion physique. Le lecteur indiquait aussi Healthy pendant l’enquête. Cela ne garantit pas l’absence de défaut du SSD, mais la séquence directe établie ici était le démontage par le service de stockage suivi de l’échec d’accès au VHDX.

Le mécanisme PackageVolume documenté par Microsoft est une méthode prise en charge pour stocker les applications. Cela ne garantissait pourtant pas que les autres applications du lecteur puissent continuer sans interruption pendant le déplacement.

Unity a aussi subi une panne d’E/S au même moment

Un projet Unity se trouvait sur le même lecteur et Unity Bug Reporter est apparu. Les événements Application Error montraient le plantage d’Unity Data Store entre 13:20:47 et 13:20:49, avant le redémarrage de Docker. L’exception était 0xC0000006 et le statut d’E/S sous-jacent, 0xC000026E.

Microsoft définit 0xC0000006 comme STATUS_IN_PAGE_ERROR: les données requises n’ont pas pu être chargées en mémoire à cause d’une erreur d’E/S. Le statut sous-jacent contenait la même valeur de démontage que la panne Docker. Cela soutient la conclusion qu’Unity a été touché par la même indisponibilité du lecteur.

Le champ du nom de fichier était toutefois vide : nous n’avons pas identifié le fichier précis inaccessible à Unity. La présence de Unity.dll dans un journal de plantage ultérieur ne suffisait pas à prouver une DLL endommagée ou un besoin de réinstallation.

Nous n’avons pas redémarré Unity immédiatement. Nous avons préservé séparément 5 fichiers, environ 8Mo au total, dont une sauvegarde de scène existante, des journaux et des dumps. La scène était horodatée à 08:31 ce jour-là : cela ne prouve pas la sauvegarde du travail non enregistré juste avant le plantage. Nous n’avons pas écrasé le projet original avec ces fichiers pendant l’enquête.

Cette séquence exclut aussi que le redémarrage de Docker ait d’abord cassé Unity. Le premier plantage d’Unity Data Store précédait ce redémarrage. L’enquête exigeait de vérifier les heures des événements, pas seulement l’ordre d’apparition des écrans.

Un redémarrage de Docker seul a rétabli le moteur

Après avoir conservé localement assez de journaux pour suivre la cause et confirmé que D était de nouveau accessible, nous avons redémarré uniquement Docker Desktop, une seule fois. Nous avons utilisé sa CLI officielle. La commande ci-dessous affecte le travail actif dans Docker : vérifiez ce qui doit être enregistré ou arrêté avant de l’exécuter.

docker desktop restart --timeout 45

La documentation officielle du redémarrage de Docker présente --timeout comme une option limitant l’attente de la commande. Elle ne garantit pas la récupération en 45 secondes. Cette exécution s’est terminée avec le code de sortie 0.

Nous avons ensuite utilisé docker version pour vérifier la réponse Server et obtenu Engine 29.8.2. L’inventaire WSL affichait de nouveau docker-desktop comme Running. Le nouveau backend a démarré dans la minute de 13:27.

L’inventaire obtenu contenait 108 conteneurs : 1 actif, 106 arrêtés et 1 créé. Nous n’avons pas démarré en masse les conteneurs arrêtés. Un moteur qui répond ne signifie pas que les bases et services de chaque projet fonctionnent comme avant ; les vérifications fonctionnelles nécessaires ont été laissées à leurs responsables.

La récupération n’a impliqué ni réinitialisation d’usine, ni suppression de données, ni désenregistrement de WSL, ni réinstallation. Nous n’avons pas non plus arrêté tout WSL, ce qui aurait affecté plus que Docker, ni envoyé l’ensemble des diagnostics à l’extérieur. L’essentiel était de ne pas passer directement de l’écran d’erreur à une action susceptible de perdre des données.

Les journaux utiles pour identifier la cause

Le seul journal System ne montrait pas initialement les événements décisifs de démontage. Leur absence de System ne signifiait pas l’absence de traces dans Windows. Classer les journaux suivants par heure a relié la préparation du déplacement aux erreurs d’E/S des autres applications.

Pour enquêter sur le même symptôme, noter d’abord l’heure de l’opération, le lecteur de destination, l’emplacement du disque virtuel Docker et le message aide à cibler les recherches. Vérifiez les canaux disponibles et commencez par les traces existantes. Cette enquête complémentaire n’a ni activé des diagnostics ni reproduit l’opération à l’origine de la panne.

L’article ne publie ni nom d’utilisateur, SID, numéros de série, identifiants secrets ni variables d’environnement des conteneurs. Lors du partage, extraire seulement les heures, codes d’erreur et noms d’opérations nécessaires rend aussi la cause plus lisible.

Décisions à prendre avant le déplacement

Notre insuffisance était d’avoir axé les consignes sur l’arrêt et la sauvegarde de ChatGPT sans assez traiter les effets sur Docker et Unity déjà actifs sur D. Pour une opération similaire, nous recenserions ce qu’il faut arrêter à l’échelle du lecteur.

1. Identifier tout ce qui utilise la destination. Vérifiez les disques virtuels Docker et des VM, les bases, projets d’éditeurs et autres processus gardant des fichiers de D ouverts.
2. Préserver le travail non enregistré et les données de récupération. Rendez le travail actif récupérable, plutôt que de copier seulement l’application.
3. Choisir un moment où les processus du lecteur peuvent être arrêtés. Incluez les autres chats et responsables, et empêchez de nouveaux processus de démarrer pendant le déplacement.
4. Utiliser la fonction de déplacement prise en charge par Windows. Ne changez pas le propriétaire ni les autorisations de WindowsApps ou WpSystem pour déplacer manuellement les seuls dossiers.
5. Vérifier séparément le déplacement et les autres applications. Contrôlez les fonctions nécessaires dans cet ordre : démarrage, éléments enregistrés, navigateur, moteur Docker, puis services requis.

Les journaux ont confirmé qu’il s’agissait du premier enregistrement de D comme stockage d’applications. Cela ne prouve pas que la même panne ne pourra jamais se reproduire ensuite. Nous n’avons pas enregistré ou démonté à répétition le lecteur de travail pour le tester ; nous avons conservé la configuration fonctionnelle.

Déplacer une application sur D n’y rassemble pas non plus tous les fichiers associés. Ici, l’application et ses principales données sont allées sur D, mais la CLI active et d’autres composants sont restés sur C. L’organisation et les tailles sont présentées dans notre récit de migration de ChatGPT et Codex.

Un déplacement réussi ne garantit pas l’absence d’effet ailleurs

ChatGPT a bien été déplacé sur D et nous avons ensuite vérifié le navigateur et les éléments enregistrés. Parallèlement, tout D a été démonté pendant la préparation, provoquant des pannes dans Docker et d’autres applications utilisant des disques virtuels du lecteur. L’événement de déplacement réussi ne suffisait pas à établir que les applications voisines n’avaient pas été affectées.

Les journaux expliquent la séquence directe de cette panne. Nous n’avons pas établi quelle branche interne de Windows a demandé le démontage ni si cela se produit sur d’autres ordinateurs ou versions. La précaution concrète soutenue par ce cas est d’arrêter les processus actifs utilisant D, en plus de l’application déplacée, avant de commencer.

Questions fréquentes

Réinstaller WSL corrige-t-il « There was a problem with WSL » ?

Ici, la panne était une perte d’accès à un disque virtuel. Un redémarrage de Docker seul a rétabli le moteur ; nous n’avons ni réinstallé ni désenregistré WSL. Examiner d’abord les journaux de l’heure de la panne protège mieux les données.

Cela signifie-t-il que le SSD de D est en panne ?

Nous avons trouvé une trace directe du démontage de D par le service de stockage. Aucun journal ne montrait de déconnexion physique au même moment. Ce cas ne permet pas de conclure à une panne du SSD.

Faut-il éviter la fonction de déplacement de Windows ?

Déplacer un paquet sur un autre volume est une fonction prise en charge. D’après cette expérience, nous prévoirions du temps pour arrêter les autres applications de la destination, sauvegarder les données et vérifier le fonctionnement, plutôt que de les laisser actives pendant le déplacement.

Si Docker démarre, peut-on considérer que tout est rétabli ?

La réponse du moteur est distincte des services et des données de chaque conteneur. Nous avons vérifié le moteur et obtenu l’inventaire ; les contrôles fonctionnels des projets nécessaires restent séparés.