Как да поправите Docker Desktop Engine Stopped на Windows 11

Започнете с рестартиране на 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 и референцията на Microsoft за команди на WSL.

Това ръководство използва четири фази за поправка, от най-безопасната до най-разрушителната. Спрете веднага щом 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“: кой слой се провали на вашия компютър. Самото съобщение не е достатъчно, за да оправдае фабрично нулиране.

Фаза 1: Рестартирайте Docker Desktop и проверете демона

Илюстрация с AI на Docker Desktop на Windows 11, показваща съобщение Engine stopped и бутон Restart Docker Desktop
Илюстрация, генерирана от AI, на екран за спиране на двигателя на Docker Desktop. Това не е реален екранен запис на Docker Desktop, а точният текст на интерфейса може да варира в зависимост от версията.

Използвайте опцията Troubleshoot > Restart Docker Desktop на 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 само защото друг урок го препоръчва.

Често срещано недоразумение: рестартирайте com.docker.service за всяка грешка Engine Stopped

Това не е универсално решение. Текущата документация на Docker за разрешенията в Windows посочва, че за Linux контейнери с WSL 2, привилегираният помощник com.docker.service не е общо взето необходим и следователно не се стартира автоматично при зареждане. Той е необходим за сценарии като Windows контейнери и бекенда Hyper-V, и може да се използва и за определени привилегирани операции с файлове на хоста.

Така че спрелият com.docker.service не е доказателство, че инсталацията на Linux контейнери с WSL 2 е повредена. Вижте изискванията за разрешения на Docker за Windows.

Полезно действие: определете дали използвате Linux контейнери с WSL 2, преди да третирате услугата на Windows като основна причина.

Фаза 2: Проверете и рестартирайте WSL 2

Илюстрация с AI на команден ред на Windows, показваща проверки на статуса и версията на WSL за отстраняване на неизправности на Docker
Илюстрация на команден ред, генерирана от AI. Показаните номера на версии са илюстративни; използвайте командите на вашия собствен компютър за реалните стойности.

Отворете PowerShell или Windows Terminal и изпълнете:

wsl --version
wsl --status
wsl -l -v

Docker в момента изисква WSL 2.1.5 или по-нова версия за своя бекенд WSL 2 и препоръчва най-новата налична версия на WSL. Ако вашата WSL е по-стара, актуализирайте я:

wsl --update

След това напълно спрете средата WSL 2:

wsl --shutdown

Microsoft посочва, че wsl --shutdown незабавно прекратява всички работещи дистрибуции и леката виртуална машина за поддръжка на WSL 2. Стартирайте Docker Desktop отново след спирането. Ако Windows или WSL са поискали рестартиране по време на актуализация, рестартирайте Windows, преди да тествате отново.

Полезно действие: изпълнете командите в този ред и запишете всеки точен код на грешка. Грешка от wsl --status е по-полезна диагностично от общото съобщение на Docker „Engine stopped“.

Често срещано недоразумение: преинсталирайте Ubuntu, за да поправите Docker Desktop

Docker Desktop не изисква конкретна Linux дистрибуция, инсталирана от потребителя. Документацията на Docker за WSL посочва, че командите на Docker могат да работят от Windows без инсталирана конкретна Linux дистрибуция; активирането на интеграция с WSL за Ubuntu, Debian или друга дистрибуция е по желание за работни процеси, родни за Linux.

Полезно действие: ако самата WSL се стартира правилно, не изтривайте работеща дистрибуция Ubuntu или Debian само за да поправите Docker Desktop.

Не използвайте wsl --unregister като ранна команда за поправка

Microsoft изрично предупреждава, че wsl --unregister <DistributionName> трайно премахва данните, настройките и инсталирания софтуер на тази дистрибуция. Командите, които регистрират отново Docker-свързани или лични WSL дистрибуции, следователно са разрушително отстраняване на неизправности, а не рутинни команди за рестартиране.

Полезно действие: използвайте първо wsl --shutdown. Направете резервно копие на важни данни преди всяка процедура за регистриране, нулиране, почистване или преинсталиране.

Фаза 3: Потвърдете виртуализацията на Windows и функциите на WSL

Илюстрация с AI на Windows Features с активирани Windows Subsystem for Linux и Virtual Machine Platform
Илюстрация на Windows Features, генерирана от AI. За WSL 2 се съсредоточете върху Windows Subsystem for Linux и Virtual Machine Platform; другите отметки могат да варират в зависимост от конфигурацията.

WSL 2 се нуждае от поддръжка на виртуализация. Microsoft посочва, че WSL 2 изисква функцията Virtual Machine Platform и хардуерна поддръжка на виртуализация. ЧЗВ на Microsoft за WSL също идентифицира два необходими компонента на Windows за WSL 2: Virtual Machine Platform и Windows Subsystem for Linux. Вижте ЧЗВ на Microsoft за WSL и ръчните стъпки за инсталация на WSL на Microsoft.

Отворете Turn Windows features on or off и проверете дали тези две функции са активирани:

  • Windows Subsystem for Linux
  • Virtual Machine Platform

