There was a problem with WSL: Docker остановился при переносе приложения

При переносе ChatGPT на другой диск через настройки Windows Docker остановился с ошибкой WSL. Журналы зафиксировали отключение всего диска при подготовке места хранения приложения. Перезапуска одного Docker хватило для восстановления движка.

Показанная ошибка WSL

После переноса ChatGPT Docker Desktop показал следующую ошибку. В подробностях также было указано, что процесс запуска Docker в WSL завершился с кодом 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 — 4.95.0, WSL — 2.7.14.0. Файл данных Docker VHDX уже до этой миграции находился на диске D и имел логический размер около 273GB. Вместе с приложением ChatGPT данные Docker не переносились.

В длинных подробностях ошибки присутствовали и журналы запуска прошлой ночью. Начальное предупреждение об отсутствующем componentsVersion.json предшествовало последующей работе Docker в течение около 11 часов. Вместо того чтобы считать первое заметное предупреждение непосредственной причиной, мы изучили события около фактической остановки Docker.

Это различие влияет на выбор исправления. Хотя сообщение предлагало проверить конфигурацию WSL, основной проблемой здесь была потеря доступа к активному виртуальному диску, а не неверная настройка WSL. До изменения настроек или повторной регистрации WSL мы сопоставили время и изучили события Windows.

Весь диск D был отключён при подготовке места назначения

Решающим стало сопоставление журналов NTFS, AppXDeploymentServer и VHDMP с обычным журналом System. Таблица показывает сохранённые метки времени событий, округлённые до миллисекунд, по японскому стандартному времени.

Диск D отключился до начала перемещения самого пакета ChatGPT. Подготовка Windows места хранения приложений затронула весь диск. Даже при закрытом переносимом приложении Docker мог пострадать, если его виртуальный диск на том же накопителе оставался открытым.

В NTFS инициатором запроса значился svchost.exe. Сопоставление ID процесса из события с тем же процессом, работавшим ещё до сбоя, и сведениями о службах Windows позволило определить StorSvc — службу хранилища Storage Service. Она отличалась от процесса AppX, регистрировавшего место хранения; эти два процесса мы не считали одним.

От начала отключения до окончания повторного подключения прошло около 3.3 секунды. Между успешным отключением и окончанием подключения — около 0.17 секунды. Поэтому нельзя утверждать, что диск D полностью отсутствовал 3.3 секунды. Проблема в том, что даже короткая операция могла нарушить доступ к открытым файлам и помешать приложениям продолжить работу.

Что показал код 0xC000026E

В определениях NTSTATUS Microsoft код 0xC000026E означает STATUS_VOLUME_DISMOUNTED: попытку операции с отключённым томом. Это же значение присутствовало в ошибках чтения VHDX Docker.

В записях ядра WSL также были ошибки READ виртуального хранилища, переход устройства в состояние offline и авария containerd с сигналом 7. Записи Windows о виртуальном диске и последующее завершение WSL образовали согласованную хронологию.

В документации Microsoft об отключении томов объясняется, что попытка отключения возможна даже для используемого тома и может непредсказуемо повлиять на работающие с ним процессы. Этот случай соответствует такому общему свойству. Однако стек вызова именно этого API не был записан, поэтому конкретный внутренний путь вызовов Windows не установлен.

В поле причины события стояло User request. Это не было истолковано как доказательство нажатия человеком «Извлечь USB». Проверка инициирующей службы и времени связала событие с обработкой подготовки места хранения приложений Windows.

Исследованные журналы USB, PnP и связанные записи того же периода не содержали доказательств физического отключения и подключения. Во время проверки диск также сообщал состояние Healthy. Это не гарантирует отсутствия неисправностей SSD, но найденная непосредственная цепочка — отключение тома службой Storage Service и последующие ошибки доступа к VHDX.

Документированный Microsoft механизм PackageVolume — поддерживаемый способ хранения приложений. Тем не менее встроенный перенос не означал, что другие приложения на этом диске смогут продолжать работу без прерывания.

В Unity одновременно произошёл сбой ввода-вывода

На том же диске был проект Unity, и появилось окно Unity Bug Reporter. Записи Application Error показывали сбой Unity Data Store в 13:20:47–49, до перезапуска Docker. Исключение — 0xC0000006, нижележащий статус ввода-вывода — 0xC000026E.

Microsoft определяет 0xC0000006 как STATUS_IN_PAGE_ERROR: нужные данные не удалось загрузить в память из-за ошибки ввода-вывода. Нижележащий статус содержал то же значение отключения тома, что и ошибка Docker. Это подтверждает вывод о влиянии недоступности того же диска на Unity.

Однако поле имени файла события было пустым, поэтому конкретный файл, к которому Unity не получил доступ, не установлен. Одного упоминания Unity.dll в последующей записи сбоя недостаточно, чтобы утверждать повреждение DLL или необходимость переустановки.

Мы не стали немедленно перезапускать Unity. Отдельно сохранили 5 файлов общим размером около 8MB, включая существующую резервную копию сцены, журналы и дампы. Копия сцены имела время 08:31 того дня; это не доказывает сохранность несохранённой работы непосредственно перед сбоем. Во время исследования исходный проект сохранёнными файлами не перезаписывали.

Эта последовательность исключает и версию, что сначала перезапуск Docker сломал Unity. Первый сбой Unity Data Store произошёл до перезапуска Docker. Для расследования требовалось сопоставить время событий в журналах, а не полагаться только на порядок появления окон.

Перезапуск только Docker восстановил движок

