Pirmiausia paleiskite iš naujo Docker Desktop ir WSL 2 virtualią mašiną – neperdiekite Docker ir neištrinkite jo WSL duomenų. Dabartinėse Windows konfigūracijose Docker Desktop dažniausiai naudoja WSL 2 posistemę, todėl pranešimas „Engine stopped“ (Variklis sustabdytas) gali reikšti Docker Desktop, WSL arba Windows virtualizacijos problemą. Greičiausias taisymo būdas – nustatyti, kuri sluoksnio dalis neveikia, prieš atliekant destruktyvius veiksmus.
2026 m. rugsėjo duomenimis, Docker Windows dokumentacija reikalauja WSL 2.1.5 arba naujesnės versijos WSL 2 posistemei ir rekomenduoja naudoti naujausią WSL versiją. Docker taip pat nurodo, kad WSL 2 yra numatytoji posistemė daugumai Windows vartotojų. „Microsoft“ dokumentuoja komandas wsl --version, wsl --status, wsl --update ir wsl --shutdown kaip standartines komandas WSL aplinkai tikrinti, atnaujinti ir paleisti iš naujo. Žr. Docker Windows diegimo reikalavimus, Docker WSL 2 posistemės dokumentaciją ir „Microsoft“ WSL komandų žinyną.
Šiame vadove naudojami keturi taisymo etapai, nuo saugiausio iki trikdžiančio. Sustokite, kai tik Docker vėl pradeda veikti.
| Ką matote | Naudingiausias kitas patikrinimas |
|---|---|
| Docker Desktop atsiveria, bet rodo, kad variklis sustabdytas | Paleiskite iš naujo Docker Desktop, tada patikrinkite Docker demoną |
Komandos wsl --status arba wsl --version nepavyksta | Prieš keisdami Docker duomenis, sutvarkykite arba atnaujinkite WSL |
| WSL praneša apie virtualizacijos arba būtinosios funkcijos klaidą | Patikrinkite Virtualios mašinos platformą ir BIOS/UEFI virtualizaciją |
| WSL veikia, bet Docker vis tiek nepaleidžiamas | Patikrinkite Docker Desktop nustatymus, atnaujinkite Docker ir surinkite diagnostikos duomenis |
| Problema prasidėjo iškart po atnaujinimo | Patikrinkite dabartinius Docker Desktop leidimo pastabas dėl atitinkamos Windows/WSL žinomos problemos |
Kas žinoma: šie sluoksniai priklauso vienas nuo kito. Kas nežinoma vien iš žodžių „Engine stopped“: kuris sluoksnis jūsų kompiuteryje sugedo. Paties pranešimo nepakanka, kad būtų pateisinamas gamyklinis atstatymas.
Pirmiausia naudokite Docker Desktop parinktį Troubleshoot > Restart Docker Desktop (Triktys > Paleisti iš naujo Docker Desktop). Docker dokumentuoja „Restart Docker Desktop“ kaip pirmąjį nedestruktyvų veiksmą savo Trikčių meniu. Versijose, kuriose yra Docker Desktop CLI, taip pat galite naudoti:
docker desktop status
docker desktop restartDabartinė Docker CLI nuoroda dokumentuoja status, start, stop ir restart komandas. Žr. Docker Desktop CLI dokumentaciją ir Docker Desktop trikčių šalinimo dokumentaciją.
Po Docker paleidimo iš naujo patikrinkite demoną:
docker version
docker infoJei docker version grąžina tiek kliento, tiek serverio informaciją, o ne demono ryšio klaidą, variklis vėl atsako.
Naudingas veiksmas: jei paleidimas iš naujo pavyko, sustokite čia. Neatstatykite WSL, neatregistruokite distribucijų ir neperdiekite Docker tik todėl, kad tai rekomenduoja kitas vadovėlis.
Tai nėra universalus sprendimas. Dabartinė Docker Windows leidimų dokumentacija teigia, kad WSL 2 Linux konteineriams privilegijuota pagalbė com.docker.service paprastai nėra būtina ir todėl nebūtinai paleidžiama automatiškai įkeliant sistemą. Ji būtina tokiems scenarijams kaip Windows konteineriai ir Hyper-V posistemė, taip pat gali būti naudojama tam tikroms privilegijuotoms pagrindinio kompiuterio failų operacijoms.
Taigi sustabdyta com.docker.service nėra įrodymas, kad WSL 2 Linux konteinerių diegimas yra sugadintas. Žr. Docker Windows leidimų reikalavimus.
Naudingas veiksmas: nustatykite, ar naudojate WSL 2 Linux konteinerius, prieš laikydami Windows tarnybą pagrindine priežastimi.
Atidarykite PowerShell arba Windows Terminal ir paleiskite:
wsl --version
wsl --status
wsl -l -vDocker šiuo metu reikalauja WSL 2.1.5 arba naujesnės versijos savo WSL 2 posistemei ir rekomenduoja naujausią prieinamą WSL leidimą. Jei jūsų WSL yra senesnė, atnaujinkite ją:
wsl --updateTada visiškai sustabdykite WSL 2 aplinką:
wsl --shutdown„Microsoft“ teigia, kad wsl --shutdown nedelsiant nutraukia visas veikiančias distribucijas ir WSL 2 lengvąją pagalbinę virtualią mašiną. Po sustabdymo vėl paleiskite Docker Desktop. Jei Windows arba WSL atnaujinimo metu prašė paleisti kompiuterį iš naujo, paleiskite Windows iš naujo prieš pakartotinai tikrindami.
Naudingas veiksmas: paleiskite komandas šia tvarka ir užfiksuokite tikslius klaidų kodus. Klaida iš wsl --status diagnostikai yra naudingesnė nei bendras Docker pranešimas „Engine stopped“.
Docker Desktop nereikalauja specifinės vartotojo įdiegtos Linux distribucijos. Docker WSL dokumentacija teigia, kad Docker komandos gali veikti iš Windows be specifinės Linux distribucijos; WSL integracijos įjungimas Ubuntu, Debian ar kitai distribucijai yra neprivalomas Linux natyviems darbo procesams.
Naudingas veiksmas: jei pats WSL paleidžiamas tinkamai, neištrinkite veikiančios Ubuntu ar Debian distribucijos vien tam, kad ištaisytumėte Docker Desktop.
„Microsoft“ aiškiai įspėja, kad wsl --unregister <DistributionName> negrįžtamai pašalina tos distribucijos duomenis, nustatymus ir įdiegtą programinę įrangą. Todėl komandos, atregistruojančios su Docker susijusias ar asmenines WSL distribucijas, yra destruktyvūs trikčių šalinimo veiksmai, o ne įprastos paleidimo iš naujo komandos.
Naudingas veiksmas: pirmiausia naudokite wsl --shutdown. Prieš bet kokį atregistravimą, atstatymą, valymą ar perdiegimą, atsargiai išsaugokite svarbius duomenis.
WSL 2 reikia virtualizacijos palaikymo. „Microsoft“ nurodo, kad WSL 2 reikalauja Virtualios mašinos platformos funkcijos ir aparatinės įrangos virtualizacijos palaikymo. „Microsoft“ WSL DUK taip pat nurodo du būtinus Windows komponentus WSL 2: Virtualią mašinos platformą ir Windows Linux posistemę. Žr. „Microsoft“ WSL DUK ir „Microsoft“ rankinius WSL diegimo veiksmus.
Atidarykite Įjungti arba išjungti Windows funkcijas ir įsitikinkite, kad šios dvi funkcijos yra įjungtos:
Jei kuri nors iš šių funkcijų buvo išjungta, įjunkite ją ir paleiskite Windows iš naujo.
Pilnas kliento Hyper-V nėra tas pats, kas virtualizacijos komponentai, kuriuos naudoja WSL 2. „Microsoft“ paaiškina, kad WSL 2 naudoja Hyper-V architektūros poaibį, pateikiamą per Virtualią mašinos platformą. Pilnas Hyper-V nėra prieinamas Windows Home versijoje, o WSL 2 yra palaikomas Windows Home versijoje, kurioje yra WSL. Docker taip pat traktuoja WSL 2 ir Hyper-V kaip atskiras posistemes.
Naudingas veiksmas: jei naudojate WSL 2 posistemę, pirmiausia patikrinkite WSL ir Virtualią mašinos platformą, o ne aklai įjunkite visus su Hyper-V susijusius langelius.
Tai yra konkretesnė užuomina nei „Engine stopped“. „Microsoft“ WSL trikčių šalinimo puslapis teigia, kad klaida 0x80370102 gali reikšti, kad būtina virtualizacijos funkcija nėra prieinama. „Microsoft“ rekomenduoja patikrinti Virtualią mašinos platformą, BIOS/UEFI virtualizaciją, CPU virtualizacijos palaikymą ir hipervizoriaus paleidimo konfigūraciją.
Padidintomis teisėmis veikiančiame PowerShell lange galite patikrinti hipervizoriaus paleidimo nustatymą:
bcdedit /enum | findstr -i hypervisorlaunchtypeJei jis aiškiai rodo hypervisorlaunchtype Off, „Microsoft“ trikčių šalinimo gairės teigia, kad jį galima įjungti naudojant:
bcdedit /set hypervisorlaunchtype AutoPo to paleiskite Windows iš naujo. Žr. „Microsoft“ WSL trikčių šalinimo vadovą.
Naudingas veiksmas: šį paleidimo konfigūracijos taisymą naudokite tik tada, kai simptomai rodo virtualizacijos arba hipervizoriaus problemas. Nekeiskite paleidimo nustatymų tik todėl, kad Docker veikia lėtai arba vienas konteineris nepavyko.
Jei WSL paleidžiamas normaliai, bet Docker Desktop vis tiek neveikia, grįžkite prie Docker sluoksnio.
Linux konteineriams Docker WSL dokumentacija teigia, kad Docker Desktop naudoja WSL 2 variklį, kai ta posistemė yra įjungta. Priklausomai nuo dabartinės Docker Desktop versijos ir palaikomos sistemos, nustatymas „Use WSL 2 based engine“ gali būti įjungtas numatytuoju būdu ir gali būti nematomas.
Jei Settings > Resources > WSL Integration (Nustatymai > Ištekliai > WSL integracija) nėra ir tikėjotės Linux konteinerių integracijos, Docker pažymi, kad Docker Desktop gali būti Windows konteinerių režime. Tokiu atveju, jei ketinate paleisti Linux konteinerius, persijunkite atgal į Linux konteinerius.
Naudingas veiksmas: nekeiskite konteinerių režimo kaip atsitiktinio trikčių šalinimo žingsnio. Patvirtinkite, ar jūsų projektas iš tikrųjų naudoja Linux, ar Windows konteinerius.
Naudokite Docker Desktop „Software updates“ (Programinės įrangos atnaujinimai) skiltį arba dabartinį diegiklį iš oficialaus Docker Windows diegimo puslapio. Docker leidimo pastabose dažnai būna Windows ir WSL specifinių pataisų bei žinomų problemų, todėl verta jas patikrinti, kai problema prasideda iškart po atnaujinimo. Žr. Docker Desktop leidimo pastabas.
Naudingas veiksmas: prieš atnaujindami užsirašykite dabartines Docker Desktop ir WSL versijas. Jei nesenoje leidimo pastaboje aprašytas jūsų tikslus simptomas, laikykitės dokumentuoto apėjimo būdo, o ne taikykite nesusijusius registro ar WSL trynimo komandas.
Docker Desktop Trikčių meniu gali surinkti diagnostikos informaciją net tada, kai programa turi paleidimo problemų. Docker taip pat dokumentuoja:
docker desktop diagnoseDocker Desktop CLI dokumentacija teigia, kad diagnose komanda yra prieinama nuo Docker Desktop 4.60 versijos. Jei jūsų įdiegta versija nepalaiko tos komandos, vietoj jos naudokite Trikčių sąsają arba dokumentuotą Docker com.docker.diagnose vykdomąjį kelią.
Naudingas veiksmas: prieš atstatydami bet ką, išsaugokite diagnostikos ID ir užfiksuokite tikslią paleidimo klaidą. Tie įrodymai yra naudingi, jei turėsite palyginti žurnalus, ieškoti dabartinės žinomos problemos arba atidaryti palaikymo užklausą.
Docker Trikčių meniu yra parinktys Clean up data (Išvalyti duomenis) ir Reset to factory defaults (Atstatyti gamyklinius nustatymus). Tai yra paskutinės priemonės, o ne įprasti taisymai. Docker atsarginių kopijų dokumentacija rekomenduoja atsargiai išsaugoti svarbius atvaizdus, tomus ir Docker Desktop VM duomenis prieš perdiegiant arba atstatant, kai Docker Desktop negali normaliai paleisti. Žr. Docker atsarginių kopijų ir atkūrimo vadovą.
Kai demonas vis dar pakankamai veikia, kad būtų galima naudoti Docker komandas, prieš atstatymą išsaugokite tai, kas svarbu. Pavyzdžiui, svarbius atvaizdus galima įkelti į registrą arba išsaugoti tar archyve. Tomų duomenims reikia savo atsarginės kopijos strategijos.
Jei Docker Desktop visai nepaleidžiamas, Docker dokumentuoja Windows procedūrą Docker Desktop virtualiam diskui atsargiai išsaugoti prieš perdiegiant. Laikykitės dabartinio oficialaus kelio iš atsarginių kopijų vadovo, nes Docker vidinė saugyklos struktūra gali keistis tarp leidimų.
Naudingas veiksmas: nespauskite „Reset to factory defaults“, kol negalite atsakyti: „Kur yra vienintelė mano svarbių tomų duomenų kopija?“
Perdiegimas yra pagrįstas, kai nustatėte, kad:
Naudokite dabartinį diegiklį iš Docker, o ne seną diegiklį, saugotą iš ankstesnio vadovėlio. Dabartinė Docker Windows diegimo dokumentacija taip pat skiria vartotojo ir visų vartotojų diegimo režimus. WSL 2 posistemė apima daugumą vartotojų, o Hyper-V posistemė ir Windows konteineriai turi skirtingus diegimo ir privilegijų reikalavimus.
Naudingas veiksmas: jei perdiegimo metu keičiate diegimo režimą arba posistemę, keiskite po vieną kintamąjį, kad galėtumėte pasakyti, kas iš tikrųjų išsprendė problemą.
Tai paprastai yra integracijos klausimas, o ne įrodymas, kad Docker variklis sustabdytas. Docker teigia, kad WSL integraciją galima įjungti pasirinktoms WSL 2 distribucijoms per Settings > Resources > WSL Integration. Pati vartotojo distribucija turi veikti WSL 2 režimu.
Patikrinkite tai naudodami:
wsl -l -vJei vartotojo distribucija vis dar yra WSL 1, „Microsoft“ dokumentuoja konvertavimą naudojant:
wsl --set-version <DistributionName> 2„Microsoft“ įspėja, kad didelių distribucijų konvertavimas gali užtrukti ir gali nepavykti, todėl prieš didelį WSL konvertavimą atsargiai išsaugokite svarbius failus.
Naudingas veiksmas: atskirkite „Docker demonas neveikia“ nuo „ši WSL distribucija negali pasiekti Docker“. Tai yra skirtingos problemos ir jos neturėtų sukelti tų pačių taisymo veiksmų.
Jei Windows 11 veikia VMware, Hyper-V, Azure ar kitoje hipervizoriaus aplinkoje, WSL 2 gali reikalauti įdėtinės virtualizacijos – virtualizacijos, perduodamos per išorinę virtualią mašiną Windows svečiui. „Microsoft“ dokumentuoja įdėtinės virtualizacijos reikalavimus ir pažymi, kad palaikymas priklauso nuo pagrindinės platformos ir konfigūracijos.
Naudingas veiksmas: jei tai įmonės VDI arba debesies VM, prieš gaišdami laiką perdiegdami Docker Desktop, pasitarkite su platformos administratoriumi dėl įdėtinės virtualizacijos palaikymo.
docker version.wsl --version ir wsl --status.wsl --update, tada wsl --shutdown ir bandykite Docker iš naujo.0x80370102, laikykitės „Microsoft“ tikslinės WSL trikčių šalinimo gairės.„Docker Desktop Engine Stopped“ yra simptomas, o ne viena diagnozė. Windows 11 su WSL 2 posisteme saugiausias taisymo kelias yra paleisti iš naujo Docker, patikrinti ir atnaujinti WSL, patvirtinti virtualizaciją tik jei WSL praneša apie susijusią nesėkmę, ir surinkti Docker diagnostikos duomenis prieš naudojant destruktyvias atstatymo parinktis.
Dvi svarbiausios klaidos, kurių reikia vengti, yra vienodai paprastos: nedarykite prielaidos, kad sustabdyta Windows Docker tarnyba yra priežastis kiekvienoje WSL 2 konfigūracijoje, ir neatregistruokite WSL distribucijų ar neatstatykite Docker gamykliniais nustatymais prieš atsargiai išsaugoję duomenis. Šie veiksmai gali paversti paleidimo problemą duomenų praradimo problema, neišsprendžiant pradinės priežasties.
Ištaisykite „Prisma Client“ nesugeneravimo klaidą patikrinę generatorių, schemą, išvesties kelią, importus, versijas, monorepo sąranką ir diegimo kūrimo veiksmus.
Ištaisykite Git klaidą „unable to get local issuer certificate“ nustatydami pasitikėjimo šaltinį, įdiegdami tinkamą CA grandinę ir palikdami įjungtą SSL patikrą.
Ištaisykite MongoDB tinklo laiko limito klaidas Mongoose nustatydami laiko limito tipą, patikrindami Atlas arba TCP pasiekiamumą, koreguodami URI ir tikslindami laiko limitus tik tada, kai tai pagrįsta.
Ištaisykite PowerShell vykdymo politikos „Restricted“ klaidą patikrindami sritį ir grupės politiką, tada pasirinkdami RemoteSigned, Unblock-File arba laikiną sesijos parinktį.
Ištaisykite npm ERESOLVE peer dependency konfliktus nustatydami nesuderinamą paketo diapazoną, suderindami versijas, naudodami komandas npm explain ir npm ls, bei laikydami legacy-peer-deps arba force tik kontroliuojamais atsarginiais variantais.
Ištaisykite Redis prisijungimo atmetimo klaidas adresu 127.0.0.1:6379 tikrindami serverį, prievadą, Docker tinklą, redis.conf, autentifikaciją ir TLS.
Ištaisykite Next.js Server Component 500 klaidas stebėdami serverio žurnalus, tikrindami duomenų gavimą ir aplinkos kintamuosius, apdorodami klaidas ir patikrindami gamybinį sukūrimą.
Diagnozuokite ir ištaisykite Kubernetes CrashLoopBackOff klaidą vietiniame Minikube tikrindami pod būseną, ankstesnius žurnalus, išėjimo priežastis, zondas, konfigūraciją, atminties apribojimus ir klasterio sveikatą.
Ištaisykite „Docker Desktop Engine Stopped“ klaidą sistemoje Windows 11 tikrindami Docker būseną, atnaujindami ir paleisdami iš naujo WSL 2, tikrindami virtualizaciją bei naudodami diagnostiką prieš atstatymą.
Ištaisykite Vite klaidą „process is not defined“ pakeisdami Node stiliaus process.env naudojimą, teisingai sukonfigūruodami VITE_ kintamuosius ir patikrindami priklausomybes.
