Sådan løser du 'Docker Desktop Engine Stopped' på Windows 11

Begynd med at genstarte Docker Desktop og WSL 2-virtuel maskine – ikke ved at geninstallere Docker eller slette dets WSL-data. På nuværende Windows-opstillinger bruger Docker Desktop typisk WSL 2-backend, så beskeden “Engine stopped” kan skyldes et problem med Docker Desktop, WSL eller Windows-virtualisering. Den hurtigste reparation er at identificere, hvilket lag der fejler, før du foretager destruktive ændringer.

Pr. september 2026 kræver Docker's Windows-dokumentation WSL 2.1.5 eller nyere for WSL 2-backend og anbefaler at bruge den nyeste WSL-version. Docker beskriver også WSL 2 som standard-backend for de fleste Windows-brugere. Microsoft dokumenterer wsl --version, wsl --status, wsl --update og wsl --shutdown som standardkommandoer til at tjekke, opdatere og genstarte WSL-miljøet. Se Docker's Windows installationskrav, Docker's WSL 2 backend-dokumentation og Microsoft's WSL-kommandoreference.

Denne guide bruger fire reparationsfaser, fra den sikreste til den mest forstyrrende. Stop, så snart Docker fungerer igen.

Først, identificer hvilket lag der faktisk fejler

Hvad der er kendt: disse lag afhænger af hinanden. Hvad der ikke er kendt ud fra ordene “Engine stopped” alene: hvilket lag der fejlede på din PC. Beskeden i sig selv er ikke nok til at retfærdiggøre en fabriksnulstilling.

Fase 1: Genstart Docker Desktop og verificér daemonen

Brug Docker Desktop's Troubleshoot > Restart Docker Desktop-mulighed først. Docker dokumenterer Restart Docker Desktop som den første ikke-destruktive handling i sin Troubleshoot-menu. På versioner, der inkluderer Docker Desktop CLI, kan du også bruge:

docker desktop status
docker desktop restart

Docker's nuværende CLI-reference dokumenterer status-, start-, stop- og restart-kommandoer. Se Docker Desktop CLI-dokumentation og Docker Desktop fejlfindingsdokumentation.

Efter Docker genstarter, test daemonen:

docker version
docker info

Hvis docker version returnerer både klient- og serverinformation i stedet for en daemon-forbindelsesfejl, reagerer motoren igen.

Nyttig handling: hvis genstarten virker, stop her. Nulstil ikke WSL, afregistrer distributioner eller geninstaller Docker, bare fordi en anden vejledning anbefaler det.

Almindelig misforståelse: genstart com.docker.service for hver Engine Stopped-fejl

Det er ikke en universel løsning. Docker's nuværende Windows-tilladelsesdokumentation siger, at for WSL 2 Linux-containere er den privilegerede hjælper com.docker.service generelt ikke påkrævet og kører derfor ikke nødvendigvis automatisk ved opstart. Den er påkrævet for scenarier som Windows-containere og Hyper-V-backend og kan også bruges til visse privilegerede værtsfiloperationer.

Så en stoppet com.docker.service er ikke bevis for, at en WSL 2 Linux-containerinstallation er ødelagt. Se Docker's Windows tilladelseskrav.

Nyttig handling: fastslå, om du bruger WSL 2 Linux-containere, før du behandler Windows-tjenesten som den underliggende årsag.

Fase 2: Tjek og genstart WSL 2

Åbn PowerShell eller Windows Terminal og kør:

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

Docker kræver i øjeblikket WSL 2.1.5 eller nyere for sin WSL 2-backend og anbefaler den nyeste tilgængelige WSL-udgivelse. Hvis din WSL er ældre, skal du opdatere den:

wsl --update

Stop derefter WSL 2-miljøet fuldstændigt:

wsl --shutdown

Microsoft siger, at wsl --shutdown øjeblikkeligt afslutter alle kørende distributioner og WSL 2 letvægts-virtuel maskine. Start Docker Desktop igen efter nedlukningen. Hvis Windows eller WSL anmodede om en genstart under en opdatering, skal du genstarte Windows før gentest.

