Så här åtgärdar du att Docker Desktop-motorn har stoppats på Windows 11

Börja med att starta om Docker Desktop och WSL 2-virtuella maskinen – inte genom att installera om Docker eller radera dess WSL-data. På aktuella Windows-installationer använder Docker Desktop vanligtvis WSL 2-backend, så ett meddelande om att ”Motorn har stoppats” kan bero på ett problem med Docker Desktop, ett WSL-problem eller ett Windows-virtualiseringsproblem. Den snabbaste vägen till reparation är att identifiera vilket lager som misslyckas innan du gör destruktiva ändringar.

Per september 2026 kräver Docker:s Windows-dokumentation WSL 2.1.5 eller senare för WSL 2-backend och rekommenderar att du använder den senaste WSL-versionen. Docker beskriver också WSL 2 som standardbackend för de flesta Windows-användare. Microsoft dokumenterar wsl --version, wsl --status, wsl --update och wsl --shutdown som standardkommandon för att kontrollera, uppdatera och starta om WSL-miljön. Se Docker:s installationskrav för Windows, Docker:s dokumentation för WSL 2-backend och Microsoft:s WSL-kommandoreferens.

Den här guiden använder fyra reparationsfaser, från säkrast till mest störande. Stoppa så snart Docker fungerar igen.

Först, identifiera vilket lager som faktiskt misslyckas

Vad som är känt: dessa lager är beroende av varandra. Vad som inte är känt enbart från orden ”Motorn har stoppats”: vilket lager som misslyckades på din PC. Meddelandet i sig är inte tillräckligt för att motivera en fabriksåterställning.

Fas 1: Starta om Docker Desktop och verifiera daemonen

Använd Docker Desktop:s alternativ Felsök > Starta om Docker Desktop först. Docker dokumenterar Starta om Docker Desktop som den första icke-destruktiva åtgärden i dess Felsökningsmeny. På versioner som inkluderar Docker Desktop CLI kan du också använda:

docker desktop status
docker desktop restart

Docker:s aktuella CLI-referens dokumenterar kommandona status, start, stop och restart. Se Docker Desktop CLI-dokumentation och Docker Desktop felsökningsdokumentation.

Efter att Docker har startat om, testa daemonen:

docker version
docker info

Om docker version returnerar både klient- och serverinformation istället för ett fel för daemonanslutning, svarar motorn igen.

Användbar åtgärd: om omstarten fungerar, stanna här. Återställ inte WSL, avregistrera distributioner eller installera om Docker bara för att en annan handledning rekommenderar det.

Vanligt missförstånd: starta om com.docker.service för varje fel där motorn har stoppats

Det är inte en universell lösning. Docker:s aktuella dokumentation för Windows-behörigheter säger att för WSL 2 Linux-containrar krävs inte den privilegierade hjälparen com.docker.service generellt och körs därför inte nödvändigtvis automatiskt vid start. Den krävs för scenarier som Windows-containrar och Hyper-V-backend, och kan också användas för vissa privilegierade värdfiloperationer.

En stoppad com.docker.service är alltså inte bevis på att en WSL 2 Linux-containerinstallation är trasig. Se Docker:s behörighetskrav för Windows.

Användbar åtgärd: avgör om du använder WSL 2 Linux-containrar innan du behandlar Windows-tjänsten som grundorsaken.

Fas 2: Kontrollera och starta om WSL 2

Öppna PowerShell eller Windows Terminal och kör:

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

Docker kräver för närvarande WSL 2.1.5 eller senare för sin WSL 2-backend och rekommenderar den senaste tillgängliga WSL-releasen. Om din WSL är äldre, uppdatera den:

wsl --update

Stoppa sedan WSL 2-miljön helt:

wsl --shutdown

Microsoft säger att wsl --shutdown omedelbart avslutar alla körande distributioner och WSL 2:s lätta hjälpvirtuella maskin. Starta Docker Desktop igen efter avstängningen. Om Windows eller WSL begärde en omstart under en uppdatering, starta om Windows innan du testar igen.