Ако някоя от функциите е била деактивирана, активирайте я и рестартирайте Windows.

Често срещано недоразумение: пълният Hyper-V трябва да е активиран за Docker Desktop с WSL 2

Пълният клиентски 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.

Ако виждате грешка 0x80370102

Това е по-конкретна улика от „Engine stopped“. Страницата за отстраняване на неизправности на Microsoft за WSL посочва, че грешка 0x80370102 може да означава, че необходима функция за виртуализация не е налична. Microsoft препоръчва да проверите Virtual Machine Platform, виртуализацията в BIOS/UEFI, поддръжката на виртуализация на процесора и конфигурацията за стартиране на хипервизора.

В прозорец на PowerShell с повишени права можете да проверите настройката за стартиране на хипервизора:

bcdedit /enum | findstr -i hypervisorlaunchtype

Ако изрично докладва hypervisorlaunchtype Off, ръководството за отстраняване на неизправности на Microsoft посочва, че може да бъде активирано с:

bcdedit /set hypervisorlaunchtype Auto

Рестартирайте Windows след това. Вижте ръководството за отстраняване на неизправности на Microsoft за WSL.

Полезно действие: използвайте тази поправка на конфигурацията при стартиране само когато симптомите ви сочат към виртуализация или хипервизора. Не променяйте настройките за стартиране само защото Docker е бавен или един контейнер се е провалил.

Фаза 4: Проверете настройките на Docker, актуализирайте и съберете диагностика

Илюстрация с AI на менюто в системната област на Docker Desktop с опции Restart и Troubleshoot
Илюстрация на менюто в системната област на Docker Desktop, генерирана от AI; точното оформление на менюто може да се различава в различните версии на Docker Desktop.

Ако 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 контейнери.

Актуализирайте Docker Desktop

Използвайте секцията 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.

Полезно действие: запазете диагностичния ID и запишете точната грешка при стартиране, преди да нулирате нещо. Това доказателство е полезно, ако трябва да сравните логове, да потърсите текущ известен проблем или да отворите заявка за поддръжка.

Нулирайте Docker Desktop само след като направите резервно копие на данните

Менюто Troubleshoot на Docker включва 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 Desktop има смисъл

Преинсталирането е разумно след като сте установили, че:

  • Самата WSL е здрава и актуална.
  • Изискванията за виртуализация са изпълнени.
  • Нормално рестартиране на Docker Desktop все още се проваля.
  • Диагностиката не разкрива по-проста поправка на конфигурацията.
  • Важните локални данни на Docker са резервирани или са възпроизводими.

Използвайте текущия инсталатор от Docker, а не стар инсталатор, кеширан от предишен урок. Текущата документация на Docker за инсталация на Windows също разграничава режими на инсталация за отделен потребител и за всички потребители. Бекендът WSL 2 покрива повечето потребители, докато бекендът Hyper-V и Windows контейнерите имат различни изисквания за инсталация и привилегии.

Полезно действие: ако промените режима на инсталация или бекенда по време на преинсталиране, променяйте по една променлива наведнъж, за да можете да разберете какво всъщност е поправило проблема.

Какво ако Docker работи в Windows Terminal, но не и вътре в Ubuntu?

Това обикновено е въпрос на интеграция, а не доказателство, че двигателят на Docker е спрян. Docker посочва, че интеграцията с WSL може да бъде активирана за избрани WSL 2 дистрибуции под Settings > Resources > WSL Integration. Самата потребителска дистрибуция трябва да работи в режим WSL 2.

Проверете го с:

wsl -l -v

Ако потребителска дистрибуция все още е на WSL 1, Microsoft документира конвертирането с:

wsl --set-version <DistributionName> 2

Microsoft предупреждава, че конвертирането на големи дистрибуции може да отнеме време и да се провали, затова направете резервно копие на важни файлове преди голяма WSL конверсия.

Полезно действие: разграничете „демонът на Docker е спрян“ от „тази WSL дистрибуция не може да получи достъп до Docker“. Това са различни проблеми и не трябва да задействат една и същи стъпки за поправка.

Какво ако машината сама по себе си е виртуална машина?

Ако Windows 11 работи вътре във VMware, Hyper-V, Azure или друг хипервизор, WSL 2 може да изисква вложенa виртуализация – виртуализация, изложена през външната виртуална машина към гостуващия Windows. Microsoft документира изискванията за вложенa виртуализация и отбелязва, че поддръжката зависи от платформата и конфигурацията на хоста.

Полезно действие: ако това е корпоративен VDI или облачна виртуална машина, потвърдете поддръжката на вложенa виртуализация с администратора на платформата, преди да похарчите време за преинсталиране на Docker Desktop.