Nyttig handling: kør kommandoerne i denne rækkefølge og notér eventuelle præcise fejlkode. En fejl fra wsl --status er mere nyttig diagnostisk end den generiske Docker “Engine stopped”-besked.

Almindelig misforståelse: geninstaller Ubuntu for at reparere Docker Desktop

Docker Desktop kræver ikke en specifik brugerinstalleret Linux-distribution. Docker's WSL-dokumentation siger, at Docker-kommandoer kan fungere fra Windows uden en bestemt Linux-distribution installeret; aktivering af WSL-integration for Ubuntu, Debian eller en anden distro er valgfrit for Linux-native arbejdsflow.

Nyttig handling: hvis WSL selv starter korrekt, så slet ikke en fungerende Ubuntu- eller Debian-distribution blot for at fikse Docker Desktop.

Brug ikke wsl --unregister som en tidlig reparationskommando

Microsoft advarer eksplicit om, at wsl --unregister <DistributionName> permanent fjerner den distributions data, indstillinger og installerede software. Kommandoer, der afregistrerer Docker-relaterede eller personlige WSL-distributioner, er derfor destruktiv fejlfinding, ikke rutinemæssige genstartskommandoer.

Nyttig handling: brug wsl --shutdown først. Sikkerhedskopiér vigtige data før enhver afregistrerings-, nulstillings-, oprydnings- eller geninstallationsprocedure.

Fase 3: Verificér Windows-virtualisering og WSL-funktioner

WSL 2 har brug for virtualiseringsunderstøttelse. Microsoft angiver, at WSL 2 kræver Virtual Machine Platform-funktionen og hardwarevirtualiseringsunderstøttelse. Microsoft's WSL FAQ identificerer også to påkrævede Windows-komponenter for WSL 2: Virtual Machine Platform og Windows Subsystem for Linux. Se Microsoft's WSL FAQ og Microsoft's manuelle WSL-installationstrin.

Åbn Slå Windows-funktioner til eller fra og verificér, at disse to funktioner er aktiveret:

• Windows Subsystem for Linux
• Virtual Machine Platform

Hvis en af funktionerne var deaktiveret, skal du aktivere den og genstarte Windows.

Almindelig misforståelse: fuld Hyper-V skal være aktiveret for Docker Desktop med WSL 2

Fuld klient-Hyper-V er ikke det samme som de virtualiseringskomponenter, der bruges af WSL 2. Microsoft forklarer, at WSL 2 bruger en delmængde af Hyper-V-arkitekturen, der leveres via Virtual Machine Platform. Fuld Hyper-V er ikke tilgængelig på Windows Home, mens WSL 2 understøttes på Windows Home, hvor WSL er tilgængelig. Docker behandler også WSL 2 og Hyper-V som separate backends.

Nyttig handling: hvis du bruger WSL 2-backend, skal du verificere WSL og Virtual Machine Platform først i stedet for blindt at aktivere alle Hyper-V-relaterede afkrydsningsfelter.

Hvis du ser fejl 0x80370102

Dette er et mere specifikt spor end “Engine stopped.” Microsoft's WSL-fejlfindingsside siger, at fejl 0x80370102 kan betyde, at en påkrævet virtualiseringsfunktion ikke er tilgængelig. Microsoft anbefaler at tjekke Virtual Machine Platform, BIOS/UEFI-virtualisering, CPU-virtualiseringsunderstøttelse og hypervisor-startkonfigurationen.

I et forhøjet PowerShell-vindue kan du inspicere hypervisor-startindstillingen:

bcdedit /enum | findstr -i hypervisorlaunchtype

Hvis den eksplicit rapporterer hypervisorlaunchtype Off, siger Microsoft's fejlfindingsvejledning, at den kan aktiveres med:

bcdedit /set hypervisorlaunchtype Auto

Genstart Windows bagefter. Se Microsoft's WSL-fejlfindingsguide.

