There was a problem with WSL: Docker ao mover o ChatGPT

Ao mover o ChatGPT para outra unidade pelas Configurações do Windows, o Docker parou com um erro do WSL. Os logs registraram a desmontagem de toda a unidade durante a preparação do armazenamento de aplicativos. Reiniciar apenas o Docker recuperou o mecanismo.

O erro do WSL exibido

Após a transferência do ChatGPT, o Docker Desktop exibiu o erro abaixo. Os detalhes também indicavam que o processo de inicialização do WSL do Docker havia terminado com o código de saída 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

O Docker Desktop era a versão 4.95.0 e o WSL, a 2.7.14.0. O VHDX de dados do Docker já estava em D antes da migração, com tamanho lógico de cerca de 273GB. Não movemos os dados do Docker junto com o aplicativo ChatGPT.

Os detalhes extensos também incluíam logs da inicialização da noite anterior. O aviso inicial sobre a ausência de componentsVersion.json era anterior a um período em que o Docker funcionou por cerca de 11 horas. Em vez de tratar o primeiro aviso chamativo como causa direta, examinamos os eventos próximos do momento em que o Docker realmente parou.

Essa distinção muda a escolha da solução. Embora a mensagem pedisse verificar o WSL, o problema central era a perda de acesso a um disco virtual ativo, não uma configuração incorreta do WSL. Antes de mudar ajustes ou registrar o WSL novamente, alinhamos os horários e examinamos os eventos do Windows.

Toda a unidade D foi desmontada na preparação do destino

O passo decisivo foi comparar os logs NTFS, AppXDeploymentServer e VHDMP com o System habitual. A tabela mostra os horários salvos dos eventos, arredondados a milissegundos e no horário padrão do Japão.

D foi desmontada antes de começar a transferência do pacote do ChatGPT. Toda a unidade foi envolvida enquanto o Windows a preparava para armazenar aplicativos. Mesmo com o aplicativo transferido fechado, o Docker poderia ser afetado se seu disco virtual na mesma unidade continuasse aberto.

O solicitante registrado pelo NTFS era svchost.exe. Comparamos o identificador do evento com o mesmo processo, que já estava em execução antes da falha, e com as informações dos serviços do Windows; assim identificamos StorSvc, o Serviço de Armazenamento. Ele era diferente do processo AppX que registrava o local; não os tratamos como um só processo.

Passaram cerca de 3.3 segundos entre o início da desmontagem e a conclusão da remontagem. Da desmontagem bem-sucedida até o fim da remontagem foram cerca de 0.17 segundos. Portanto, não podemos afirmar que D desapareceu completamente por 3.3 segundos. O problema é que mesmo uma operação breve pode interromper o acesso a arquivos em uso e impedir a continuidade dos aplicativos.

O que 0xC000026E revelou

Nas definições NTSTATUS da Microsoft, 0xC000026E significa STATUS_VOLUME_DISMOUNTED. Indica uma tentativa de operação em um volume desmontado. Esse valor também apareceu nas leituras malsucedidas do VHDX do Docker.

Os logs do kernel do WSL também mostraram falhas READ no armazenamento virtual, o dispositivo ficando offline e o containerd falhando com o sinal 7. Os registros do disco virtual do Windows e o desligamento final do WSL formaram uma cronologia coerente.

A documentação da Microsoft sobre desmontagem de volumes explica que uma desmontagem pode ser tentada mesmo com o volume em uso, com efeitos imprevisíveis sobre os processos que o utilizam. Este caso é compatível com essa propriedade geral. Porém, não capturamos uma pilha que mostrasse a chamada dessa API específica; portanto, não determinamos o caminho interno exato do Windows.

O campo de motivo do evento indicava User request. Não interpretamos isso como prova de que alguém clicou em “Ejetar USB”. O serviço solicitante e a cronologia o relacionavam ao processamento do Windows durante a preparação do armazenamento de aplicativos.

