Microsoft 3 октября 2026 года создала тег WSL 3.0.2 в официальном репозитории проекта. Изменение возвращает защиту WSLInterop в binfmt_misc: после WSL 3.0.1 сторонний обработчик, например установленный вместе с Mono, мог перехватить запуск Windows-программ из Linux. На момент проверки 4 октября GitHub API Microsoft всё ещё считает WSL 3.0.1 последним полноценным release.
WSL 3.0.2 восстанавливает обработчик для запуска Windows-программ из Linux
Сбой затрагивал одну из самых привычных возможностей Windows Subsystem for Linux — запуск Windows-программ прямо из терминала Linux. В обычной WSL-сессии можно выполнить notepad.exe, explorer.exe ., powershell.exe или другую Windows-команду без выхода из Ubuntu, Debian и других дистрибутивов.
За этой возможностью стоит механизм Linux binfmt_misc. Он позволяет ядру определить тип исполняемого файла и передать его подходящему обработчику. WSL регистрирует собственную запись WSLInterop, благодаря которой Windows PE-файлы с сигнатурой MZ запускаются через Windows.
После WSL 3.0.1 эта цепочка могла нарушиться. Если другой пакет регистрировал обработчик для того же типа файлов, запись WSL переставала получать управление. В результате Windows-программа из Linux уже не стартовала привычным способом.
Microsoft описала исправление в pull request #41780: WSL снова создаёт свою запись binfmt_misc, если её заменил другой обработчик или служба systemd-binfmt.
Проблему заметили сразу после WSL 3.0.1
WSL 3.0.1 Microsoft опубликовала 29 сентября. Версия стала крупной точкой для проекта: WSL Containers перешёл в статус generally available, а сам релиз включал ряд изменений для конфигурации, SDK, файловых операций и завершения виртуальной машины.
Уже 30 сентября в репозитории появился отчёт об ошибке #41739. Пользователь Debian 13 с установленным Mono обнаружил, что после перехода на WSL 3.0.1 команда notepad.exe перестала работать из Linux.
Вместо запуска Windows-программы система возвращала сообщение:
run-detectors: unable to find an interpreter for /mnt/c/WINDOWS/system32/notepad.exe
Причиной оказался обработчик cli, который Mono регистрирует через binfmt_misc. Он распознавал тот же формат Windows PE и получал управление раньше WSLInterop. В отчёте указано, что похожее поведение наблюдали и пользователи Ubuntu и Arch Linux.
Здесь и появляется главная особенность этой ошибки: сама Windows, установленный Linux-дистрибутив и файл notepad.exe оставались исправными. Ломался механизм, который связывает две среды на уровне запуска исполняемых файлов.
В 3.0.2 WSL заново регистрирует WSLInterop после конфликта
Исправление в коде представляет собой частичный откат предыдущего изменения WSL. Разработчики вернули логику, которая следит за собственной записью WSLInterop и восстанавливает её, когда systemd-binfmt или другой обработчик заменяет регистрацию.
В pull request перечислены два ключевых элемента изменения:
- WSL снова генерирует systemd override для восстановления собственного
binfmt_misc-обработчика; - автоматический тест проверяет, что
WSLInteropвозвращается после запуска, остановки и повторной регистрации обработчиков черезsystemd-binfmt.
Поведение связано с параметрами конфигурации boot.protectBinfmt и включённой interop-функцией. Для пользователя смысл проще: WSL должен сохранять возможность запускать Windows .exe из Linux даже в системе, где другие пакеты работают с binfmt_misc.
Разработчик Microsoft Blue, который подготовил исправление, отдельно отметил ещё один связанный момент: read-only-монтирование может приводить к сбою запуска systemd-binfmt. Этот вопрос назван уже существующей отдельной проблемой и в изменение 3.0.2 не входит.
Исправление затрагивает смешанные Windows/Linux-сценарии
Сбой становится заметен там, где Linux-команды и Windows-инструменты используются в одной рабочей цепочке. Официальная документация Microsoft приводит такие сценарии как штатную возможность WSL: Windows-программу можно вызвать из Linux по имени с расширением .exe, а вывод Windows- и Linux-команд можно объединять через конвейеры.
Для затронутой конфигурации разница выглядит так:
| Сценарий | WSL 3.0.1 при конфликте binfmt_misc | Изменение в 3.0.2 |
notepad.exe из Linux | запуск мог завершиться ошибкой | WSL восстанавливает свой обработчик |
explorer.exe . | мог не открыться через interop | регистрация WSLInterop защищается от замены |
| Windows-команда внутри Linux-скрипта | цепочка могла оборваться | обработчик WSL повторно регистрируется |
Система с Mono или другим binfmt_misc-обработчиком | возможен конфликт приоритета | WSL возвращает собственную запись |
Механизм важен прежде всего для разработчиков, которые используют WSL как связующее звено между Linux-инструментами и Windows-программами. Ошибка могла проявляться неожиданно после установки пакета, добавляющего собственный обработчик форматов, даже если пользователь ничего не менял в настройках WSL вручную.
WSL 3.0.2 пока остаётся тегом, а latest release — 3.0.1
На момент проверки 4 октября статус WSL 3.0.2 отличается от обычного опубликованного релиза. Страница тега 3.0.2 создана 3 октября и указывает на коммит 0dc1bc1, связанный с исправлением binfmt_misc.
При этом официальный GitHub API репозитория Microsoft возвращает WSL 3.0.1 как текущий latest release. У 3.0.1 опубликованы установочные пакеты MSIX и MSI для x64 и ARM64, тогда как страница 3.0.2 на момент проверки показывает только стандартные исходные архивы тега.
Получается редкая ситуация: номер 3.0.2 уже закреплён в репозитории и содержит конкретное исправление регрессии, но обычный канал релизов Microsoft пока указывает на 3.0.1. Следующий вопрос здесь вполне конкретный — когда тег 3.0.2 превратится в распространяемый пакет и появится в официальном канале обновления WSL.