Nyttig handling: brug denne opstarts-konfigurationsreparation kun, når dine symptomer peger på virtualisering eller hypervisoren. Ændr ikke opstartsindstillinger blot fordi Docker er langsom, eller en enkelt container fejlede.

Fase 4: Tjek Docker-indstillinger, opdater og indsamle diagnostik

Hvis WSL starter normalt, men Docker Desktop stadig ikke gør, så bevæg dig tilbage op til Docker-laget.

Bekræft, at du bruger den tilsigtede backend

For Linux-containere siger Docker's WSL-dokumentation, at Docker Desktop bruger WSL 2-motoren, når den backend er aktiveret. Afhængigt af den nuværende Docker Desktop-version og understøttet system kan indstillingen “Use WSL 2 based engine” være aktiveret som standard og måske ikke synlig.

Hvis Settings > Resources > WSL Integration mangler, og du forventede Linux-container-integration, noterer Docker, at Docker Desktop måske er i Windows-container-tilstand. I den situation, skal du skifte tilbage til Linux-containere, hvis Linux-containere er det, du har til hensigt at køre.

Nyttig handling: ændr ikke container-tilstand blot som et tilfældigt fejlfindingstrin. Bekræft, om dit projekt faktisk bruger Linux- eller Windows-containere.

Opdater Docker Desktop

Brug Docker Desktop's Software updates-sektion eller den nuværende installer fra Docker's officielle Windows-installationsside. Docker's udgivelsesnoter indeholder ofte Windows- og WSL-specifikke rettelser og kendte problemer, så de er værd at tjekke, når problemet starter umiddelbart efter en opgradering. Se Docker Desktop udgivelsesnoter.

Nyttig handling: notér dine nuværende Docker Desktop- og WSL-versioner før opdatering. Hvis en nylig udgivelsesnote beskriver dit præcise symptom, så følg den dokumenterede workaround i stedet for at anvende urelaterede register- eller WSL-slettekommandoer.

Kør diagnostik før en fabriksnulstilling

Docker Desktop's Troubleshoot-menu kan indsamle diagnostisk information, selv når applikationen har opstartsproblemer. Docker dokumenterer også:

docker desktop diagnose

Docker Desktop CLI-dokumentationen siger, at diagnose-kommandoen er tilgængelig med Docker Desktop 4.60 og nyere. Hvis din installerede version ikke understøtter den kommando, så brug Troubleshoot-grænsefladen eller Docker's dokumenterede com.docker.diagnose-eksekverbare sti i stedet.

Nyttig handling: gem diagnostik-ID'et og fang den præcise opstartsfejl, før du nulstiller noget. Det bevis er nyttigt, hvis du skal sammenligne logfiler, søge efter et aktuelt kendt problem eller åbne en support-sag.

Nulstil kun Docker Desktop efter sikkerhedskopiering af data

Docker's Troubleshoot-menu inkluderer Clean up data og Reset to factory defaults. Disse er sidste udvej-muligheder, ikke rutinemæssige rettelser. Docker's backup-dokumentation anbefaler at sikkerhedskopiere vigtige images, volumes og Docker Desktop VM-data før geninstallation eller nulstilling, når Docker Desktop ikke kan starte normalt. Se Docker's backup- og gendannelsesguide.

Når daemonen stadig fungerer nok til at bruge Docker-kommandoer, så bevar det, der betyder noget, før nulstilling. For eksempel kan vigtige images pushes til et register eller gemmes i et tar-arkiv. Volume-data har brug for sin egen backup-strategi.

Hvis Docker Desktop ikke vil starte overhovedet, dokumenterer Docker en Windows-procedure for at sikkerhedskopiere Docker Desktop-virtuel disk før geninstallation. Følg den nuværende officielle sti fra backup-guiden, fordi Docker's interne lagerlayout kan ændre sig mellem udgivelser.

Nyttig handling: klik ikke på Reset to factory defaults, før du kan svare på: “Hvor er den eneste kopi af mine vigtige volume-data?”

Når geninstallation af Docker Desktop giver mening

Geninstallation er rimelig, efter du har fastslået, at:

• WSL selv er sund og opdateret.
• Virtualiseringskravene er opfyldt.
• En normal Docker Desktop-genstart stadig fejler.
• Diagnostik afslører ikke en simplere konfigurationsrettelse.
• Vigtige lokale Docker-data er sikkerhedskopieret eller kan reproduceres.

Brug den nuværende installer fra Docker i stedet for en gammel installer cachelagret fra en tidligere vejledning. Docker's nuværende Windows-installationsdokumentation skelner også mellem per-bruger og alle-brugere installationsmetoder. WSL 2-backend dækker de fleste brugere, mens Hyper-V-backend og Windows-containere har forskellige installations- og privilegiekrav.

Nyttig handling: hvis du ændrer installationsmetode eller backend under geninstallation, så ændr én variabel ad gangen, så du kan fortælle, hvad der faktisk løste problemet.

Hvad hvis Docker fungerer i Windows Terminal, men ikke inde i Ubuntu?

Det er normalt et integrationsspørgsmål, ikke bevis for, at Docker-motoren er stoppet. Docker siger, at WSL-integration kan aktiveres for udvalgte WSL 2-distributioner under Settings > Resources > WSL Integration. Brugerdistributionen selv skal køre i WSL 2-tilstand.

Tjek det med:

wsl -l -v

Hvis en brugerdistribution stadig er på WSL 1, dokumenterer Microsoft konvertering med:

wsl --set-version <DistributionName> 2

Microsoft advarer om, at konvertering af store distributioner kan tage tid og kan fejle, så sikkerhedskopiér vigtige filer før en stor WSL-konvertering.

Nyttig handling: skeln mellem “Docker-daemonen er nede” og “denne WSL-distribution kan ikke få adgang til Docker.” De er forskellige problemer og bør ikke udløse de samme reparationstrin.

Hvad hvis maskinen selv er en virtuel maskine?

Hvis Windows 11 kører inde i VMware, Hyper-V, Azure eller en anden hypervisor, kan WSL 2 kræve nested virtualization – virtualisering eksponeret gennem den ydre virtuelle maskine til Windows-gæsten. Microsoft dokumenterer kravene til nested virtualization og noterer, at understøttelse afhænger af værtsplatformen og konfigurationen.

Nyttig handling: hvis dette er en virksomheds VDI eller cloud VM, skal du bekræfte understøttelse af nested virtualization med platformadministratoren, før du bruger tid på at geninstallere Docker Desktop.

En sikker repareringsrækkefølge, du kan beholde

1. Genstart Docker Desktop og test med docker version.
2. Kør wsl --version og wsl --status.
3. Kør wsl --update, derefter wsl --shutdown, og prøv Docker igen.
4. Hvis WSL selv fejler, skal du verificere Windows Subsystem for Linux, Virtual Machine Platform og BIOS/UEFI-virtualisering.
5. Hvis du har en virtualiseringsspecifik fejl som 0x80370102, så følg Microsoft's målrettede WSL-fejlfinding.
6. Hvis WSL er sund, skal du verificere Docker's backend/container-tilstand og opdatere Docker Desktop.
7. Indsaml Docker-diagnostik og gennemse aktuelle udgivelsesnoter.
8. Sikkerhedskopiér vigtige data før oprydning, nulstilling, afregistrering eller geninstallationsoperationer.

Konklusion

“Docker Desktop Engine Stopped” er et symptom, ikke en enkelt diagnose. På Windows 11 med WSL 2-backend er den sikreste repareringssti at genstarte Docker, verificere og opdatere WSL, bekræfte virtualisering kun hvis WSL rapporterer en relateret fejl, og indsamle Docker-diagnostik før brug af destruktive nulstillingsmuligheder.

De to vigtigste fejl at undgå er lige så simple: antag ikke, at en stoppet Windows Docker-tjeneste er årsagen på alle WSL 2-opstillinger, og afregistrer ikke WSL-distributioner eller fabriksnulstil Docker før sikkerhedskopiering af data. Disse trin kan gøre et opstartsproblem til et datatabsproblem uden at adressere den oprindelige årsag.