Användbar åtgärd: kör kommandona i denna ordning och registrera eventuella exakta felkoder. Ett fel från wsl --status är mer diagnostiskt användbart än det generiska Docker-meddelandet ”Motorn har stoppats”.

Vanligt missförstånd: installera om Ubuntu för att reparera Docker Desktop

Docker Desktop kräver inte en specifik användarinstallerad Linux-distribution. Docker:s WSL-dokumentation säger att Docker-kommandon kan fungera från Windows utan att en specifik Linux-distribution är installerad; att aktivera WSL-integration för Ubuntu, Debian eller en annan distro är valfritt för Linux-nativa arbetsflöden.

Användbar åtgärd: om WSL själv startar korrekt, radera inte en fungerande Ubuntu- eller Debian-distribution enbart för att fixa Docker Desktop.

Använd inte wsl --unregister som ett tidigt reparationskommando

Microsoft varnar uttryckligen för att wsl --unregister <DistributionName> permanent tar bort den distributionens data, inställningar och installerad programvara. Kommandon som avregistrerar Docker-relaterade eller personliga WSL-distributioner är därför destruktiv felsökning, inte rutinmässiga omstartskommandon.

Användbar åtgärd: använd wsl --shutdown först. Säkerhetskopiera viktig data innan någon avregistrerings-, återställnings-, städ- eller ominstallationsprocedur.

Fas 3: Verifiera Windows-virtualisering och WSL-funktioner

WSL 2 behöver virtualiseringsstöd. Microsoft anger att WSL 2 kräver funktionen Virtuell maskinplattform och hårdvaruvirtualiseringsstöd. Microsoft:s WSL-FAQ identifierar också två krävda Windows-komponenter för WSL 2: Virtuell maskinplattform och Windows Subsystem for Linux. Se Microsoft:s WSL-FAQ och Microsoft:s manuella WSL-installationssteg.

Öppna Slå på eller av Windows-funktioner och verifiera att dessa två funktioner är aktiverade:

• Windows Subsystem for Linux
• Virtuell maskinplattform

Om någon av funktionerna var inaktiverad, aktivera den och starta om Windows.

Vanligt missförstånd: fullständig Hyper-V måste vara aktiverat för Docker Desktop med WSL 2

Fullständig klient-Hyper-V är inte samma sak som de virtualiseringskomponenter som används av WSL 2. Microsoft förklarar att WSL 2 använder en delmängd av Hyper-V-arkitekturen som tillhandahålls via Virtuell maskinplattform. Fullständig Hyper-V är inte tillgänglig på Windows Home, medan WSL 2 stöds på Windows Home där WSL är tillgängligt. Docker behandlar också WSL 2 och Hyper-V som separata backends.

Användbar åtgärd: om du använder WSL 2-backend, verifiera WSL och Virtuell maskinplattform först istället för att blindt aktivera varje Hyper-V-relaterad kryssruta.

Om du ser fel 0x80370102

Detta är en mer specifik ledtråd än ”Motorn har stoppats”. Microsoft:s WSL-felsökningssida säger att felet 0x80370102 kan betyda att en krävd virtualiseringsfunktion inte är tillgänglig. Microsoft rekommenderar att kontrollera Virtuell maskinplattform, BIOS/UEFI-virtualisering, CPU-virtualiseringsstöd och hypervisorns startkonfiguration.

I ett förhöjt PowerShell-fönster kan du inspektera hypervisorns startinställning:

bcdedit /enum | findstr -i hypervisorlaunchtype

Om den uttryckligen rapporterar hypervisorlaunchtype Off, säger Microsoft:s felsökningsvägledning att den kan aktiveras med:

bcdedit /set hypervisorlaunchtype Auto

Starta om Windows efteråt. Se Microsoft:s WSL-felsökningsguide.

Användbar åtgärd: använd den här fixen för startkonfigurationen endast när dina symtom pekar på virtualisering eller hypervisorn. Ändra inte startinställningar enbart för att Docker är långsamt eller att en enda container misslyckades.

