Slik fikser du at Docker Desktop-motoren stopper på Windows 11

Begynn med å starte Docker Desktop og WSL 2 virtuelle maskin på nytt – ikke ved å reinstallere Docker eller slette WSL-dataene dens. På gjeldende Windows-oppsett bruker Docker Desktop vanligvis WSL 2-backend, så en melding om «Engine stopped» kan være et Docker Desktop-problem, et WSL-problem eller et Windows-virtualiseringsproblem. Den raskeste reparasjonsveien er å identifisere hvilket lag som feiler før du gjør destruktive endringer.

Per september 2026 krever Docker's Windows-dokumentasjon WSL 2.1.5 eller nyere for WSL 2-backend og anbefaler å bruke den nyeste WSL-versjonen. Docker beskriver også WSL 2 som standardbackend for de fleste Windows-brukere. Microsoft dokumenterer wsl --version, wsl --status, wsl --update og wsl --shutdown som standardkommandoer for å sjekke, oppdatere og starte WSL-miljøet på nytt. Se Docker's Windows-installasjonskrav, Docker's WSL 2 backend-dokumentasjon og Microsoft's WSL-kommandoreferanse.

Denne veiledningen bruker fire reparasjonsfaser, fra tryggest til mest forstyrrende. Stopp så snart Docker fungerer igjen.

Først, identifiser hvilket lag som faktisk feiler

Hva som er kjent: disse lagene er avhengige av hverandre. Hva som ikke er kjent fra ordene «Engine stopped» alene: hvilket lag som feilet på PC-en din. Meldingen i seg selv er ikke nok til å rettferdiggjøre en fabrikknullstilling.

Fase 1: Start Docker Desktop på nytt og verifiser daemonen

Bruk Docker Desktops Troubleshoot > Restart Docker Desktop-alternativ først. Docker dokumenterer Restart Docker Desktop som den første ikke-destruktive handlingen i Troubleshoot-menyen. På versjoner som inkluderer Docker Desktop CLI, kan du også bruke:

docker desktop status
docker desktop restart

Docker's gjeldende CLI-referanse dokumenterer status-, start-, stop- og restart-kommandoer. Se Docker Desktop CLI-dokumentasjon og Docker Desktop feilsøkingsdokumentasjon.

Etter at Docker har startet på nytt, test daemonen:

docker version
docker info

Hvis docker version returnerer både klient- og serverinformasjon i stedet for en daemon-tilkoblingsfeil, svarer motoren igjen.

Nyttig handling: hvis omstarten fungerer, stopp her. Ikke nullstill WSL, avregistrer distribusjoner eller installer Docker på nytt bare fordi en annen veiledning anbefaler det.

Vanlig misforståelse: start com.docker.service på nytt for hver Engine Stopped-feil

Det er ikke en universell løsning. Docker's gjeldende Windows-tillatelsesdokumentasjon sier at for WSL 2 Linux-containere er den privilegerte hjelperen com.docker.service ikke generelt nødvendig og kjører derfor ikke nødvendigvis automatisk ved oppstart. Den er nødvendig for scenarioer som Windows-containere og Hyper-V-backend, og kan også brukes for visse privilegerte vertsfiloperasjoner.

Så en stoppet com.docker.service er ikke bevis på at en WSL 2 Linux-container-installasjon er ødelagt. Se Docker's Windows-tillatelseskrav.

Nyttig handling: fastslå om du bruker WSL 2 Linux-containere før du behandler Windows-tjenesten som rotårsaken.

Fase 2: Sjekk og start WSL 2 på nytt

Åpne PowerShell eller Windows Terminal og kjør:

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

Docker krever for øyeblikket WSL 2.1.5 eller nyere for sin WSL 2-backend og anbefaler den nyeste tilgjengelige WSL-utgivelsen. Hvis WSL-en din er eldre, oppdater den:

wsl --update

Stopp deretter WSL 2-miljøet fullstendig:

wsl --shutdown

Microsoft sier at wsl --shutdown umiddelbart avslutter alle kjørende distribusjoner og WSL 2 lette verktøymaskinen. Start Docker Desktop igjen etter avslutningen. Hvis Windows eller WSL ba om en omstart under en oppdatering, start Windows på nytt før du tester igjen.

