WSL 3.0.4 — Microsoft исправила риск зависаний при завершении Linux-контейнеров

17 октября 2026 года в репозитории Microsoft появился тег WSL 3.0.4 с исправлениями ошибок синхронизации в подсистеме WSL Containers. Изменения защищают механизм отслеживания Linux-процессов от взаимной блокировки и обращения к уже освобождённой памяти. Особенно важны ситуации, когда процессы одновременно запускаются, завершаются или продолжают взаимодействовать с виртуальной машиной во время её остановки.

При завершении процессов WSLc могла возникнуть взаимная блокировка

В коде WSL Containers обнаружили потенциальную ошибку в механизме WatchForExitedProcesses, который следит за завершением запущенных Linux-процессов. Разработчик Microsoft Blue описал её в запросе на изменение кода № 41928, объединённом с основной веткой проекта 17 октября.

Проблема возникала из-за того, как служба работала с объектами процессов и блокировкой общего списка. Во время поиска завершённого процесса она могла получить последнюю действующую ссылку на управляющий объект. Когда эта ссылка освобождалась, деструктор объекта вызывал OnProcessReleased() и пытался повторно захватить блокировку, которую текущий поток уже удерживал.

Такой сценарий называется deadlock, или взаимной блокировкой: выполнение останавливается из-за ожидания доступа к ресурсу. Разработчики указывают именно на потенциальную ошибку. Подтверждённых сведений о массовых зависаниях, вызванных этим механизмом, в описании исправления нет.

Отдельный реестр исключает обращение к уничтоженной виртуальной машине

Вторая ошибка была связана со временем жизни объектов. Управляющий объект Linux-процесса мог сохраняться после уничтожения связанной с ним виртуальной машины. При освобождении процесса обратный вызов обращался к объекту машины, которого уже не существовало. Это типичная ситуация use-after-free — использование памяти после её освобождения.

Исправление меняет хранение сведений о процессах. Microsoft вынесла их в отдельную структуру VMProcessRegistry, управляемую через shared_ptr. Процессы обращаются к реестру через слабые ссылки weak_ptr: прежде чем пользоваться реестром, код проверяет, существует ли он ещё.

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

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

Остановка WSL Containers стала безопаснее для команд терминала

С обновлённой логикой связан ещё один запрос на изменение кода — № 41929, объединённый 16 октября. Он закрывает отдельное состояние гонки при работе с функциями Signal() и ResizeTty().

Эти операции используются для отправки сигнала процессу и изменения размера его терминала. Раньше внешний вызов мог начаться в тот момент, когда виртуальная машина уже уничтожала канал связи с Linux-процессами. В таком случае возникал риск обращения к ресурсам, освобождаемым в процессе остановки.

Теперь служба сначала отсоединяет связанные процессы и лишь затем освобождает канал инициализации. Операции изменения размера терминала для отключённых или завершённых процессов отклоняются. Для пользователей wslc.exe и приложений, использующих WSL Containers API, это закрывает узкий сценарий параллельного управления контейнерными процессами во время выключения среды.

Исправление проверяют параллельным запуском 200 процессов

В коммите, на который указывает тег 3.0.4 (ce88638), разработчики добавили нагрузочный тест RootNamespaceProcessReleaseAndExitStress. Он запускает четыре потока, каждый из которых 50 раз создаёт короткоживущий Linux-процесс /bin/true. Всего тест охватывает 200 запусков, после чего дополнительно проверяет доставку уведомлений о завершении процессов.

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

Тег WSL 3.0.4 и установленная версия WSL — разные состояния

WSL позволяет запускать Linux-инструменты и дистрибутивы в Windows. С сентября 2026 года Microsoft также предоставляет WSL Containers — встроенный механизм управления Linux-контейнерами через wslc.exe и программный интерфейс. Изменения из рассмотренных запросов относятся именно к этой контейнерной инфраструктуре, что видно по затронутым файлам src/windows/wslcsession.

На GitHub подтверждён тег 3.0.4 от 17 октября 2026 года. Он указывает на коммит с исправлениями, но сам факт появления тега ещё не подтверждает, что эту версию уже распространяют через Microsoft Store или стандартный канал обновления WSL.

В официальной документации Microsoft приведены две команды PowerShell для работы с установленной подсистемой:

wsl --version
wsl --update

Первая показывает версию WSL и её компонентов. Вторая запускает обновление до версии, доступной через выбранный канал. Номер, указанный в репозитории GitHub, и версия, полученная после обновления на конкретном компьютере, могут различаться.

Исправления ограничены механизмом управления процессами WSLc

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

Исходный код исправлений доступен в основной ветке проекта, а тег версии датирован 17 октября. Когда соответствующие изменения станут доступны всем пользователям через обычные механизмы обновления Windows и WSL, определяется публикацией и распространением установочных пакетов Microsoft.