Безопасен ред за поправка, който можете да запазите

  1. Рестартирайте Docker Desktop и тествайте с docker version.
  2. Изпълнете wsl --version и wsl --status.
  3. Изпълнете wsl --update, след това wsl --shutdown и опитайте Docker отново.
  4. Ако самата WSL се провали, проверете Windows Subsystem for Linux, Virtual Machine Platform и виртуализацията в BIOS/UEFI.
  5. Ако имате грешка, специфична за виртуализацията, като 0x80370102, следвайте целевото отстраняване на неизправности на Microsoft за WSL.
  6. Ако WSL е здрава, проверете бекенда/режима на контейнерите на Docker и актуализирайте Docker Desktop.
  7. Съберете диагностични данни на Docker и прегледайте текущите бележки за версията.
  8. Направете резервно копие на важни данни преди операции за почистване, нулиране, регистриране или преинсталиране.

Заключение

„Docker Desktop Engine Stopped“ е симптом, а не единна диагноза. На Windows 11 с бекенда WSL 2, най-безопасният път за поправка е да рестартирате Docker, да проверите и актуализирате WSL, да потвърдите виртуализацията само ако WSL докладва свързан отказ, и да съберете диагностични данни на Docker, преди да използвате разрушителни опции за нулиране.

Двете най-важни грешки, които трябва да се избягват, са еднакво прости: не приемайте, че спрялата услуга на Docker за Windows е причината при всяка конфигурация с WSL 2, и не регистрирайте отново WSL дистрибуции или не нулирайте Docker до фабрични настройки, преди да направите резервно копие на данните. Тези стъпки могат да превърнат проблем при стартиране в проблем с загуба на данни, без да адресират първоначалната причина.

Оставете коментар

Как да поправите „CSS стиловете на Tailwind не се актуализират“ в приложение Vite React

Как да поправите „CSS стиловете на Tailwind не се актуализират“ в приложение Vite React

Поправете CSS стиловете на Tailwind, които не се актуализират във Vite React, като проверите настройката на Tailwind v4, CSS импортирането, откриването на източници, динамичните класове, HMR и остарелите кешове.

Как да се поправи ModuleNotFoundError: Няма модул с име „pip“ в Python 3

Как да се поправи ModuleNotFoundError: Няма модул с име „pip“ в Python 3

Поправете ModuleNotFoundError на Python 3 за pip на Windows, macOS и Linux с ensurepip, OS пакети, виртуални среди и проверки на интерпретатора.

Как да поправите грешката „Отказано разрешение (публичен ключ)“ в GitHub SSH

Как да поправите грешката „Отказано разрешение (публичен ключ)“ в GitHub SSH

Поправете отказан достъп до GitHub SSH (публичен ключ), като проверите хоста, активния SSH ключ, GitHub акаунта, SSO оторизацията, отдалечения URL адрес и достъпа до порт 22.

Как да поправите „Git Push Rejected: Non-FastForward“ без загуба на промени

Как да поправите „Git Push Rejected: Non-FastForward“ без загуба на промени

Поправете безопасно Git push, който не превърта напред. Защитете локалната работа, извлечете отдалечени коммити, изберете сливане или пребазиране, разрешите конфликти и push-вайте без загуба на промени.

Как да поправите грешката „Nginx 502 Bad Gateway“ при проксиране към Node.js

Как да поправите грешката „Nginx 502 Bad Gateway“ при проксиране към Node.js

Поправете грешките Nginx 502 Bad Gateway с Node.js upstream, като проверите порта на приложението, NGINX лог файловете, proxy_pass адреса, мрежата на контейнера, времето за изчакване и презареждането.

Как да поправим „Тип 'null' не може да се присвои на тип“ в TypeScript

Как да поправим „Тип 'null' не може да се присвои на тип“ в TypeScript

Поправете грешката на TypeScript „Тип 'null' не може да се присвоява на тип“ с типове обединения, стесняване, стойности по подразбиране и безопасни твърдения под strictNullChecks.

Как да поправите грешката „Prisma Client has not been generated yet“

Как да поправите грешката „Prisma Client has not been generated yet“

Поправете грешката за негенериран Prisma Client, като проверите генератора, схемата, изходния път, импортите, версиите, настройката на монорепо и стъпките за изграждане при внедряване.

Как да поправим "ERR_MODULE_NOT_FOUND" в Node.js ESM импортиране

Как да поправим "ERR_MODULE_NOT_FOUND" в Node.js ESM импортиране

Поправете Node.js ERR_MODULE_NOT_FOUND в ESM, като проверите пътищата за импортиране, файловите разширения, инсталирането на пакети, експортирането, ESM режима и чистите инсталации.

Как да поправите проблема със SSL сертификата: Unable to Get Local Issuer Certificate в Git

Как да поправите проблема със SSL сертификата: Unable to Get Local Issuer Certificate в Git

Поправете грешката на Git "unable to get local issuer certificate", като идентифицирате бекенда за доверие, инсталирате правилната CA верига и запазите SSL верификацията активирана.

Как да поправите грешката за изтичане на мрежовото време в Mongoose връзка с MongoDB

Как да поправите грешката за изтичане на мрежовото време в Mongoose връзка с MongoDB

Поправете грешките за изтичане на мрежовото време в Mongoose, като идентифицирате типа на таймаута, тествате достъпността на Atlas или TCP, коригирате URI и настройвате таймаутите само когато е оправдано.