There was a problem with WSL: Docker tras mover ChatGPT

Al mover ChatGPT a otra unidad desde Configuración de Windows, Docker se detuvo con un error de WSL. Los registros mostraron el desmontaje de toda la unidad mientras se preparaba la ubicación de almacenamiento de aplicaciones. Bastó reiniciar Docker para recuperar el motor.

El error de WSL mostrado

Después del traslado de ChatGPT, Docker Desktop mostró el siguiente error. Los detalles también indicaban que el proceso de inicio de WSL de Docker había terminado con el código de salida 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 era la versión 4.95.0 y WSL, la 2.7.14.0. El VHDX de datos de Docker ya estaba en D antes de esta migración, con un tamaño lógico de unos 273GB. No trasladamos los datos de Docker junto con la aplicación ChatGPT.

Los detalles extensos del error también incluían registros del inicio de la noche anterior. El aviso inicial sobre la ausencia de componentsVersion.json era anterior a un periodo en el que Docker funcionó unas 11 horas. En lugar de considerar la primera advertencia llamativa como causa directa, examinamos los eventos cercanos al momento en que Docker se detuvo realmente.

Esta distinción cambia la solución que conviene elegir. Aunque el mensaje pedía comprobar WSL, el problema central fue perder el acceso a un disco virtual activo, no una configuración errónea de WSL. Antes de cambiar ajustes o volver a registrar WSL, alineamos las horas y examinamos los eventos de Windows.

Toda la unidad D se desmontó mientras se preparaba el destino

El paso decisivo fue comparar los registros NTFS, AppXDeploymentServer y VHDMP junto con el registro System habitual. La tabla muestra las horas guardadas de los eventos, redondeadas a milisegundos y en hora estándar de Japón.

D se desmontó antes de comenzar el traslado del paquete de ChatGPT. Toda la unidad se vio involucrada mientras Windows la preparaba para almacenar aplicaciones. Aunque la aplicación que se mueve esté cerrada, Docker puede verse afectado si su disco virtual de esa unidad sigue abierto.

El solicitante registrado por NTFS era svchost.exe. Comparamos el identificador del evento con el mismo proceso, que ya funcionaba antes del fallo, y con la información de servicios de Windows; así identificamos StorSvc, el Servicio de almacenamiento. Era distinto del proceso AppX que registraba la ubicación: no los tratamos como un solo proceso.

Desde el inicio del desmontaje hasta completar el nuevo montaje pasaron unos 3.3 segundos. Entre el desmontaje correcto y la finalización del nuevo montaje pasaron unos 0.17 segundos. Por ello no podemos afirmar que D desapareciera por completo durante 3.3 segundos. El problema fue que una operación breve podía romper el acceso a archivos en uso e impedir después que las aplicaciones continuaran.

Qué reveló 0xC000026E

En las definiciones NTSTATUS de Microsoft, 0xC000026E significa STATUS_VOLUME_DISMOUNTED. Indica que se intentó una operación sobre un volumen desmontado. Este valor también apareció en las lecturas fallidas del VHDX de Docker.

Los registros del kernel de WSL también mostraron fallos de READ del almacenamiento virtual, la desconexión del dispositivo y el cierre de containerd con la señal 7. Los registros del disco virtual de Windows y el apagado final de WSL formaban una cronología coherente.

La documentación de Microsoft sobre el desmontaje de volúmenes explica que puede intentarse incluso cuando un volumen está en uso, con efectos imprevisibles sobre sus procesos. Lo observado aquí concuerda con esa propiedad general. Sin embargo, no capturamos una pila que mostrara la llamada a esta API concreta, por lo que no determinamos la ruta interna específica de Windows.

El campo de motivo del evento indicaba User request. No lo interpretamos como prueba de que una persona pulsara «Expulsar USB». El servicio solicitante y la cronología lo relacionaban con el procesamiento de Windows al preparar el almacenamiento de aplicaciones.