Os logs USB, PnP e relacionados que examinamos nesse período não continham evidências de desconexão e reconexão físicas. A unidade também informou Healthy durante a investigação. Isso não garante que o SSD esteja livre de defeitos, mas a sequência direta encontrada foi a desmontagem pelo Serviço de Armazenamento seguida da falha de acesso ao VHDX.

O mecanismo PackageVolume documentado pela Microsoft é uma forma compatível de armazenar aplicativos. Mesmo assim, usar uma função nativa de transferência não garantia que os outros aplicativos da unidade pudessem continuar sem interrupções.

O Unity também apresentou falha de E/S ao mesmo tempo

Havia um projeto do Unity na mesma unidade e o Unity Bug Reporter apareceu. Os eventos Application Error mostraram o Unity Data Store falhando entre 13:20:47 e 13:20:49, antes de reiniciar o Docker. A exceção era 0xC0000006 e o status de E/S subjacente, 0xC000026E.

A Microsoft define 0xC0000006 como STATUS_IN_PAGE_ERROR: os dados necessários não puderam ser carregados na memória devido a um erro de E/S. O status subjacente tinha o mesmo valor de desmontagem que a falha do Docker. Isso sustenta a conclusão de que o Unity foi afetado pela mesma indisponibilidade da unidade.

Porém, o campo de nome do arquivo estava vazio, então não identificamos o arquivo específico que o Unity não conseguiu acessar. Unity.dll aparecer em um registro posterior, por si só, não comprovava uma DLL corrompida nem necessidade de reinstalação.

Não reiniciamos o Unity imediatamente. Preservamos separadamente 5 arquivos, cerca de 8MB no total, incluindo um backup de cena existente, logs e dumps. A cena tinha o horário 08:31 daquele dia; isso não comprova a preservação do trabalho não salvo imediatamente anterior à falha. Não sobrescrevemos o projeto original com esses arquivos durante a investigação.

Essa sequência também descarta que reiniciar primeiro o Docker tenha causado a falha do Unity. O primeiro encerramento do Unity Data Store ocorreu antes do reinício do Docker. A investigação exigiu conferir os horários dos eventos, em vez de confiar apenas na ordem em que as telas apareceram.

Reiniciar apenas o Docker recuperou o mecanismo

Após guardar logs suficientes localmente para rastrear a causa e confirmar que D estava acessível novamente, reiniciamos apenas o Docker Desktop, uma única vez. Usamos sua CLI oficial. O comando abaixo afeta o trabalho ativo no Docker: antes de executá-lo, verifique o que precisa ser salvo ou parado.

docker desktop restart --timeout 45

A documentação oficial de reinicialização do Docker descreve --timeout como uma opção que limita quanto tempo o comando espera. Não garante a recuperação em 45 segundos. Essa execução terminou com o código de saída 0.

Depois usamos docker version para conferir a resposta Server e obtivemos Engine 29.8.2. O inventário do WSL também voltou a mostrar docker-desktop como Running. O novo backend iniciou no minuto das 13:27.

O inventário obtido continha 108 contêineres: 1 em execução, 106 parados e 1 criado. Não iniciamos em lote os contêineres parados. O mecanismo responder é diferente de os bancos e serviços de cada projeto funcionarem como antes; as verificações funcionais necessárias ficaram com os respectivos responsáveis.

A recuperação não envolveu restauração de fábrica, exclusão de dados, cancelamento do registro do WSL ou reinstalação. Também não desligamos todo o WSL, o que afetaria mais do que o Docker, nem enviamos todos os diagnósticos para serviços externos. O importante era não saltar da tela de erro para uma ação capaz de perder dados armazenados.

Logs que ajudaram a identificar a causa

Consultar apenas System inicialmente não revelou os registros decisivos da desmontagem. A ausência em System não significava falta de registro no Windows. Ordenar os logs abaixo por horário relacionou a preparação da transferência com as falhas de E/S dos outros aplicativos.