Nyttig handling: kjør kommandoene i denne rekkefølgen og registrer eventuelle nøyaktige feilkoder. En feil fra wsl --status er mer nyttig diagnostisk enn den generiske Docker «Engine stopped»-meldingen.

Vanlig misforståelse: installer Ubuntu på nytt for å reparere Docker Desktop

Docker Desktop krever ikke en spesifikk brukerininstallert Linux-distribusjon. Docker's WSL-dokumentasjon sier at Docker-kommandoer kan fungere fra Windows uten at en bestemt Linux-distribusjon er installert; å aktivere WSL-integrasjon for Ubuntu, Debian eller en annen distro er valgfritt for Linux-native arbeidsflyter.

Nyttig handling: hvis WSL selv starter korrekt, ikke slett en fungerende Ubuntu- eller Debian-distribusjon bare for å fikse Docker Desktop.

Ikke bruk wsl --unregister som en tidlig reparasjonskommando

Microsoft advarer uttrykkelig om at wsl --unregister <DistributionName> permanent fjerner den distribusjonens data, innstillinger og installert programvare. Kommandoer som avregistrerer Docker-relaterte eller personlige WSL-distribusjoner er derfor destruktiv feilsøking, ikke rutinemessige omstartskommandoer.

Nyttig handling: bruk wsl --shutdown først. Sikkerhetskopier viktige data før noen avregistrerings-, nullstillings-, oppryddings- eller reinstallasjonsprosedyre.

Fase 3: Verifiser Windows-virtualisering og WSL-funksjoner

WSL 2 trenger virtualiseringsstøtte. Microsoft sier at WSL 2 krever funksjonen Virtual Machine Platform og maskinvarevirtualiseringsstøtte. Microsoft's WSL FAQ identifiserer også to nødvendige Windows-komponenter for WSL 2: Virtual Machine Platform og Windows Subsystem for Linux. Se Microsoft's WSL FAQ og Microsoft's manuelle WSL-installasjonstrinn.

Åpne Slå Windows-funksjoner på eller av og verifiser at disse to funksjonene er aktivert:

• Windows Subsystem for Linux
• Virtual Machine Platform

Hvis en av funksjonene var deaktivert, aktiver den og start Windows på nytt.

Vanlig misforståelse: full Hyper-V må være aktivert for Docker Desktop med WSL 2

Full klient-Hyper-V er ikke det samme som virtualiseringskomponentene som brukes av WSL 2. Microsoft forklarer at WSL 2 bruker en delmengde av Hyper-V-arkitekturen som tilbys gjennom Virtual Machine Platform. Full Hyper-V er utilgjengelig på Windows Home, mens WSL 2 støttes på Windows Home der WSL er tilgjengelig. Docker behandler også WSL 2 og Hyper-V som separate backends.

Nyttig handling: hvis du bruker WSL 2-backend, verifiser WSL og Virtual Machine Platform først i stedet for blindt å aktivere hver Hyper-V-relaterte avkryssingsboks.

Hvis du ser feil 0x80370102

Dette er et mer spesifikt spor enn «Engine stopped». Microsoft's WSL-feilsøkingsside sier at feil 0x80370102 kan bety at en nødvendig virtualiseringsfunksjon ikke er tilgjengelig. Microsoft anbefaler å sjekke Virtual Machine Platform, BIOS/UEFI-virtualisering, CPU-virtualiseringsstøtte og hypervisor-oppstartskonfigurasjonen.

I et forhøyet PowerShell-vindu kan du inspisere hypervisor-oppstartsinnstillingen:

bcdedit /enum | findstr -i hypervisorlaunchtype

Hvis den uttrykkelig rapporterer hypervisorlaunchtype Off, sier Microsoft's feilsøkingsveiledning at den kan aktiveres med:

bcdedit /set hypervisorlaunchtype Auto

Start Windows på nytt etterpå. Se Microsoft's WSL-feilsøkingsveiledning.

Nyttig handling: bruk denne oppstartskonfigurasjonsfiksen bare når symptomene dine peker mot virtualisering eller hypervisoren. Ikke endre oppstartsinnstillinger bare fordi Docker er tregt eller en enkelt container feilet.

