Команда wsl в терминале возвращает ошибку 0x80370102, 0x8007019e или просто молча зависает — это типичные симптомы, с которыми сталкиваются пользователи подсистемы Windows для Linux. Чаще всего причина кроется в отключённой виртуализации, неустановленных компонентах Windows или сбое службы LxssManager.
Проблема почти всегда решается без переустановки системы, но требует последовательной диагностики: сначала проверяются базовые компоненты, затем настройки BIOS и только потом выполняется сброс или переустановка дистрибутива. Ниже разберём каждый шаг подробно.
Проверка состояния WSL и установленных компонентов
Первое действие — выяснить, установлен ли WSL вообще и видит ли система дистрибутивы. Откройте PowerShell или Терминал Windows от имени администратора и выполните:
wsl --status
wsl --list --verbose
Если первая команда сообщает, что подсистема не установлена, а вторая выдаёт ошибку — проблема на уровне компонентов Windows. Если дистрибутив в списке есть, но находится в состоянии Stopped и не стартует, диагностика идёт по другой ветке.
- 🔍 Проверьте версию WSL командой
wsl --version— если команда не распознаётся, установлена старая встроенная версия или компонент отсутствует - 📋 Убедитесь, что дистрибутив отображается в выводе
wsl -l -vи его состояние не Installing - ⚙️ Попробуйте запустить дистрибутив напрямую:
wsl -d ИмяДистрибутива - 🔄 Выполните
wsl --shutdownи повторите попытку запуска через минуту
Включение компонентов Windows
WSL зависит от двух функций Windows: Виртуальная машина платформы Windows (Virtual Machine Platform) и Подсистема Windows для Linux. Если хотя бы одна отключена, подсистема не запустится.
Проверить и включить их можно через окно «Компоненты Windows» (optionalfeatures в диалоге «Выполнить») или командами DISM в PowerShell с правами администратора:
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
После выполнения обеих команд обязательна перезагрузка компьютера — без неё изменения не вступят в силу, и ошибки повторятся. Это одна из самых частых причин «неисправности», которая на деле оказывается недожатой настройкой.
⚠️ Внимание: на домашних редакциях Windows старых версий компонент «Платформа виртуальной машины» может отсутствовать. Если его нет в списке компонентов, сначала обновите Windows до актуальной версии через Центр обновления.
☑️ Базовая проверка перед запуском WSL
Виртуализация в BIOS/UEFI и ошибка 0x80370102
Ошибка 0x80370102 при запуске дистрибутива почти всегда означает, что аппаратная виртуализация отключена на уровне прошивки. WSL2 работает поверх гипервизора Hyper-V, и без включённой виртуализации в BIOS/UEFI он функционировать не может.
Название нужной настройки зависит от производителя процессора и материнской платы: у Intel это обычно Intel Virtualization Technology (VT-x), у AMD — SVM Mode или AMD-V. Найти её следует в разделах Advanced, Advanced BIOS Features или Configuration — точный путь уточните в документации к вашей материнской плате или ноутбуку, так как расположение пункта у разных производителей различается.
Быстро проверить, включена ли виртуализация, можно без входа в BIOS: откройте Диспетчер задач, перейдите на вкладку «Производительность», выберите ЦП — в правой части окна есть строка «Виртуализация». Значение «Включено» означает, что проблема не в BIOS.
Типовые ошибки и их расшифровка
Разные коды ошибок указывают на разные причины. Таблица ниже поможет сориентироваться, с чего начать поиск.
| Код ошибки | Вероятная причина | Что проверить |
|---|---|---|
| 0x80370102 | Виртуализация отключена в BIOS/UEFI | Настройки VT-x / SVM, Диспетчер задач |
| 0x8007019e | Компонент WSL не включён в Windows | Компоненты Windows, команды DISM |
| 0x800701bc | Устаревшее ядро WSL2 | Команда wsl --update |
| Ошибка сети внутри WSL | Сбой DNS или конфликт с VPN/антивирусом | Файл resolv.conf, отключение VPN для проверки |
Обратите внимание: один и тот же код иногда возникает по разным причинам, поэтому таблица — это отправная точка, а не окончательный диагноз. Если действие из третьего столбца не помогло, переходите к следующим разделам.
Обновление ядра и сброс WSL
Если компоненты включены, а виртуализация активна, следующий шаг — обновить ядро подсистемы. Выполните в PowerShell с правами администратора:
wsl --update
wsl --shutdown
Когда обновление не помогает, можно перезапустить службу LxssManager, отвечающую за работу подсистемы. Это делается через консоль служб (services.msc) или командой Restart-Service LxssManager в PowerShell с повышенными правами. Служба может зависнуть после аварийного завершения работы или обновления Windows.
В крайнем случае допустимо выполнить отмену регистрации конкретного дистрибутива командой wsl --unregister ИмяДистрибутива и установить его заново из Microsoft Store. Эта операция безвозвратно удаляет все файлы внутри дистрибутива — перед ней обязательно скопируйте важные данные, например через wsl --export.
⚠️ Внимание: команда
wsl --unregisterстирает всю файловую систему дистрибутива, включая домашний каталог и установленные пакеты. Сначала создайте резервную копию:wsl --export ИмяДистрибутива D:\backup.tar.
Как проверить, не мешает ли сторонний антивирус или VPN
Временно отключите VPN-клиент и защиту антивируса, затем выполните wsl --shutdown и запустите дистрибутив снова. Некоторые сетевые фильтры сторонних программ перехватывают трафик виртуального коммутатора WSL2, из-за чего подсистема зависает при запуске или теряет сеть. Если после отключения всё заработало — добавьте процессы WSL в исключения соответствующей программы.
Когда ничего не помогает
Если все перечисленные шаги выполнены, а WSL по-прежнему не работает, остаются системные варианты. Проверьте целостность системных файлов командой sfc /scannow и убедитесь, что в системе нет повреждений хранилища компонентов: DISM /Online /Cleanup-Image /RestoreHealth. Обе команды запускаются от имени администратора и могут занять продолжительное время.
Также имеет смысл изучить журналы событий Windows: откройте «Просмотр событий» и посмотрите раздел «Журналы Windows → Система» на предмет ошибок, связанных с Hyper-V и службой LxssManager в момент запуска WSL. Текст конкретной ошибки в журнале часто указывает на причину точнее, чем код в терминале.
- 🧩 Убедитесь, что не используются одновременно конфликтующие гипервизоры — старые версии некоторых эмуляторов и виртуальных машин несовместимы с Hyper-V
- 💻 На виртуальной машине WSL2 требует вложенной виртуализации, которая поддерживается не везде
- 📦 Попробуйте установить другой дистрибутив из Microsoft Store, чтобы отделить проблему подсистемы от проблемы конкретного образа
⚠️ Внимание: не отключайте Hyper-V и платформу виртуальной машины ради «освобождения ресурсов», если пользуетесь WSL2, Docker Desktop или песочницей Windows — все эти функции зависят от одного гипервизора и перестанут работать вместе.
Часто задаваемые вопросы
Чем отличается WSL1 от WSL2 и влияет ли это на ошибки?
WSL1 работает через трансляцию системных вызовов и не требует виртуализации, а WSL2 использует полноценное ядро Linux в лёгкой виртуальной машине. Ошибка 0x80370102 характерна именно для WSL2. Переключить версию для дистрибутива можно командой wsl --set-version ИмяДистрибутива 1 — это рабочий обходной путь, если включить виртуализацию невозможно.
Почему команда wsl не распознаётся в PowerShell?
Возможные причины: компонент подсистемы не установлен, используется устаревшая версия Windows без поддержки WSL или повреждены системные файлы. Начните с проверки компонентов Windows и обновления системы.
WSL запускается, но внутри нет интернета. Что делать?
Частая причина — сбой автоматической генерации DNS-настроек или конфликт с VPN. Проверьте содержимое файла /etc/resolv.conf внутри дистрибутива, временно отключите VPN и выполните wsl --shutdown с последующим запуском.
Удалятся ли мои файлы при выполнении wsl --update или wsl --shutdown?
Нет. Обе команды затрагивают только ядро и работающие процессы подсистемы — файловая система дистрибутивов остаётся нетронутой. Данные удаляет только команда wsl --unregister.
Можно ли использовать WSL на виртуальной машине?
Да, но только если гипервизор, на котором работает виртуальная машина, поддерживает вложенную виртуализацию и она включена для этой ВМ. Без неё WSL2 внутри виртуальной машины запуститься не сможет — используйте WSL1.