Los registros USB, PnP y relacionados que examinamos en ese periodo no contenían pruebas de una desconexión y reconexión físicas. La unidad también notificó Healthy durante la investigación. Esto no garantiza que el SSD no tenga fallos, pero la secuencia directa encontrada fue el desmontaje por el Servicio de almacenamiento seguido del acceso fallido al VHDX.

El mecanismo PackageVolume que documenta Microsoft es una forma admitida de almacenar aplicaciones. Aun así, usar una función integrada de traslado no garantizaba que otras aplicaciones de la unidad pudieran seguir funcionando sin interrupción.

Unity también sufrió un fallo de E/S al mismo tiempo

Había un proyecto de Unity en la misma unidad y apareció Unity Bug Reporter. Los eventos Application Error mostraron el cierre de Unity Data Store entre las 13:20:47 y las 13:20:49, antes de reiniciar Docker. La excepción era 0xC0000006 y el estado de E/S subyacente, 0xC000026E.

Microsoft define 0xC0000006 como STATUS_IN_PAGE_ERROR: no pudieron cargarse en memoria los datos necesarios debido a un error de E/S. El estado subyacente tenía el mismo valor de desmontaje que el fallo de Docker. Esto respalda que Unity se vio afectado por la misma indisponibilidad de la unidad.

Sin embargo, el campo de nombre de archivo estaba vacío, así que no identificamos el archivo concreto al que Unity no pudo acceder. Que Unity.dll apareciera en un registro posterior no demostraba por sí solo una DLL dañada ni la necesidad de reinstalar.

No reiniciamos Unity inmediatamente. Conservamos por separado 5 archivos, unos 8MB en total, incluidos una copia de escena ya existente, registros y volcados. La escena tenía la hora 08:31 de ese día: no demuestra que se guardara el trabajo sin guardar inmediatamente anterior al fallo. Durante la investigación no sobrescribimos el proyecto original con esos archivos.

La secuencia también descarta que reiniciar primero Docker provocara el fallo de Unity. El primer cierre de Unity Data Store fue anterior al reinicio de Docker. Fue necesario comprobar las horas de los eventos, no basarse solo en el orden en que aparecieron las pantallas.

Reiniciar solo Docker recuperó el motor

Tras conservar localmente suficientes registros para rastrear la causa y confirmar que D volvía a ser accesible, reiniciamos solo Docker Desktop una vez. Utilizamos su CLI oficial. El comando siguiente afecta al trabajo activo en Docker: comprueba qué procesos hay que guardar o detener antes de ejecutarlo.

docker desktop restart --timeout 45

La documentación oficial de reinicio de Docker describe --timeout como una opción que limita la espera del comando. No garantiza una recuperación en 45 segundos. Esta ejecución terminó con el código 0.

Después utilizamos docker version para comprobar la respuesta Server y obtuvimos Engine 29.8.2. El inventario de WSL también volvió a mostrar docker-desktop como Running. El backend nuevo arrancó en el minuto de las 13:27.

El inventario obtenido contenía 108 contenedores: 1 en ejecución, 106 detenidos y 1 creado. No iniciamos en bloque los detenidos. Que el motor responda no equivale a que las bases de datos y servicios de cada proyecto funcionen como antes; sus responsables debían comprobar las funciones necesarias.

La recuperación no requirió restablecer a fábrica, borrar datos, anular el registro de WSL ni reinstalar. Tampoco apagamos todo WSL, lo que afectaría a más que Docker, ni subimos un diagnóstico completo a servicios externos. Lo importante era no pasar directamente de la pantalla de error a una acción capaz de perder datos guardados.

Registros que ayudaron a identificar la causa

Examinar solo System no reveló inicialmente los registros decisivos del desmontaje. Que no estuvieran en System no significaba que Windows no los hubiera registrado. Ordenar los registros siguientes por hora conectó la preparación del traslado con los fallos de E/S de otras aplicaciones.

Para investigar un síntoma similar, anotar primero la hora de la operación, la unidad de destino, la ubicación del disco virtual de Docker y el texto del error ayuda a delimitar la búsqueda. Comprueba qué canales existen en el equipo y comienza leyendo los registros disponibles. En esta investigación posterior no habilitamos ajustes de diagnóstico ni repetimos la operación que provocó el fallo.