Сохранив локально достаточно журналов для выяснения причины и убедившись, что диск D снова доступен, мы один раз перезапустили только Docker Desktop. Использовали официальную CLI Docker. Следующая команда влияет на текущую работу Docker, поэтому перед выполнением определите, что нужно сохранить или остановить.

docker desktop restart --timeout 45

Официальная документация Docker о перезапуске описывает --timeout как ограничение времени ожидания команды. Это не гарантия восстановления за 45 секунд. В нашем случае команда завершилась с кодом 0.

Затем командой docker version проверили ответ Server и получили Engine 29.8.2. В списке WSL docker-desktop снова значился как Running. Новый backend запустился в течение минуты 13:27.

Полученный список содержал 108 контейнеров: 1 работающий, 106 остановленных и 1 созданный. Массово запускать остановленные контейнеры мы не стали. Ответ движка отличается от прежней работоспособности баз данных и сервисов каждого проекта, поэтому функциональные проверки нужных сервисов оставили их владельцам.

Восстановление не включало заводской сброс, удаление данных, отмену регистрации WSL или переустановку. Мы также не завершали всю WSL, что затронуло бы не только Docker, и не выгружали полный набор диагностических данных вовне. Главное — не переходить сразу от окна ошибки к действиям, способным уничтожить сохранённые данные.

Какие журналы помогли найти причину

Первоначальный просмотр только System не показал решающих записей отключения тома. Отсутствие их в System не означало, что Windows ничего не записала. Упорядочивание следующих журналов по времени связало подготовку переноса приложения с ошибками ввода-вывода других программ.

При исследовании такого же симптома сначала запишите время действия, целевой диск, место виртуального диска Docker и текст ошибки — это сузит область поиска. Уточните, какие каналы журналов доступны на компьютере, и начните с существующих записей. В этом дополнительном исследовании мы не включали диагностику и не повторяли вызвавшую сбой операцию.

В статье не публикуются имя пользователя, пользовательский SID, серийные номера устройств, учётные данные или переменные среды контейнеров. При обмене журналами выделение только нужных меток времени, кодов ошибок и названий операций также упрощает понимание причины.

Что решить до переноса на другой диск

Наш недостаток — внимание к остановке и резервному копированию ChatGPT без достаточного учёта влияния на уже работающие с диском D Docker и Unity в инструкциях перед переносом. В будущем при такой задаче мы определим необходимые остановки на уровне всего диска.

1. Определите всё, что использует место назначения. Проверьте виртуальные диски Docker и ВМ, базы данных, проекты редакторов и другие процессы, держащие файлы на диске D открытыми.
2. Сохраните несохранённую работу и данные для восстановления. Обеспечьте возможность восстановить текущую работу, а не только копию самого приложения.
3. Выберите время, когда процессы, использующие диск, можно остановить. Учтите работу в других чатах и у других владельцев, не допускайте запуска новых процессов во время переноса.
4. Используйте поддерживаемую функцию переноса Windows. Не меняйте владельца или разрешения WindowsApps и WpSystem ради ручного перемещения одних папок.
5. Проверяйте перенос и другие приложения раздельно. Проверяйте действительно нужные функции по порядку: запуск приложения, сохранённые элементы, браузер, движок Docker и необходимые сервисы.

Журналы подтвердили первую регистрацию диска D как места хранения приложений. Но это не доказывает, что после регистрации такой сбой никогда не повторится. Мы не стали ради теста повторно регистрировать или отключать рабочий диск, а сохранили текущую работающую конфигурацию.

Перенос приложения на диск D также не собирает там все связанные файлы. В этом случае само приложение и его основные данные ушли на диск D, а активная CLI и другие компоненты остались на диске C. Расположение и размеры описаны в нашем отчёте о переносе ChatGPT и Codex между дисками.

Успешный перенос не означает, что другие приложения не пострадали

Само приложение ChatGPT успешно перенесено на диск D, после чего мы проверили действия браузера и сохранённые элементы. Одновременно при подготовке места назначения весь диск D был отключён, что привело к сбоям Docker и других приложений, использовавших виртуальные диски на нём. Одно событие успешного переноса не доказывало отсутствия влияния на остальные приложения.

Журналы объясняют непосредственную цепочку сбоя в этом случае. Мы не установили, какая внутренняя ветвь вызовов Windows запросила отключение тома и повторяется ли поведение на других компьютерах или версиях Windows. Конкретная мера предосторожности, подтверждаемая случаем: до начала остановить не только переносимое приложение, но и активные процессы, использующие диск D.

Частые вопросы

Переустановка WSL исправит «There was a problem with WSL»?

Здесь сбой был связан с потерей доступа к виртуальному диску. Перезапуск одного Docker восстановил движок; WSL не переустанавливали и не отменяли его регистрацию. Первичная проверка журналов времени сбоя лучше защищает сохранённые данные.

Это значит, что SSD диска D сломался?

Мы нашли прямую запись об отключении диска D службой Storage Service. Записей физического отключения в тот же момент не обнаружили. Этот случай не даёт оснований делать вывод о поломке SSD.

Стоит избегать встроенного переноса приложений Windows?

Перенос пакета на другой том — поддерживаемая функция Windows. После этого опыта мы предусмотрим время на остановку других приложений на том же диске, резервное копирование и проверку работы, вместо того чтобы оставлять их работающими при переносе.

Если Docker запускается, можно считать всё восстановленным?

Ответ движка отличается от состояния сервисов и содержимого баз данных внутри каждого контейнера. Мы проверили восстановление движка и получили список; функциональные проверки нужных проектов остаются отдельной задачей.