Para investigar o mesmo sintoma, anotar primeiro o horário, a unidade de destino, o local do disco virtual do Docker e o texto do erro ajuda a limitar a busca. Confira os canais disponíveis no computador e comece lendo os registros existentes. Nesta investigação posterior, não ativamos configurações de diagnóstico nem repetimos a operação que causou a falha.

O artigo não publica nome de usuário, SID, números de série, credenciais nem variáveis de ambiente dos contêineres. Ao compartilhar logs, extrair apenas horários, códigos de erro e nomes de operações necessários também facilita entender a causa.

O que decidir antes de mover para outra unidade

Nossa falha foi concentrar as instruções prévias em parar e fazer backup do ChatGPT sem abordar adequadamente o efeito sobre o Docker e o Unity já em execução em D. Em uma tarefa semelhante, identificaríamos o que parar em toda a unidade.

1. Identifique tudo o que usa o destino. Verifique discos virtuais do Docker e de VMs, bancos de dados, projetos de editores e outros processos que mantêm arquivos de D abertos.
2. Preserve trabalho não salvo e dados para recuperação. Garanta que o trabalho ativo possa ser recuperado, em vez de apenas copiar o aplicativo.
3. Escolha um momento para parar os processos da unidade. Inclua o trabalho de outros chats e responsáveis e impeça o início de novos processos durante a transferência.
4. Use o recurso de transferência compatível do Windows. Não altere propriedade ou permissões de WindowsApps ou WpSystem para mover manualmente apenas as pastas.
5. Verifique a transferência e os outros aplicativos separadamente. Verifique as funções necessárias nesta ordem: inicialização, itens salvos, navegador, mecanismo do Docker e serviços exigidos.

Os logs confirmaram que esse foi o primeiro registro de D como armazenamento de aplicativos. Isso não demonstra que a mesma falha nunca mais possa ocorrer após o registro. Não registramos nem desmontamos repetidamente a unidade de trabalho para testar; mantivemos a configuração que funcionava.

Mover um aplicativo para D também não reúne ali todos os arquivos relacionados. Neste caso, o aplicativo e seus dados principais foram para D, enquanto a CLI e outros componentes ativos ficaram em C. A organização e os tamanhos estão em nosso registro de migração do ChatGPT e do Codex.

Uma transferência bem-sucedida não significa que outros aplicativos não foram afetados

O ChatGPT foi movido para D com sucesso e depois verificamos o navegador e os itens salvos. Ao mesmo tempo, toda a unidade D foi desmontada na preparação do destino, causando falhas no Docker e em outros aplicativos que usavam discos virtuais nessa unidade. O evento de transferência bem-sucedida, sozinho, não comprovava que os demais aplicativos estavam intactos.

Os logs explicam a sequência direta da falha neste caso. Não determinamos qual ramificação interna do Windows solicitou a desmontagem nem se o mesmo ocorre em outros computadores ou versões. A precaução concreta sustentada por esta experiência é parar os processos ativos que usam D, além do aplicativo transferido, antes de começar.

Perguntas frequentes

Reinstalar o WSL resolve “There was a problem with WSL”?

Aqui a falha foi a perda de acesso a um disco virtual. Reiniciar apenas o Docker recuperou o mecanismo; não reinstalamos nem cancelamos o registro do WSL. Verificar primeiro os logs do momento da falha protege melhor os dados armazenados.

Isso significa que o SSD de D falhou?

Encontramos um registro direto da desmontagem de D pelo Serviço de Armazenamento. Não encontramos registros de desconexão física simultânea. Este caso não permite concluir que o SSD falhou.

Devo evitar o recurso do Windows para mover aplicativos?

Mover um pacote para outro volume é um recurso compatível do Windows. Com base nesta experiência, reservaríamos tempo para parar outros aplicativos do destino, fazer backup e verificar operações, em vez de deixá-los em execução durante a transferência.

Se o Docker inicia, posso considerar tudo recuperado?

A resposta do mecanismo é diferente dos serviços e conteúdos dos bancos em cada contêiner. Verificamos a recuperação do mecanismo e obtivemos o inventário; as verificações funcionais dos projetos necessários são separadas.