Fase 4: Sjekk Docker-innstillinger, oppdater og samle diagnostikk

Hvis WSL starter normalt men Docker Desktop fortsatt ikke gjør det, gå tilbake opp til Docker-laget.

Bekreft at du bruker den tiltenkte backenden

For Linux-containere sier Docker's WSL-dokumentasjon at Docker Desktop bruker WSL 2-motoren når den backenden er aktivert. Avhengig av gjeldende Docker Desktop-versjon og støttet system, kan «Use WSL 2 based engine»-innstillingen være aktivert som standard og kanskje ikke synlig.

Hvis Settings > Resources > WSL Integration mangler og du forventet Linux-container-integrasjon, noterer Docker at Docker Desktop kan være i Windows-containermodus. I den situasjonen, bytt tilbake til Linux-containere hvis Linux-containere er det du intenderte å kjøre.

Nyttig handling: ikke endre containermodus bare som et tilfeldig feilsøkingstrinn. Bekreft om prosjektet ditt faktisk bruker Linux- eller Windows-containere.

Oppdater Docker Desktop

Bruk Docker Desktops Software updates-seksjon eller den gjeldende installasjonsprogrammet fra Docker's offisielle Windows-installasjonsside. Docker's utgivelsesnotater inkluderer ofte Windows- og WSL-spesifikke fikser og kjente problemer, så de er verdt å sjekke når problemet starter umiddelbart etter en oppgradering. Se Docker Desktop utgivelsesnotater.

Nyttig handling: notér gjeldende Docker Desktop- og WSL-versjoner før oppdatering. Hvis en nylig utgivelsesnotat beskriver ditt nøyaktige symptom, følg den dokumenterte løsningen i stedet for å anvende urelaterte register- eller WSL-slettekommandoer.

Kjør diagnostikk før en fabrikknullstilling

Docker Desktops Troubleshoot-meny kan samle diagnostisk informasjon selv når applikasjonen har oppstartsproblemer. Docker dokumenterer også:

docker desktop diagnose

Docker Desktop CLI-dokumentasjonen sier at diagnose-kommandoen er tilgjengelig med Docker Desktop 4.60 og nyere. Hvis din installerte versjon ikke støtter den kommandoen, bruk Troubleshoot-grensesnittet eller Docker's dokumenterte com.docker.diagnose kjørbar filbane i stedet.

Nyttig handling: lagre diagnostisk ID og fang opp den nøyaktige oppstartsfeilen før du nullstiller noe. Det beviset er nyttig hvis du trenger å sammenligne logger, søke etter et gjeldende kjent problem eller åpne en supportcase.

Bare nullstill Docker Desktop etter å ha sikkerhetskopiert data

Docker's Troubleshoot-meny inkluderer Clean up data og Reset to factory defaults. Dette er siste utvei-alternativer, ikke rutinemessige fikser. Docker's sikkerhetskopidokumentasjon anbefaler å sikkerhetskopiere viktige bilder, volumer og Docker Desktop VM-data før reinstallasjon eller nullstilling når Docker Desktop ikke kan starte normalt. Se Docker's sikkerhetskopierings- og gjenopprettingsveiledning.

Når daemonen fortsatt fungerer nok til å bruke Docker-kommandoer, bevar det som betyr noe før nullstilling. For eksempel kan viktige bilder pushes til et register eller lagres til et tar-arkiv. Volumdata trenger sin egen sikkerhetskopistrategi.

Hvis Docker Desktop ikke vil starte i det hele tatt, dokumenterer Docker en Windows-prosedyre for å sikkerhetskopiere Docker Desktop virtuelle disk før reinstallasjon. Følg den gjeldende offisielle banen fra sikkerhetskopiveiledningen fordi Docker's interne lagringsoppsett kan endre seg mellom utgivelser.

Nyttig handling: ikke klikk Reset to factory defaults før du kan svare, «Hvor er den eneste kopien av mine viktige volumdata?»

Når reinstallasjon av Docker Desktop gir mening

Reinstallasjon er rimelig etter at du har fastslått at:

• WSL selv er sunt og oppdatert.
• Virtualiseringskravene er oppfylt.
• En normal Docker Desktop-omstart fortsatt feiler.
• Diagnostikk ikke avslører en enklere konfigurasjonsfikse.
• Viktige lokale Docker-data er sikkerhetskopiert eller er reproduserbare.

Bruk den gjeldende installasjonsprogrammet fra Docker i stedet for et gammelt installasjonsprogram bufret fra en tidligere veiledning. Docker's gjeldende Windows-installasjonsdokumentasjon skiller også mellom per-bruker og alle-brukere installasjonsmoduser. WSL 2-backend dekker de fleste brukere, mens Hyper-V-backend og Windows-containere har forskjellige installasjons- og privilegiekrav.

Nyttig handling: hvis du endrer installasjonsmodus eller backend under reinstallasjon, endre én variabel om gangen slik at du kan si hva som faktisk fikset problemet.

Hva om Docker fungerer i Windows Terminal men ikke inne i Ubuntu?

Det er vanligvis et integrasjonsspørsmål, ikke bevis på at Docker-motoren er stoppet. Docker sier at WSL-integrasjon kan aktiveres for utvalgte WSL 2-distribusjoner under Settings > Resources > WSL Integration. Brukerdistribusjonen selv må kjøre i WSL 2-modus.

Sjekk det med:

wsl -l -v

Hvis en brukerdistribusjon fortsatt er på WSL 1, dokumenterer Microsoft konvertering med:

wsl --set-version <DistributionName> 2

Microsoft advarer om at konvertering av store distribusjoner kan ta tid og kan feile, så sikkerhetskopier viktige filer før en stor WSL-konvertering.

Nyttig handling: skill «Docker-daemonen er nede» fra «denne WSL-distribusjonen kan ikke få tilgang til Docker». De er forskjellige problemer og bør ikke utløse de samme reparasjonstrinnene.

Hva om maskinen selv er en virtuell maskin?

Hvis Windows 11 kjører inne i VMware, Hyper-V, Azure eller en annen hypervisor, kan WSL 2 kreve nested virtualization – virtualisering eksponert gjennom den ytre virtuelle maskinen til Windows-gjesten. Microsoft dokumenterer kravene for nested virtualization og noterer at støtten avhenger av vertsplattformen og konfigurasjonen.

Nyttig handling: hvis dette er en bedrifts-VDI eller sky-VM, bekreft støtten for nested virtualization med plattformadministratoren før du bruker tid på å reinstallere Docker Desktop.

En trygg reparasjonsrekkefølge du kan beholde

1. Start Docker Desktop på nytt og test med docker version.
2. Kjør wsl --version og wsl --status.
3. Kjør wsl --update, deretter wsl --shutdown, og prøv Docker igjen.
4. Hvis WSL selv feiler, verifiser Windows Subsystem for Linux, Virtual Machine Platform og BIOS/UEFI-virtualisering.
5. Hvis du har en virtualiseringsspesifikk feil som 0x80370102, følg Microsoft's målrettede WSL-feilsøking.
6. Hvis WSL er sunt, verifiser Docker's backend/containermodus og oppdater Docker Desktop.
7. Samle Docker-diagnostikk og gjennomgå gjeldende utgivelsesnotater.
8. Sikkerhetskopier viktige data før opprydding, nullstilling, avregistrering eller reinstallasjon.

Konklusjon

«Docker Desktop Engine Stopped» er et symptom, ikke en enkelt diagnose. På Windows 11 med WSL 2-backend, er den tryggeste fikseveien å starte Docker på nytt, verifisere og oppdatere WSL, bekrefte virtualisering bare hvis WSL rapporterer en relatert feil, og samle Docker-diagnostikk før du bruker destruktive nullstillingsalternativer.

De to viktigste feilene å unngå er like enkle: ikke anta at en stoppet Windows Docker-tjeneste er årsaken på hvert WSL 2-oppsett, og ikke avregistrer WSL-distribusjoner eller fabrikknullstill Docker før du sikkerhetskopierer data. Disse trinnene kan gjøre et oppstartsproblem om til et datatapproblem uten å adressere den opprinnelige årsaken.