Почніть із перезавантаження Docker Desktop та віртуальної машини WSL 2, а не з перевстановлення Docker або видалення його даних WSL. На сучасних конфігураціях Windows Docker Desktop зазвичай використовує бекенд WSL 2, тому повідомлення «Engine stopped» може вказувати на проблему з Docker Desktop, WSL або віртуалізацією Windows. Найшвидший шлях до виправлення — визначити, який саме шар не працює, перш ніж вносити руйнівні зміни.
Станом на вересень 2026 року документація Docker для Windows вимагає WSL 2.1.5 або новішої версії для бекенда WSL 2 та рекомендує використовувати останню версію WSL. Docker також описує WSL 2 як бекенд за замовчуванням для більшості користувачів Windows. Microsoft документує команди wsl --version, wsl --status, wsl --update та wsl --shutdown як стандартні команди для перевірки, оновлення та перезавантаження середовища WSL. Див. вимоги до встановлення Docker для Windows, документацію Docker щодо бекенда WSL 2 та довідник команд WSL від Microsoft.
Цей посібник використовує чотири етапи виправлення, від найбезпечнішого до найбільш руйнівного. Зупиніться, щойно Docker знову запрацює.
| Що ви бачите | Найкорисніша наступна перевірка |
|---|---|
| Docker Desktop відкривається, але повідомляє, що рушій зупинено | Перезавантажте Docker Desktop, потім протестуйте демон Docker |
wsl --status або wsl --version завершуються помилкою | Відновіть або оновіть WSL перед зміною даних Docker |
| WSL повідомляє про помилку віртуалізації або необхідної функції | Перевірте платформу віртуальних машин та віртуалізацію в BIOS/UEFI |
| WSL працює, але Docker все одно не запускається | Перевірте налаштування Docker Desktop, оновіть Docker та зберіть діагностику |
| Проблема почалася одразу після оновлення | Перевірте поточні примітки до випуску Docker Desktop на наявність відомої проблеми з Windows/WSL |
Що відомо: ці шари залежать один від одного. Що невідомо лише з повідомлення «Engine stopped»: який шар не працює на вашому ПК. Самого повідомлення недостатньо, щоб виправдати повне скидання системи.
Спершу скористайтеся опцією Docker Desktop Troubleshoot > Restart Docker Desktop. Docker документує «Restart Docker Desktop» як першу неруйнівну дію в меню Troubleshoot. У версіях, що включають CLI Docker Desktop, ви також можете використати:
docker desktop status
docker desktop restartПоточна довідка CLI Docker документує команди status, start, stop та restart. Див. документацію CLI Docker Desktop та документацію з усунення несправностей Docker Desktop.
Після перезавантаження Docker протестуйте демона:
docker version
docker infoЯкщо docker version повертає інформацію про клієнта та сервер замість помилки з’єднання з демоном, рушій знову відповідає.
Корисна дія: якщо перезавантаження допомогло, зупиніться тут. Не скидайте WSL, не реєструйте дистрибутиви та не перевстановлюйте Docker лише тому, що це рекомендує інший посібник.
Це не універсальне рішення. Поточна документація Docker щодо дозволів у Windows стверджує, що для контейнерів Linux WSL 2 привілейований помічник com.docker.service загалом не потрібен і тому не обов’язково запускається автоматично під час завантаження. Він необхідний для таких сценаріїв, як контейнери Windows та бекенд Hyper-V, а також може використовуватися для певних привілейованих операцій з файлами хоста.
Отже, зупинений com.docker.service не є доказом того, що встановлення контейнерів Linux WSL 2 пошкоджено. Див. вимоги Docker щодо дозволів у Windows.
Корисна дія: визначте, чи використовуєте ви контейнери Linux WSL 2, перш ніж вважати службу Windows першопричиною.
Відкрийте PowerShell або Windows Terminal і виконайте:
wsl --version
wsl --status
wsl -l -vDocker наразі вимагає WSL 2.1.5 або новішої версії для свого бекенда WSL 2 та рекомендує найновіший доступний випуск WSL. Якщо ваша версія WSL старіша, оновіть її:
wsl --updateПотім повністю зупиніть середовище WSL 2:
wsl --shutdownMicrosoft зазначає, що wsl --shutdown негайно завершує всі запущені дистрибутиви та легку віртуальну машину WSL 2. Запустіть Docker Desktop знову після завершення роботи. Якщо Windows або WSL вимагали перезавантаження під час оновлення, перезавантажте Windows перед повторним тестуванням.
Корисна дія: виконуйте команди в цьому порядку та записуйте будь-який точний код помилки. Помилка від wsl --status є більш корисною для діагностики, ніж загальне повідомлення Docker «Engine stopped».
Docker Desktop не вимагає конкретного встановленого користувачем дистрибутива Linux. Документація Docker щодо WSL стверджує, що команди Docker можуть працювати з Windows без встановленого конкретного дистрибутива Linux; увімкнення інтеграції WSL для Ubuntu, Debian або іншого дистрибутива є необов’язковим для робочих процесів, нативних для Linux.
Корисна дія: якщо сам WSL запускається правильно, не видаляйте робочий дистрибутив Ubuntu або Debian лише для виправлення Docker Desktop.
Microsoft явно попереджає, що wsl --unregister <DistributionName> назавжди видаляє дані, налаштування та встановлене програмне забезпечення цього дистрибутива. Тому команди, які реєструють дистрибутиви WSL, пов’язані з Docker або особисті, є руйнівним усуненням несправностей, а не звичайними командами перезавантаження.
Корисна дія: спершу використайте wsl --shutdown. Зробіть резервну копію важливих даних перед будь-якою процедурою реєстрації, скидання, очищення або перевстановлення.
WSL 2 потребує підтримки віртуалізації. Microsoft стверджує, що WSL 2 вимагає функції Virtual Machine Platform та апаратної підтримки віртуалізації. FAQ Microsoft щодо WSL також визначає два необхідні компоненти Windows для WSL 2: Virtual Machine Platform та Windows Subsystem for Linux. Див. FAQ Microsoft щодо WSL та інструкції Microsoft щодо ручного встановлення WSL.
Відкрийте Увімкнути або вимкнути компоненти Windows та переконайтеся, що ці дві функції увімкнено:
Якщо будь-яка з цих функцій була вимкнена, увімкніть її та перезавантажте Windows.
Повний клієнтський Hyper-V — це не те саме, що компоненти віртуалізації, які використовує WSL 2. Microsoft пояснює, що WSL 2 використовує підмножину архітектури Hyper-V, надану через Virtual Machine Platform. Повний Hyper-V недоступний у Windows Home, тоді як WSL 2 підтримується у Windows Home, де доступний WSL. Docker також розглядає WSL 2 та Hyper-V як окремі бекенди.
Корисна дія: якщо ви використовуєте бекенд WSL 2, спершу перевірте WSL та Virtual Machine Platform, а не вмикайте навмання всі прапорці, пов’язані з Hyper-V.
Це більш конкретна підказка, ніж «Engine stopped». Сторінка усунення несправностей WSL Microsoft стверджує, що помилка 0x80370102 може означати, що необхідна функція віртуалізації недоступна. Microsoft рекомендує перевірити Virtual Machine Platform, віртуалізацію BIOS/UEFI, підтримку віртуалізації процесором та конфігурацію запуску гіпервізора.
У вікні PowerShell з підвищеними правами ви можете перевірити налаштування запуску гіпервізора:
bcdedit /enum | findstr -i hypervisorlaunchtypeЯкщо він явно повідомляє hypervisorlaunchtype Off, рекомендації Microsoft щодо усунення несправностей стверджують, що його можна увімкнути за допомогою:
bcdedit /set hypervisorlaunchtype AutoПісля цього перезавантажте Windows. Див. посібник Microsoft з усунення несправностей WSL.
Корисна дія: використовуйте це виправлення конфігурації завантаження лише тоді, коли ваші симптоми вказують на віртуалізацію або гіпервізор. Не змінюйте налаштування завантаження лише тому, що Docker працює повільно або не вдалося запустити один контейнер.
Якщо WSL запускається нормально, але Docker Desktop все ще не працює, поверніться до шару Docker.
Для контейнерів Linux документація Docker щодо WSL стверджує, що Docker Desktop використовує рушій WSL 2, коли цей бекенд увімкнено. Залежно від поточної версії Docker Desktop та підтримуваної системи, налаштування «Use WSL 2 based engine» може бути увімкнено за замовчуванням і може бути невидимим.
Якщо Settings > Resources > WSL Integration відсутнє, а ви очікували інтеграції контейнерів Linux, Docker зазначає, що Docker Desktop може перебувати в режимі контейнерів Windows. У такій ситуації поверніться до контейнерів Linux, якщо саме їх ви збираєтеся запускати.
Корисна дія: не змінюйте режим контейнерів лише як випадковий крок усунення несправностей. Підтвердіть, чи ваш проєкт дійсно використовує контейнери Linux або Windows.
Використовуйте розділ «Software updates» у Docker Desktop або поточний інсталятор з офіційної сторінки встановлення Docker для Windows. Примітки до випусків Docker часто містять виправлення та відомі проблеми, специфічні для Windows та WSL, тому їх варто перевіряти, коли проблема починається одразу після оновлення. Див. примітки до випусків Docker Desktop.
Корисна дія: запишіть поточні версії Docker Desktop та WSL перед оновленням. Якщо в недавніх примітках до випуску описано ваш точний симптом, дотримуйтесь задокументованого обхідного шляху, а не застосовуйте несумісні команди реєстру або видалення WSL.
Меню Troubleshoot у Docker Desktop може збирати діагностичну інформацію, навіть коли додаток має проблеми з запуском. Docker також документує:
docker desktop diagnoseДокументація CLI Docker Desktop стверджує, що команда diagnose доступна у Docker Desktop 4.60 та новіших версіях. Якщо ваша встановлена версія не підтримує цю команду, скористайтеся інтерфейсом Troubleshoot або задокументованим шляхом до виконуваного файлу com.docker.diagnose від Docker.
Корисна дія: збережіть ідентифікатор діагностики та запишіть точну помилку запуску перед скиданням чогось. Ці докази корисні, якщо вам потрібно порівняти журнали, знайти поточну відому проблему або відкрити звернення до служби підтримки.
Меню Troubleshoot у Docker Desktop включає Clean up data та Reset to factory defaults. Це варіанти останньої надії, а не звичайні виправлення. Документація Docker щодо резервного копіювання рекомендує створювати резервні копії важливих образів, томів та даних віртуальної машини Docker Desktop перед перевстановленням або скиданням, коли Docker Desktop не може запуститися нормально. Див. посібник Docker з резервного копіювання та відновлення.
Коли демон ще працює достатньо добре, щоб використовувати команди Docker, збережіть важливе перед скиданням. Наприклад, важливі образи можна завантажити в реєстр або зберегти в архів tar. Дані томів потребують власної стратегії резервного копіювання.
Якщо Docker Desktop взагалі не запускається, Docker документує процедуру Windows для резервного копіювання віртуального диска Docker Desktop перед перевстановленням. Дотримуйтесь поточного офіційного шляху з посібника з резервного копіювання, оскільки внутрішня структура зберігання даних Docker може змінюватися між випусками.
Корисна дія: не натискайте «Reset to factory defaults», доки не зможете відповісти: «Де знаходиться єдина копія моїх важливих даних тому?»
Перевстановлення є розумним після того, як ви встановили, що:
Використовуйте поточний інсталятор від Docker, а не старий інсталятор, кешований з попереднього посібника. Поточна документація Docker щодо встановлення для Windows також розрізняє режими встановлення для окремого користувача та для всіх користувачів. Бекенд WSL 2 охоплює більшість користувачів, тоді як бекенд Hyper-V та контейнери Windows мають різні вимоги до встановлення та привілеїв.
Корисна дія: якщо ви змінюєте режим встановлення або бекенд під час перевстановлення, змінюйте одну змінну за раз, щоб зрозуміти, що саме виправило проблему.
Зазвичай це питання інтеграції, а не доказ того, що рушій Docker зупинено. Docker стверджує, що інтеграцію WSL можна увімкнути для вибраних дистрибутивів WSL 2 у Settings > Resources > WSL Integration. Сам дистрибутив користувача має працювати в режимі WSL 2.
Перевірте це за допомогою:
wsl -l -vЯкщо дистрибутив користувача все ще на WSL 1, Microsoft документує конвертацію за допомогою:
wsl --set-version <DistributionName> 2Microsoft попереджає, що конвертація великих дистрибутивів може зайняти час і завершитися помилкою, тому робіть резервні копії важливих файлів перед великою конвертацією WSL.
Корисна дія: розрізняйте «демон Docker не працює» та «цей дистрибутив WSL не має доступу до Docker». Це різні проблеми, і вони не повинні запускати однакові кроки виправлення.
Якщо Windows 11 працює всередині VMware, Hyper-V, Azure або іншого гіпервізора, WSL 2 може вимагати вкладеної віртуалізації — віртуалізації, наданої через зовнішню віртуальну машину гостьовій системі Windows. Microsoft документує вимоги до вкладеної віртуалізації та зазначає, що підтримка залежить від платформи хоста та конфігурації.
Корисна дія: якщо це корпоративний VDI або хмарна віртуальна машина, підтвердіть підтримку вкладеної віртуалізації з адміністратором платформи, перш ніж витрачати час на перевстановлення Docker Desktop.
docker version.wsl --version та wsl --status.wsl --update, потім wsl --shutdown та повторіть спробу з Docker.0x80370102, дотримуйтесь цільового усунення несправностей WSL від Microsoft.«Docker Desktop Engine Stopped» — це симптом, а не єдиний діагноз. У Windows 11 з бекендом WSL 2 найбезпечніший шлях виправлення — перезавантажити Docker, перевірити та оновити WSL, підтвердити віртуалізацію лише якщо WSL повідомляє про пов’язану відмову, та зібрати діагностику Docker перед використанням руйнівних опцій скидання.
Дві найважливіші помилки, яких слід уникати, є однаково простими: не припускайте, що зупинена служба Docker у Windows є причиною на кожній конфігурації WSL 2, і не реєструйте дистрибутиви WSL або не скидайте Docker до заводських налаштувань перед резервним копіюванням даних. Ці кроки можуть перетворити проблему запуску на проблему втрати даних, не вирішуючи початкову причину.
Виправте помилку незгенерованого Prisma Client, перевіривши генератор, схему, шлях виводу, імпорти, версії, налаштування монорепозиторію та кроки збірки під час розгортання.
Виправте помилку Git «не вдалося отримати локальний сертифікат емітента», визначивши механізм довіри, встановивши правильний ланцюжок ЦС та зберігаючи перевірку SSL увімкненою.
Виправте помилки таймауту мережі MongoDB у Mongoose, визначивши тип таймауту, перевіривши доступність Atlas або TCP, виправивши URI та налаштувавши таймаути лише за необхідності.
Виправте помилку обмеженої політики виконання PowerShell, перевіривши область дії та групову політику, а потім обравши RemoteSigned, Unblock-File або тимчасовий параметр сесії.
Виправте конфлікти залежностей-партнерів npm ERESOLVE, визначивши несумісний діапазон пакетів, узгодивши версії, використовуючи npm explain та npm ls, а також розглядаючи legacy-peer-deps або force лише як контрольовані резервні варіанти.
Виправте помилки відмови у підключенні Redis на 127.0.0.1:6379, перевіривши сервер, порт, мережу Docker, redis.conf, автентифікацію та TLS.
Виправте помилки 500 у серверних компонентах Next.js, аналізуючи логи сервера, перевіряючи запити даних та змінні середовища, обробляючи помилки та перевіряючи збірку для продакшену.
Діагностуйте та виправляйте помилку CrashLoopBackOff у Kubernetes у локальному Minikube, перевіряючи стан пода, попередні логи, причини завершення роботи, проби, конфігурацію, ліміти пам’яті та стан кластера.
Виправте помилку «Docker Desktop Engine Stopped» у Windows 11, перевіривши статус Docker, оновивши та перезавантаживши WSL 2, підтвердивши віртуалізацію та використавши діагностику перед скиданням налаштувань.
Виправте помилку 'process is not defined' у Vite, замінивши використання process.env у стилі Node.js, правильно налаштувавши змінні VITE_ та перевіривши залежності.
