Sākums
» Pamatzināšanas
»
Kā novērst Docker Desktop dzinēja apstāšanos sistēmā Windows 11
Kā novērst Docker Desktop dzinēja apstāšanos sistēmā Windows 11
Sāciet ar Docker Desktop un WSL 2 virtuālās mašīnas restartēšanu – nevis ar Docker pārinstalēšanu vai tā WSL datu dzēšanu. Pašreizējās Windows iestatījumos Docker Desktop parasti izmanto WSL 2 aizmugursistēmu, tāpēc ziņojums “Engine stopped” (Dzinējs apstājies) var norādīt uz Docker Desktop problēmu, WSL problēmu vai Windows virtualizācijas problēmu. Ātrākais remonta ceļš ir noteikt, kurš slānis nedarbojas, pirms veicat destruktīvas izmaiņas.
Līdz 2026. gada septembrim Docker Windows dokumentācija WSL 2 aizmugursistēmai pieprasa WSL 2.1.5 vai jaunāku versiju un iesaka izmantot jaunāko WSL versiju. Docker arī apraksta WSL 2 kā noklusējuma aizmugursistēmu lielākajai daļai Windows lietotāju. Microsoft dokumentē komandas wsl --version, wsl --status, wsl --update un wsl --shutdown kā standarta komandas WSL vides pārbaudei, atjaunināšanai un restartēšanai. Skatiet Docker Windows instalēšanas prasības, Docker WSL 2 aizmugursistēmas dokumentāciju un Microsoft WSL komandu atsauces dokumentāciju.
Šajā rokasgrāmatā ir izmantoti četri remonta posmi, sākot no drošākā līdz vistraucējošākajam. Pārtrauciet darbību, tiklīdz Docker atkal darbojas.
Vispirms nosakiet, kurš slānis patiesībā nedarbojas
Ko jūs redzat
Lietderīgākā nākamā pārbaude
Docker Desktop atveras, bet norāda, ka dzinējs ir apstājies
Restartējiet Docker Desktop, pēc tam pārbaudiet Docker dēmonu
wsl --status vai wsl --version neizdodas
Pirms Docker datu mainīšanas, labojiet vai atjauniniet WSL
WSL ziņo par virtualizācijas vai nepieciešamās funkcijas kļūdu
Pārbaudiet virtuālās mašīnas platformu un BIOS/UEFI virtualizāciju
WSL darbojas, bet Docker joprojām nevar sākt darbu
Pārbaudiet Docker Desktop iestatījumus, atjauniniet Docker un vāciet diagnostikas datus
Problēma sākās uzreiz pēc atjauninājuma
Pārbaudiet pašreizējās Docker Desktop izlaiduma piezīmes, lai atrastu atbilstošu Windows/WSL zināmo problēmu
Kas ir zināms: šie slāņi ir savstarpēji atkarīgi. Kas nav zināms tikai no frāzes “Engine stopped”: kurš slānis jūsu datorā nedarbojās. Pats ziņojums nav pietiekams pamats rūpnīcas atiestatīšanai.
1. posms: Restartējiet Docker Desktop un pārbaudiet dēmonu
AI ģenerēta ilustrācija par Docker Desktop dzinēja apstāšanās ekrānu. Tā nav īsta Docker Desktop ekrānuzņēmuma kopija, un precīzs saskarnes teksts var atšķirties atkarībā no versijas.
Vispirms izmantojiet Docker Desktop opciju Troubleshoot > Restart Docker Desktop (Diagnostics > Restart Docker Desktop). Docker dokumentācijā Restart Docker Desktop ir norādīts kā pirmā nedestruktīvā darbība tā Troubleshoot izvēlnē. Versijās, kurās ir iekļauts Docker Desktop CLI, varat izmantot arī:
Ja docker version atgriež gan klienta, gan servera informāciju, nevis dēmona savienojuma kļūdu, dzinējs atkal atbild.
Noderīga darbība: ja restartēšana izdodas, apstājieties šeit. Neatjaunojiet WSL, nereģistrējiet distribūcijas un nepārinstalējiet Docker tikai tāpēc, ka kāds cits ceļvedis to iesaka.
Bieži sastopama pārpratums: restartēt com.docker.service katras Engine Stopped kļūdas gadījumā
Tas nav universāls risinājums. Docker pašreizējā Windows atļauju dokumentācija nosaka, ka WSL 2 Linux konteineriem privilēģiju palīgdienests com.docker.service parasti nav nepieciešams un tāpēc tas ne vienmēr automātiski startējas sāknēšanas laikā. Tas ir nepieciešams tādos scenārijos kā Windows konteineri un Hyper-V aizmugursistēma, un to var izmantot arī noteiktām privilēģiju saistītām saimniekdatora failu darbībām.
Tātad apstājies com.docker.service nav pierādījums, ka WSL 2 Linux konteineru instalācija ir bojāta. Skatiet Docker Windows atļauju prasības.
Noderīga darbība: nosakiet, vai izmantojat WSL 2 Linux konteinerus, pirms uzskatāt Windows pakalpojumu par pamatcēloni.
2. posms: Pārbaudiet un restartējiet WSL 2
AI ģenerēta komandrindas ilustrācija. Rādītie versiju numuri ir ilustratīvi; izmantojiet komandas savā datorā, lai iegūtu reālās vērtības.
Atveriet PowerShell vai Windows Terminal un palaidiet:
wsl --version
wsl --status
wsl -l -v
Docker pašlaik savai WSL 2 aizmugursistēmai pieprasa WSL 2.1.5 vai jaunāku versiju un iesaka jaunāko pieejamo WSL izlaidumu. Ja jūsu WSL versija ir vecāka, atjauniniet to:
wsl --update
Pēc tam pilnībā apturiet WSL 2 vidi:
wsl --shutdown
Microsoft norāda, ka wsl --shutdown nekavējoties pārtrauc visu palaisto distribūciju un WSL 2 vieglo palīgprogrammu virtuālās mašīnas darbību. Pēc apturēšanas vēlreiz startējiet Docker Desktop. Ja Windows vai WSL atjauninājuma laikā pieprasīja restartēšanu, restartējiet Windows pirms atkārtotas pārbaudes.
Noderīga darbība: palaidiet komandas šādā secībā un ierakstiet jebkuru precīzu kļūdas kodu. Kļūda no wsl --status ir diagnostiski noderīgāka nekā vispārīgais Docker ziņojums “Engine stopped”.
Bieži sastopama pārpratums: Ubuntu pārinstalēšana, lai labotu Docker Desktop
Docker Desktop neprasa konkrētu lietotāja instalētu Linux distribūciju. Docker WSL dokumentācija nosaka, ka Docker komandas var darboties no Windows bez konkrētas Linux distribūcijas instalēšanas; WSL integrācijas iespējošana Ubuntu, Debian vai citai distribūcijai ir pēc izvēles Linux dabiskajiem darba plūsmām.
Noderīga darbība: ja WSL pats startējas pareizi, nedzēsiet darbspējīgu Ubuntu vai Debian distribūciju tikai tāpēc, lai labotu Docker Desktop.
Nekavējieties lietot wsl --unregister kā agrīnu remonta komandu
Microsoft skaidri brīdina, ka wsl --unregister <DistributionName> neatgriezeniski noņem šīs distribūcijas datus, iestatījumus un instalēto programmatūru. Komandas, kas atreģistrē ar Docker saistītas vai personiskas WSL distribūcijas, tādējādi ir destruktīva problēmu novēršana, nevis rutīnas restarta komandas.
Noderīga darbība: vispirms izmantojiet wsl --shutdown. Izveidojiet svarīgo datu rezerves kopijas pirms jebkuras atreģistrēšanas, atiestatīšanas, tīrīšanas vai pārinstalēšanas procedūras.
3. posms: Pārbaudiet Windows virtualizāciju un WSL funkcijas
AI ģenerēta Windows funkciju ilustrācija. WSL 2 gadījumā pievērsiet uzmanību Windows Subsystem for Linux un Virtual Machine Platform; citas izvēles rūtiņas var atšķirties atkarībā no konfigurācijas.
WSL 2 ir nepieciešams virtualizācijas atbalsts. Microsoft norāda, ka WSL 2 pieprasa funkciju Virtual Machine Platform (Virtuālās mašīnas platforma) un aparatūras virtualizācijas atbalstu. Microsoft WSL BUJ arī norāda divas nepieciešamās Windows komponentes WSL 2: Virtual Machine Platform un Windows Subsystem for Linux. Skatiet Microsoft WSL BUJ un Microsoft manuālās WSL instalēšanas darbības.
Atveriet Turn Windows features on or off (Ieslēgt vai izslēgt Windows funkcijas) un pārliecinieties, vai šīs divas funkcijas ir iespējotas:
Windows Subsystem for Linux
Virtual Machine Platform
Ja kāda no šīm funkcijām bija atspējota, iespējojiet to un restartējiet Windows.
Bieži sastopama pārpratums: pilns Hyper-V ir jāiespējo Docker Desktop ar WSL 2
Pilns klienta Hyper-V nav tas pats, kas virtualizācijas komponentes, ko izmanto WSL 2. Microsoft skaidro, ka WSL 2 izmanto Hyper-V arhitektūras apakškopu, kas nodrošināta caur Virtual Machine Platform. Pilns Hyper-V nav pieejams Windows Home, savukārt WSL 2 ir atbalstīts Windows Home, kur WSL ir pieejams. Docker arī uzskata WSL 2 un Hyper-V par atsevišķām aizmugursistēmām.
Noderīga darbība: ja izmantojat WSL 2 aizmugursistēmu, vispirms pārbaudiet WSL un Virtual Machine Platform, nevis aklām iespējojot visas ar Hyper-V saistītās izvēles rūtiņas.
Ja redzat kļūdu 0x80370102
Tas ir konkrētāks norādes punkts nekā “Engine stopped”. Microsoft WSL problēmu novēršanas lapa nosaka, ka kļūda 0x80370102 var nozīmēt, ka nepieciešamā virtualizācijas funkcija nav pieejama. Microsoft iesaka pārbaudīt Virtual Machine Platform, BIOS/UEFI virtualizāciju, CPU virtualizācijas atbalstu un hipervizora starta konfigurāciju.
Paaugstinātu privilēģiju PowerShell logā varat pārbaudīt hipervizora starta iestatījumu:
bcdedit /enum | findstr -i hypervisorlaunchtype
Ja tas skaidri ziņo hypervisorlaunchtype Off, Microsoft problēmu novēršanas norādījumi nosaka, ka to var iespējot ar:
Noderīga darbība: izmantojiet šo sāknēšanas konfigurācijas labojumu tikai tad, ja jūsu simptomi norāda uz virtualizāciju vai hipervizoru. Nemainiet sāknēšanas iestatījumus tikai tāpēc, ka Docker ir lēns vai viens konteiners nav izdevies.
4. posms: Pārbaudiet Docker iestatījumus, atjauniniet un vāciet diagnostiku
AI ģenerēta Docker Desktop sistēmas teknes izvēlnes ilustrācija; precīzs izvēlnes izkārtojums var atšķirties dažādās Docker Desktop versijās.
Ja WSL startējas normāli, bet Docker Desktop joprojām nedarbojas, atgriezieties pie Docker slāņa.
Pārliecinieties, vai izmantojat paredzēto aizmugursistēmu
Linux konteineriem Docker WSL dokumentācija nosaka, ka Docker Desktop izmanto WSL 2 dzinēju, kad šī aizmugursistēma ir iespējota. Atkarībā no pašreizējās Docker Desktop versijas un atbalstītās sistēmas iestatījums “Use WSL 2 based engine” var būt iespējots pēc noklusējuma un var nebūt redzams.
Ja Settings > Resources > WSL Integration (Iestatījumi > Resursi > WSL integrācija) nav pieejams un jūs gaidījāt Linux konteineru integrāciju, Docker norāda, ka Docker Desktop var būt Windows konteineru režīmā. Šādā situācijā pārslēdzieties atpakaļ uz Linux konteineriem, ja tieši Linux konteinerus plānojat palaist.
Noderīga darbība: nemainiet konteineru režīmu tikai kā nejaušu problēmu novēršanas soli. Pārliecinieties, vai jūsu projekts patiešām izmanto Linux vai Windows konteinerus.
Atjauniniet Docker Desktop
Izmantojiet Docker Desktop Software updates (Programmatūras atjauninājumi) sadaļu vai pašreizējo instalētāju no Docker oficiālās Windows instalēšanas lapas. Docker izlaiduma piezīmes bieži satur Windows un WSL specifiskus labojumus un zināmās problēmas, tāpēc tās ir vērts pārbaudīt, ja problēma sākas uzreiz pēc jaunināšanas. Skatiet Docker Desktop izlaiduma piezīmes.
Noderīga darbība: pirms atjaunināšanas pierakstiet savu pašreizējo Docker Desktop un WSL versiju. Ja nesenā izlaiduma piezīmē ir aprakstīts jūsu precīzais simptoms, sekojiet dokumentētajam apbraukšanas veidam, nevis piemērojiet nesaistītus reģistra vai WSL dzēšanas komandas.
Veiciet diagnostiku pirms rūpnīcas atiestatīšanas
Docker Desktop Troubleshoot izvēlne var vākt diagnostikas informāciju pat tad, ja lietojumprogrammai ir starta problēmas. Docker arī dokumentē:
docker desktop diagnose
Docker Desktop CLI dokumentācija nosaka, ka diagnose komanda ir pieejama ar Docker Desktop 4.60 un jaunākām versijām. Ja jūsu instalētā versija neatbalsta šo komandu, izmantojiet Troubleshoot interfeisu vai Docker dokumentēto com.docker.diagnose izpildāmo ceļu.
Noderīga darbība: saglabājiet diagnostikas ID un fiksējiet precīzu starta kļūdu pirms kaut kā atiestatīšanas. Šie pierādījumi ir noderīgi, ja jums ir jāsalīdzina žurnāli, jāmeklē pašreizējā zināmā problēma vai jāatver atbalsta pieteikums.
Atiestatiet Docker Desktop tikai pēc datu rezerves kopijas izveides
Docker Troubleshoot izvēlnē ir iekļautas opcijas Clean up data (Notīrīt datus) un Reset to factory defaults (Atiestatīt uz rūpnīcas noklusējuma iestatījumiem). Tās ir pēdējās iespējas, nevis rutīnas labojumi. Docker rezerves kopiju dokumentācija iesaka izveidot svarīgo attēlu, tilpumu un Docker Desktop VM datu rezerves kopijas pirms pārinstalēšanas vai atiestatīšanas, ja Docker Desktop nevar startēt normāli. Skatiet Docker rezerves kopiju un atjaunošanas rokasgrāmatu.
Kad dēmons joprojām darbojas pietiekami labi, lai izmantotu Docker komandas, pirms atiestatīšanas saglabājiet to, kas ir svarīgs. Piemēram, svarīgos attēlus var augšupielādēt reģistrā vai saglabāt tar arhīvā. Tilpumu datiem ir nepieciešama sava rezerves kopiju stratēģija.
Ja Docker Desktop vispār nevar startēt, Docker dokumentē Windows procedūru Docker Desktop virtuālā diska rezerves kopijas izveidei pirms pārinstalēšanas. Sekojiet pašreizējam oficiālajam ceļam no rezerves kopiju rokasgrāmatas, jo Docker iekšējā glabāšanas izkārtojums var mainīties starp izlaidumiem.
Noderīga darbība: neklikšķiniet uz Reset to factory defaults, līdz varat atbildēt: “Kur atrodas vienīgā mana svarīgā tilpuma datu kopija?”
Kad Docker Desktop pārinstalēšana ir pamatota
Pārinstalēšana ir saprātīga pēc tam, kad esat noskaidrojuši, ka:
WSL pats ir vesels un atjaunināts.
Virtualizācijas prasības ir izpildītas.
Parasta Docker Desktop restartēšana joprojām neizdodas.
Svarīgie vietējie Docker dati ir dublēti vai tos var atjaunot.
Izmantojiet pašreizējo instalētāju no Docker, nevis vecu instalētāju, kas saglabāts no iepriekšēja ceļveža. Docker pašreizējā Windows instalēšanas dokumentācija arī atšķir per-user (katram lietotājam) un all-users (visiem lietotājiem) instalēšanas režīmus. WSL 2 aizmugursistēma aptver lielāko daļu lietotāju, savukārt Hyper-V aizmugursistēmai un Windows konteineriem ir atšķirīgas instalēšanas un privilēģiju prasības.
Noderīga darbība: ja pārinstalēšanas laikā maināt instalēšanas režīmu vai aizmugursistēmu, mainiet vienu mainīgo vienlaikus, lai varētu noteikt, kas patiesībā atrisināja problēmu.
Ko darīt, ja Docker darbojas Windows Terminal, bet ne Ubuntu iekšienē?
Tas parasti ir integrācijas jautājums, nevis pierādījums, ka Docker dzinējs ir apstājies. Docker nosaka, ka WSL integrāciju var iespējot atlasītām WSL 2 distribūcijām sadaļā Settings > Resources > WSL Integration. Lietotāja distribūcijai pašai ir jādarbojas WSL 2 režīmā.
Pārbaudiet to ar:
wsl -l -v
Ja lietotāja distribūcija joprojām ir WSL 1, Microsoft dokumentē konvertāciju ar:
wsl --set-version <DistributionName> 2
Microsoft brīdina, ka lielu distribūciju konvertēšana var aizņemt laiku un var neizdoties, tāpēc pirms lielas WSL konvertācijas izveidojiet svarīgo failu rezerves kopijas.
Noderīga darbība: atšķiriet “Docker dēmons ir apturēts” no “šī WSL distribūcija nevar piekļūt Docker”. Tie ir dažādi jautājumi, un tiem nevajadzētu izraisīt tādus pašus remonta soļus.
Ko darīt, ja mašīna pati ir virtuāla mašīna?
Ja Windows 11 darbojas VMware, Hyper-V, Azure vai citā hipervizorā, WSL 2 var pieprasīt ligzdotu virtualizāciju – virtualizāciju, kas caur ārējo virtuālo mašīnu tiek nodota Windows viesim. Microsoft dokumentē ligzdotās virtualizācijas prasības un norāda, ka atbalsts ir atkarīgs no saimniekdatora platformas un konfigurācijas.
Noderīga darbība: ja tas ir korporatīvs VDI vai mākoņa VM, pirms laika tērēšanas Docker Desktop pārinstalēšanai, apstipriniet ligzdotās virtualizācijas atbalstu ar platformas administratoru.
Droša remonta secība, ko varat paturēt
Restartējiet Docker Desktop un pārbaudiet ar docker version.
Palaidiet wsl --version un wsl --status.
Palaidiet wsl --update, pēc tam wsl --shutdown un mēģiniet Docker vēlreiz.
Ja WSL pats neizdodas, pārbaudiet Windows Subsystem for Linux, Virtual Machine Platform un BIOS/UEFI virtualizāciju.
Ja jums ir virtualizācijai specifiska kļūda, piemēram, 0x80370102, sekojiet Microsoft mērķtiecīgajai WSL problēmu novēršanai.
Ja WSL ir vesels, pārbaudiet Docker aizmugursistēmu/konteineru režīmu un atjauniniet Docker Desktop.
Vāciet Docker diagnostiku un pārskatiet pašreizējās izlaiduma piezīmes.
Izveidojiet svarīgo datu rezerves kopijas pirms tīrīšanas, atiestatīšanas, atreģistrēšanas vai pārinstalēšanas darbībām.
Secinājums
“Docker Desktop Engine Stopped” ir simptoms, nevis vienota diagnoze. Sistēmā Windows 11 ar WSL 2 aizmugursistēmu drošākais remonta ceļš ir restartēt Docker, pārbaudīt un atjaunināt WSL, apstiprināt virtualizāciju tikai tad, ja WSL ziņo par saistītu kļūmi, un vākt Docker diagnostiku pirms destruktīvu atiestatīšanas opciju izmantošanas.
Divas svarīgākās kļūdas, no kurām izvairīties, ir tikpat vienkāršas: neuzskatiet, ka apstājies Windows Docker pakalpojums ir cēlonis katrā WSL 2 iestatījumā, un neatreģistrējiet WSL distribūcijas vai neveiciet Docker rūpnīcas atiestatīšanu pirms datu dublēšanas. Šie soļi var pārvērst starta problēmu par datu zaudēšanas problēmu, neaizskārot sākotnējo cēloni.