Fas 4: Kontrollera Docker-inställningar, uppdatera och samla in diagnostik

Om WSL startar normalt men Docker Desktop fortfarande inte gör det, gå tillbaka upp till Docker-lagret.

Bekräfta att du använder den avsedda backenden

För Linux-containrar säger Docker:s WSL-dokumentation att Docker Desktop använder WSL 2-motorn när den backenden är aktiverad. Beroende på aktuell Docker Desktop-version och stödd system kan inställningen ”Använd WSL 2-baserad motor” vara aktiverad som standard och kanske inte synlig.

Om Inställningar > Resurser > WSL-integration saknas och du förväntade dig Linux-containerintegration, noterar Docker att Docker Desktop kan vara i Windows-containerläge. I den situationen, byt tillbaka till Linux-containrar om Linux-containrar är vad du avser att köra.

Användbar åtgärd: ändra inte containerläge enbart som ett slumpmässigt felsökningssteg. Bekräfta om ditt projekt faktiskt använder Linux- eller Windows-containrar.

Uppdatera Docker Desktop

Använd Docker Desktop:s avsnitt för programvaruuppdateringar eller den aktuella installationsprogrammet från Docker:s officiella Windows-installationssida. Docker:s releasenoter inkluderar ofta Windows- och WSL-specifika fixar och kända problem, så det är värt att kontrollera dem när problemet börjar omedelbart efter en uppgradering. Se Docker Desktop-releasenoter.

Användbar åtgärd: notera dina nuvarande Docker Desktop- och WSL-versioner innan du uppdaterar. Om en nylig releasenot beskriver ditt exakta symtom, följ den dokumenterade lösningen istället för att tillämpa orelaterade register- eller WSL-raderingskommandon.

Kör diagnostik innan en fabriksåterställning

Docker Desktop:s Felsökningsmeny kan samla in diagnostisk information även när applikationen har startproblem. Docker dokumenterar också:

docker desktop diagnose

Docker Desktop CLI-dokumentationen säger att diagnose-kommandot är tillgängligt med Docker Desktop 4.60 och senare. Om din installerade version inte stöder det kommandot, använd Felsökningsgränssnittet eller Docker:s dokumenterade com.docker.diagnose körbara sökväg istället.

Användbar åtgärd: spara diagnostik-ID:t och fånga det exakta startfelet innan du återställer något. Det beviset är användbart om du behöver jämföra loggar, söka efter ett aktuellt känt problem eller öppna ett supportärende.

Återställ bara Docker Desktop efter att du har säkerhetskopierat data

Docker:s Felsökningsmeny inkluderar Rensa data och Återställ till fabriksinställningar. Dessa är sista utvägen-alternativ, inte rutinmässiga fixar. Docker:s säkerhetskopiadokumentation rekommenderar att du säkerhetskopierar viktiga avbilder, volymer och Docker Desktop VM-data innan du installerar om eller återställer när Docker Desktop inte kan starta normalt. Se Docker:s guide för säkerhetskopiering och återställning.

När daemonen fortfarande fungerar tillräckligt för att använda Docker-kommandon, bevara det som är viktigt innan återställning. Till exempel kan viktiga avbilder pushas till ett register eller sparas till en tar-arkiv. Volymdata behöver sin egen säkerhetskopieringsstrategi.

Om Docker Desktop inte startar alls, dokumenterar Docker en Windows-procedur för att säkerhetskopiera Docker Desktop:s virtuella disk innan ominstallation. Följ den aktuella officiella vägen från säkerhetskopiaguiden eftersom Docker:s interna lagringslayout kan ändras mellan releaser.

Användbar åtgärd: klicka inte på Återställ till fabriksinställningar förrän du kan svara på, ”Var är den enda kopian av min viktiga volymdata?”

När det är rimligt att installera om Docker Desktop

Ominstallation är rimligt efter att du har fastställt att:

• WSL själv är frisk och uppdaterad.
• Virtualiseringskraven är uppfyllda.
• En normal omstart av Docker Desktop fortfarande misslyckas.
• Diagnostik inte avslöjar en enklare konfigurationsfix.
• Viktig lokal Docker-data har säkerhetskopierats eller är reproducerbar.

Använd det aktuella installationsprogrammet från Docker istället för ett gammalt installationsprogram som cachats från en tidigare handledning. Docker:s aktuella Windows-installationsdokumentation skiljer också mellan installationslägen per användare och för alla användare. WSL 2-backend täcker de flesta användare, medan Hyper-V-backend och Windows-containrar har olika installations- och behörighetskrav.

Användbar åtgärd: om du ändrar installationsläge eller backend under ominstallation, ändra en variabel i taget så att du kan avgöra vad som faktiskt löste problemet.

Vad om Docker fungerar i Windows Terminal men inte inne i Ubuntu?

Det är vanligtvis en integrationsfråga, inte bevis på att Docker-motorn har stoppats. Docker säger att WSL-integration kan aktiveras för valda WSL 2-distributioner under Inställningar > Resurser > WSL-integration. Användardistributionen själv måste köra i WSL 2-läge.

Kontrollera det med:

wsl -l -v

Om en användardistribution fortfarande är på WSL 1, dokumenterar Microsoft konvertering med:

wsl --set-version <DistributionName> 2

Microsoft varnar att konvertering av stora distributioner kan ta tid och kan misslyckas, så säkerhetskopiera viktiga filer innan en större WSL-konvertering.

Användbar åtgärd: särskilj ”Docker-daemonen är nere” från ”denna WSL-distribution kan inte komma åt Docker”. De är olika problem och bör inte utlösa samma reparationssteg.

Vad om maskinen i sig är en virtuell maskin?

Om Windows 11 körs inuti VMware, Hyper-V, Azure eller en annan hypervisor, kan WSL 2 kräva nästlad virtualisering – virtualisering exponerad genom den yttre virtuella maskinen till Windows-gästen. Microsoft dokumenterar kraven för nästlad virtualisering och noterar att stödet beror på värdplattformen och konfigurationen.

Användbar åtgärd: om detta är en företags-VDI eller moln-VM, bekräfta stöd för nästlad virtualisering med plattformsadministratören innan du lägger tid på att installera om Docker Desktop.

En säker reparationsordning du kan behålla

1. Starta om Docker Desktop och testa med docker version.
2. Kör wsl --version och wsl --status.
3. Kör wsl --update, sedan wsl --shutdown, och försök igen med Docker.
4. Om WSL själv misslyckas, verifiera Windows Subsystem for Linux, Virtuell maskinplattform och BIOS/UEFI-virtualisering.
5. Om du har ett virtualiseringsspecifikt fel som 0x80370102, följ Microsoft:s riktade WSL-felsökning.
6. Om WSL är frisk, verifiera Dockers backend/containerläge och uppdatera Docker Desktop.
7. Samla in Docker-diagnostik och granska aktuella releasenoter.
8. Säkerhetskopiera viktig data innan städ-, återställnings-, avregistrerings- eller ominstallationsoperationer.

Slutsats

”Docker Desktop-motorn har stoppats” är ett symtom, inte en enda diagnos. På Windows 11 med WSL 2-backend är den säkraste fixvägen att starta om Docker, verifiera och uppdatera WSL, bekräfta virtualisering endast om WSL rapporterar ett relaterat fel, och samla in Docker-diagnostik innan du använder destruktiva återställningsalternativ.

De två viktigaste misstagen att undvika är lika enkla: antag inte att en stoppad Windows Docker-tjänst är orsaken på varje WSL 2-installation, och avregistrera inte WSL-distributioner eller fabriksåterställ Docker innan du säkerhetskopierar data. Dessa steg kan förvandla ett startproblem till ett dataförlustproblem utan att adressera den ursprungliga orsaken.