El artículo no publica el nombre de usuario, SID, números de serie, credenciales ni variables de entorno de contenedores. Al compartir registros, extraer solo horas, códigos de error y nombres de operaciones necesarios también facilita entender la causa.

Qué decidir antes de mover a otra unidad

Nuestro error fue centrarnos en detener y respaldar ChatGPT sin abordar suficientemente, en las instrucciones previas, el efecto sobre Docker y Unity que ya utilizaban D. Para un trabajo similar identificaríamos qué detener en toda la unidad.

1. Identificar todo lo que usa el destino. Comprueba discos virtuales de Docker y máquinas virtuales, bases de datos, proyectos de editores y procesos que mantengan abiertos archivos de D.
2. Preservar el trabajo sin guardar y los datos de recuperación. Haz recuperable el trabajo activo, en lugar de limitarte a copiar la aplicación.
3. Elegir un momento en que se puedan detener los procesos de la unidad. Incluye los otros chats y responsables e impide que arranquen procesos nuevos durante el traslado.
4. Utilizar la función de traslado admitida por Windows. No cambies la propiedad ni los permisos de WindowsApps o WpSystem para mover manualmente solo sus carpetas.
5. Comprobar el traslado y las demás aplicaciones por separado. Verifica las funciones necesarias, en este orden: inicio de la aplicación, elementos guardados, navegador, motor de Docker y servicios requeridos.

Los registros confirmaron que era el primer registro de D como almacenamiento de aplicaciones. Eso no demuestra que el fallo ya nunca pueda repetirse una vez registrado. No registramos ni desmontamos repetidamente la unidad de trabajo para probarlo; mantuvimos la configuración que funcionaba.

Mover una aplicación a D tampoco concentra allí todos sus archivos relacionados. En este caso, la aplicación y sus datos principales fueron a D, mientras que la CLI y otros componentes activos quedaron en C. La distribución y los tamaños se explican en nuestro registro de migración de ChatGPT y Codex.

Un traslado correcto no implica que otras aplicaciones no sufrieran efectos

La aplicación ChatGPT se trasladó correctamente a D y después comprobamos el navegador y los elementos guardados. Al mismo tiempo, toda D se desmontó mientras se preparaba el destino y provocó fallos en Docker y otras aplicaciones que utilizaban discos virtuales de esa unidad. El evento de traslado correcto no bastaba para demostrar que las aplicaciones cercanas no habían sufrido efectos.

Los registros explican la secuencia directa del fallo de este caso. No determinamos qué rama interna de Windows pidió el desmontaje ni si ocurre lo mismo en otros equipos o versiones. La precaución concreta respaldada por esta experiencia es detener los procesos activos que usan D, además de la aplicación que se va a mover, antes de empezar.

Preguntas frecuentes

¿Reinstalar WSL soluciona «There was a problem with WSL»?

Aquí el fallo fue la pérdida de acceso a un disco virtual. Reiniciar solo Docker recuperó el motor; no reinstalamos ni anulamos el registro de WSL. Examinar primero los registros del momento del fallo protege mejor los datos guardados.

¿Significa que falló el SSD de D?

Encontramos un registro directo del desmontaje de D por el Servicio de almacenamiento. No aparecieron registros de desconexión física simultánea. Este caso no permite concluir que el SSD fallara.

¿Debo evitar la función de Windows para mover aplicaciones?

Mover un paquete a otro volumen es una función admitida de Windows. Según esta experiencia, reservaríamos tiempo para detener las demás aplicaciones del destino, hacer copias y comprobar su funcionamiento, en lugar de mantenerlas abiertas durante el traslado.

Si Docker arranca, ¿puedo dar todo por recuperado?

La respuesta del motor es independiente de los servicios y datos de cada contenedor. Verificamos la recuperación del motor y obtuvimos el inventario; las comprobaciones funcionales de cada proyecto siguen siendo independientes.