Начало
» Основни познания
»
Как да поправите Docker Desktop Engine Stopped на Windows 11
Как да поправите 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. Това не е реален екранен запис на Docker Desktop, а точният текст на интерфейса може да варира в зависимост от версията.
Използвайте опцията Troubleshoot > Restart Docker Desktop на Docker Desktop първо. Docker документира Restart Docker Desktop като първото неразрушително действие в менюто Troubleshoot. На версии, които включват CLI на Docker Desktop, можете също да използвате:
Ако docker version връща информация както за клиента, така и за сървъра, вместо грешка при свързване с демона, двигателят отново отговаря.
Полезно действие: ако рестартирането проработи, спрете тук. Не нулирайте WSL, не регистрирайте отново дистрибуции и не преинсталирайте Docker само защото друг урок го препоръчва.
Често срещано недоразумение: рестартирайте com.docker.service за всяка грешка Engine Stopped
Това не е универсално решение. Текущата документация на Docker за разрешенията в Windows посочва, че за Linux контейнери с WSL 2, привилегираният помощник com.docker.service не е общо взето необходим и следователно не се стартира автоматично при зареждане. Той е необходим за сценарии като Windows контейнери и бекенда Hyper-V, и може да се използва и за определени привилегирани операции с файлове на хоста.
Полезно действие: определете дали използвате Linux контейнери с WSL 2, преди да третирате услугата на Windows като основна причина.
Фаза 2: Проверете и рестартирайте WSL 2
Илюстрация на команден ред, генерирана от 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
Илюстрация на 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 посочва, че може да бъде активирано с:
Полезно действие: използвайте тази поправка на конфигурацията при стартиране само когато симптомите ви сочат към виртуализация или хипервизора. Не променяйте настройките за стартиране само защото Docker е бавен или един контейнер се е провалил.
Фаза 4: Проверете настройките на Docker, актуализирайте и съберете диагностика
Илюстрация на менюто в системната област на 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.
Безопасен ред за поправка, който можете да запазите
Рестартирайте Docker Desktop и тествайте с docker version.
Изпълнете wsl --version и wsl --status.
Изпълнете wsl --update, след това wsl --shutdown и опитайте Docker отново.
Ако самата WSL се провали, проверете Windows Subsystem for Linux, Virtual Machine Platform и виртуализацията в BIOS/UEFI.
Ако имате грешка, специфична за виртуализацията, като 0x80370102, следвайте целевото отстраняване на неизправности на Microsoft за WSL.
Ако WSL е здрава, проверете бекенда/режима на контейнерите на Docker и актуализирайте Docker Desktop.
Съберете диагностични данни на Docker и прегледайте текущите бележки за версията.
Направете резервно копие на важни данни преди операции за почистване, нулиране, регистриране или преинсталиране.
Заключение
„Docker Desktop Engine Stopped“ е симптом, а не единна диагноза. На Windows 11 с бекенда WSL 2, най-безопасният път за поправка е да рестартирате Docker, да проверите и актуализирате WSL, да потвърдите виртуализацията само ако WSL докладва свързан отказ, и да съберете диагностични данни на Docker, преди да използвате разрушителни опции за нулиране.
Двете най-важни грешки, които трябва да се избягват, са еднакво прости: не приемайте, че спрялата услуга на Docker за Windows е причината при всяка конфигурация с WSL 2, и не регистрирайте отново WSL дистрибуции или не нулирайте Docker до фабрични настройки, преди да направите резервно копие на данните. Тези стъпки могат да превърнат проблем при стартиране в проблем с загуба на данни, без да адресират първоначалната причина.