Jak opravit chybu „Engine stopped“ v Docker Desktop na Windows 11

Začněte restartem Docker Desktop a virtuálního stroje WSL 2 – ne přeinstalací Dockeru nebo smazáním jeho dat ve WSL. Na současných instalacích Windows Docker Desktop běžně používá backend WSL 2, takže zpráva „Engine stopped“ může signalizovat problém s Docker Desktop, problém s WSL nebo problém s virtualizací ve Windows. Nejrychlejší cestou k opravě je identifikovat, která vrstva selhává, ještě před provedením destruktivních změn.

K září 2026 vyžaduje dokumentace Dockeru pro Windows verzi WSL 2.1.5 nebo novější pro backend WSL 2 a doporučuje používat nejnovější verzi WSL. Docker také popisuje WSL 2 jako výchozí backend pro většinu uživatelů Windows. Microsoft dokumentuje příkazy wsl --version, wsl --status, wsl --update a wsl --shutdown jako standardní příkazy pro kontrolu, aktualizaci a restart prostředí WSL. Podívejte se na požadavky na instalaci Dockeru pro Windows, dokumentaci backendu WSL 2 pro Docker a referenci příkazů WSL od Microsoftu.

Tato příručka používá čtyři fáze opravy, od nejbezpečnější po nejvíce narušující. Přestaňte, jakmile Docker opět funguje.

Nejprve identifikujte, která vrstva skutečně selhává

Co vidíteNejužitečnější další kontrola
Docker Desktop se otevře, ale hlásí, že engine je zastavenRestartujte Docker Desktop a poté otestujte démona Dockeru
Příkaz wsl --status nebo wsl --version selžeOpravte nebo aktualizujte WSL před změnou dat Dockeru
WSL hlásí chybu virtualizace nebo požadované funkceZkontrolujte Platformu virtuálního stroje a virtualizaci v BIOS/UEFI
WSL funguje, ale Docker stále nespustíZkontrolujte nastavení Docker Desktop, aktualizujte Docker a shromáždi diagnostiku
Problém začal okamžitě po aktualizaciZkontrolujte poznámky k vydání aktuální verze Docker Desktop pro odpovídající známý problém s Windows/WSL

Co je známo: tyto vrstvy jsou na sobě závislé. Co není známo pouze ze slov „Engine stopped“: která vrstva selhala na vašem PC. Samotná zpráva nestačí k odůvodnění továrního resetu.

Fáze 1: Restartujte Docker Desktop a ověřte démona

AI ilustrace Docker Desktop na Windows 11 zobrazující zprávu Engine stopped a tlačítko Restart Docker Desktop
AI generovaná ilustrace obrazovky zastaveného enginu Docker Desktop. Nejedná se o skutečný snímek obrazovky Docker Desktop a přesné znění UI se může lišit podle verze.

Nejprve použijte možnost Troubleshoot > Restart Docker Desktop v Docker Desktop. Docker dokumentuje Restart Docker Desktop jako první nedestruktivní akci v nabídce Troubleshoot. Ve verzích, které zahrnují CLI Docker Desktop, můžete také použít:

docker desktop status
docker desktop restart

Aktuální reference CLI Dockeru dokumentuje příkazy status, start, stop a restart. Podívejte se na dokumentaci CLI Docker Desktop a dokumentaci řešení potíží s Docker Desktop.

Po restartu Dockeru otestujte démona:

docker version
docker info

Pokud docker version vrátí informace o klientovi i serveru místo chyby připojení k démonovi, engine opět odpovídá.

Užitečný krok: pokud restart funguje, zde skončete. Neresetujte WSL, neodregistrujte distribuce ani nepřeinstalujte Docker jen proto, že to doporučuje jiný návod.

Běžné nedorozumění: restartujte com.docker.service při každé chybě Engine Stopped

To není univerzální oprava. Aktuální dokumentace oprávnění Dockeru pro Windows uvádí, že pro linuxové kontejnery ve WSL 2 není privilegovaný pomocník com.docker.service obecně vyžadován, a proto nutně neběží automaticky při startu systému. Je vyžadován pro scénáře, jako jsou kontejnery Windows a backend Hyper-V, a může být také použit pro určité privilegované operace s hostitelskými soubory.

Zastavená služba com.docker.service tedy není důkazem, že je instalace linuxových kontejnerů ve WSL 2 poškozena. Podívejte se na požadavky na oprávnění Dockeru pro Windows.

Užitečný krok: zjistěte, zda používáte linuxové kontejnery ve WSL 2, než začnete považovat službu Windows za příčinu problému.

Fáze 2: Zkontrolujte a restartujte WSL 2

AI ilustrace příkazového řádku Windows zobrazující kontrolu stavu WSL a verze WSL pro řešení potíží s Dockerem
AI generovaná ilustrace příkazového řádku. Zobrazená čísla verzí jsou pouze ilustrativní; pro skutečné hodnoty použijte příkazy na svém vlastním PC.

Otevřete PowerShell nebo Windows Terminal a spusťte:

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

Docker aktuálně vyžaduje pro svůj backend WSL 2 verzi WSL 2.1.5 nebo novější a doporučuje nejnovější dostupné vydání WSL. Pokud je vaše WSL starší, aktualizujte ji:

wsl --update

Poté zcela zastavte prostředí WSL 2:

wsl --shutdown

Microsoft uvádí, že wsl --shutdown okamžitě ukončí všechny běžící distribuce a lehký virtuální stroj WSL 2. Po vypnutí znovu spusťte Docker Desktop. Pokud Windows nebo WSL vyžadovaly restart během aktualizace, restartujte Windows před dalším testováním.

Užitečný krok: spusťte příkazy v tomto pořadí a zaznamenejte jakýkoli přesný kód chyby. Chyba z wsl --status je diagnosticky užitečnější než obecná zpráva Dockeru „Engine stopped“.

Běžné nedorozumění: přeinstalujte Ubuntu pro opravu Docker Desktop

Docker Desktop nevyžaduje konkrétní uživatelsky nainstalovanou linuxovou distribuci. Dokumentace WSL pro Docker uvádí, že příkazy Docker mohou fungovat z Windows bez nainstalované konkrétní linuxové distribuce; povolení integrace WSL pro Ubuntu, Debian nebo jinou distribuci je volitelné pro nativní linuxové pracovní postupy.

Užitečný krok: pokud se WSL sama spustí správně, nemažte funkční distribuci Ubuntu nebo Debian pouze kvůli opravě Docker Desktop.

Nepoužívejte wsl --unregister jako raný příkaz pro opravu

Microsoft výslovně varuje, že wsl --unregister <DistributionName> trvale odstraní data, nastavení a nainstalovaný software dané distribuce. Příkazy, které odregistrují distribuce WSL spojené s Dockerem nebo osobní distribuce, jsou tedy destruktivním řešením potíží, nikoli rutinními příkazy pro restart.

Užitečný krok: nejprve použijte wsl --shutdown. Před jakoukoli procedurou odregistrace, resetu, čištění nebo přeinstalování zálohujte důležitá data.

Fáze 3: Ověřte virtualizaci Windows a funkce WSL

AI ilustrace Funkcí Windows s povolenými Podsystémem Windows pro Linux a Platformou virtuálního stroje
AI generovaná ilustrace Funkcí Windows. Pro WSL 2 se zaměřte na Podsystém Windows pro Linux a Platformu virtuálního stroje; ostatní zaškrtávací políčka se mohou lišit podle konfigurace.

WSL 2 potřebuje podporu virtualizace. Microsoft uvádí, že WSL 2 vyžaduje funkci Platforma virtuálního stroje a podporu hardwarové virtualizace. Často kladené otázky Microsoftu o WSL také identifikují dvě požadované komponenty Windows pro WSL 2: Platforma virtuálního stroje a Podsystém Windows pro Linux. Podívejte se na Často kladené otázky Microsoftu o WSL a ruční kroky instalace WSL od Microsoftu.

Otevřete Zapnout nebo vypnout funkce systému Windows a ověřte, zda jsou tyto dvě funkce povoleny:

  • Podsystém Windows pro Linux
  • Platforma virtuálního stroje

Pokud byla některá z těchto funkcí zakázána, povolte ji a restartujte Windows.

Běžné nedorozumění: pro Docker Desktop s WSL 2 musí být povolena plná funkce Hyper-V

Plná klientská verze Hyper-V není totéž co komponenty virtualizace používané WSL 2. Microsoft vysvětluje, že WSL 2 používá podmnožinu architektury Hyper-V poskytovanou prostřednictvím Platformy virtuálního stroje. Plná verze Hyper-V není dostupná ve Windows Home, zatímco WSL 2 je podporována ve Windows Home, kde je WSL dostupná. Docker také považuje WSL 2 a Hyper-V za samostatné backendy.

Užitečný krok: pokud používáte backend WSL 2, nejprve ověřte WSL a Platformu virtuálního stroje, místo abyste slepě povolili každé zaškrtávací políčko spojené s Hyper-V.

Pokud vidíte chybu 0x80370102

Toto je konkrétnější vodítko než „Engine stopped“. Stránka řešení potíží s WSL od Microsoftu uvádí, že chyba 0x80370102 může znamenat, že požadovaná funkce virtualizace není dostupná. Microsoft doporučuje zkontrolovat Platformu virtuálního stroje, virtualizaci v BIOS/UEFI, podporu virtualizace procesoru a konfiguraci spuštění hypervizoru.

V okně PowerShellu s oprávněním správce můžete zkontrolovat nastavení spuštění hypervizoru:

bcdedit /enum | findstr -i hypervisorlaunchtype

Pokud explicitně hlásí hypervisorlaunchtype Off, pokyny Microsoftu pro řešení potíží uvádějí, že lze povolit pomocí:

bcdedit /set hypervisorlaunchtype Auto

Poté restartujte Windows. Podívejte se na průvodce řešením potíží s WSL od Microsoftu.

Užitečný krok: použijte tuto opravu konfigurace spouštění pouze tehdy, když vaše příznaky ukazují na virtualizaci nebo hypervizor. Neměňte nastavení spouštění pouze proto, že je Docker pomalý nebo selhal jeden kontejner.

Fáze 4: Zkontrolujte nastavení Dockeru, aktualizujte a shromáždi diagnostiku

AI ilustrace nabídky v oznamovací oblasti Docker Desktop s možnostmi Restart a Troubleshoot
AI generovaná ilustrace nabídky v oznamovací oblasti Docker Desktop; přesné rozložení nabídky se může lišit mezi vydáními Docker Desktop.

Pokud se WSL spustí normálně, ale Docker Desktop stále ne, vraťte se zpět na vrstvu Dockeru.

Potvrďte, že používáte zamýšlený backend

Pro linuxové kontejnery dokumentace WSL pro Docker uvádí, že Docker Desktop používá engine WSL 2, když je tento backend povolen. V závislosti na aktuální verzi Docker Desktop a podporovaném systému může být nastavení „Use WSL 2 based engine“ povoleno ve výchozím nastavení a nemusí být viditelné.

Pokud chybí Settings > Resources > WSL Integration a očekávali jste integraci linuxových kontejnerů, Docker poznamenává, že Docker Desktop může být v režimu kontejnerů Windows. V takové situaci se vraťte ke kontejnerům Linux, pokud jsou to ty, které zamýšlíte spouštět.

Užitečný krok: neměňte režim kontejnerů pouze jako náhodný krok při řešení potíží. Potvrďte, zda váš projekt skutečně používá linuxové nebo windows kontejnery.

Aktualizujte Docker Desktop

Použijte sekci Software updates v Docker Desktop nebo aktuální instalační program z oficiální instalační stránky Dockeru pro Windows. Poznámky k vydání Dockeru často zahrnují opravy a známé problémy specifické pro Windows a WSL, takže stojí za to je zkontrolovat, když problém začne okamžitě po upgradu. Podívejte se na poznámky k vydání Docker Desktop.

Užitečný krok: před aktualizací si poznamenejte aktuální verze Docker Desktop a WSL. Pokud nedávné poznámky k vydání popisují váš přesný příznak, postupujte podle zdokumentovaného řešení, místo abyste aplikovali nesouvisející příkazy registru nebo mazání WSL.

Spusťte diagnostiku před továrním resetem

Nabídka Troubleshoot v Docker Desktop může shromáždit diagnostické informace, i když má aplikace problémy se spuštěním. Docker také dokumentuje:

docker desktop diagnose

Dokumentace CLI Docker Desktop uvádí, že příkaz diagnose je dostupný od Docker Desktop 4.60 a novějších. Pokud vaše nainstalovaná verzi tento příkaz nepodporuje, použijte rozhraní Troubleshoot nebo zdokumentovanou cestu ke spustitelnému souboru com.docker.diagnose od Dockeru.

Užitečný krok: uložte ID diagnostiky a zachyťte přesnou chybu při spuštění před resetováním čehokoli. Tento důkaz je užitečný, pokud potřebujete porovnat logy, vyhledat aktuální známý problém nebo otevřít případ podpory.

Resetujte Docker Desktop až po zálohování dat

Nabídka Troubleshoot v Dockeru zahrnuje Clean up data a Reset to factory defaults. Jedná se o možnosti poslední záchrany, nikoli o rutinní opravy. Dokumentace zálohování Dockeru doporučuje zálohovat důležité obrazy, svazky a data VM Docker Desktop před přeinstalací nebo resetem, pokud se Docker Desktop nemůže normálně spustit. Podívejte se na průvodce zálohováním a obnovením Dockeru.

Když démon stále funguje dostatečně na to, aby bylo možné používat příkazy Docker, zachovejte to, co je důležité, před resetem. Například důležité obrazy lze nahrát do registru nebo uložit do archivu tar. Data svazků potřebují vlastní strategii zálohování.

Pokud se Docker Desktop vůbec nespustí, Docker dokumentuje proceduru pro Windows pro zálohování virtuálního disku Docker Desktop před přeinstalací. Postupujte podle aktuální oficiální cesty z průvodce zálohováním, protože interní rozložení úložiště Dockeru se může mezi vydáními měnit.

Užitečný krok: neklikejte na Reset to factory defaults, dokud nedokážete odpovědět na otázku: „Kde je jediná kopie mých důležitých dat svazků?“

Kdy má smysl přeinstalovat Docker Desktop

Přeinstalace je rozumná poté, co jste zjistili, že:

  • WSL je sama o sobě zdravá a aktuální.
  • Požadavky na virtualizaci jsou splněny.
  • Normální restart Docker Desktop stále selhává.
  • Diagnostika neodhalila jednodušší opravu konfigurace.
  • Důležitá lokální data Dockeru byla zálohována nebo jsou reprodukovatelná.

Použijte aktuální instalační program od Dockeru, nikoli starý instalační program uložený z předchozího návodu. Aktuální instalační dokumentace Dockeru pro Windows také rozlišuje režimy instalace pro jednotlivé uživatele a pro všechny uživatele. Backend WSL 2 pokrývá většinu uživatelů, zatímco backend Hyper-V a kontejnery Windows mají různé požadavky na instalaci a oprávnění.

Užitečný krok: pokud při přeinstalaci změníte režim instalace nebo backend, měňte jednu proměnnou najednou, abyste mohli zjistit, co problém skutečně vyřešilo.

Co když Docker funguje v Windows Terminal, ale ne uvnitř Ubuntu?

To je obvykle otázka integrace, nikoli důkaz, že je engine Dockeru zastaven. Docker uvádí, že integraci WSL lze povolit pro vybrané distribuce WSL 2 v Settings > Resources > WSL Integration. Uživatelská distribuce sama o sobě musí běžet v režimu WSL 2.

Zkontrolujte to pomocí:

wsl -l -v

Pokud je uživatelská distribuce stále na WSL 1, Microsoft dokumentuje konverzi pomocí:

wsl --set-version <DistributionName> 2

Microsoft varuje, že konverze velkých distribucí může trvat dlouho a může selhat, takže před hlavní konverzí WSL zálohujte důležité soubory.

Užitečný krok: rozlišujte mezi „Démon Dockeru je vypnutý“ a „Tato distribuce WSL nemůže přistupovat k Dockeru“. Jedná se o různé problémy a neměly by spouštět stejné kroky opravy.

Co když je samotný stroj virtuálním strojem?

Pokud Windows 11 běží uvnitř VMware, Hyper-V, Azure nebo jiného hypervizoru, WSL 2 může vyžadovat zanořenou virtualizaci – virtualizaci vystavenou přes vnější virtuální stroj hostovi Windows. Microsoft dokumentuje požadavky na zanořenou virtualizaci a uvádí, že podpora závisí na hostitelské platformě a konfiguraci.

Užitečný krok: pokud se jedná o firemní VDI nebo cloudový VM, potvrďte podporu zanořené virtualizace s administrátorem platformy, než strávíte čas přeinstalací Docker Desktop.

Bezpečné pořadí oprav, které si můžete ponechat

  1. Restartujte Docker Desktop a otestujte pomocí docker version.
  2. Spusťte wsl --version a wsl --status.
  3. Spusťte wsl --update, poté wsl --shutdown a zkuste Docker znovu.
  4. Pokud WSL sama selže, ověřte Podsystém Windows pro Linux, Platformu virtuálního stroje a virtualizaci v BIOS/UEFI.
  5. Pokud máte chybu specifickou pro virtualizaci, jako je 0x80370102, postupujte podle cíleného řešení potíží s WSL od Microsoftu.
  6. Pokud je WSL zdravá, ověřte backend/režim kontejnerů Dockeru a aktualizujte Docker Desktop.
  7. Shromáždi diagnostiku Dockeru a zkontrolujte aktuální poznámky k vydání.
  8. Zálohujte důležitá data před operacemi čištění, resetu, odregistrace nebo přeinstalování.

Závěr

„Docker Desktop Engine Stopped“ je příznak, nikoli jediná diagnóza. Na Windows 11 s backendem WSL 2 je nejbezpečnější cestou k opravě restartovat Docker, ověřit a aktualizovat WSL, potvrdit virtualizaci pouze pokud WSL hlásí související selhání a shromáždit diagnostiku Dockeru před použitím destruktivních možností resetu.

Dvě nejdůležitější chyby, kterým je třeba se vyhnout, jsou stejně jednoduché: nepředpokládejte, že zastavená služba Dockeru ve Windows je příčinou na každém nastavení WSL 2, a neodregistrujte distribuce WSL nebo neprovádějte tovární reset Dockeru před zálohováním dat. Tyto kroky mohou proměnit problém se spuštěním na problém se ztrátou dat, aniž by řešily původní příčinu.

Zanechat komentář

Jak opravit chybu „ENOSPC: Dosažen systémový limit pro hlídače souborů“ v Linuxu

Jak opravit chybu „ENOSPC: Dosažen systémový limit pro hlídače souborů“ v Linuxu

Opravte chyby hlídače souborů ENOSPC v systému Linux kontrolou limitů inotify, nalezením procesů s vysokou mírou zátěže hlídače, bezpečným zvýšením limitů a trvalým uložením změn.

How to Fix "Tailwind CSS Styles Not Updating" in a Vite React App

How to Fix "Tailwind CSS Styles Not Updating" in a Vite React App

Fix Tailwind CSS styles not updating in Vite React by checking Tailwind v4 setup, CSS imports, source detection, dynamic classes, HMR, and stale caches.

Jak opravit ModuleNotFoundError: V Pythonu 3 neexistuje modul s názvem 'pip'

Jak opravit ModuleNotFoundError: V Pythonu 3 neexistuje modul s názvem 'pip'

Oprava chyby ModuleNotFoundError v Pythonu 3 pro PIP na Windows, macOS a Linuxu pomocí ensurepip, balíčků operačního systému, virtuálních prostředí a kontrol interpretů.

Jak opravit chybu „Oprávnění odepřeno (veřejný klíč)“ v GitHub SSH

Jak opravit chybu „Oprávnění odepřeno (veřejný klíč)“ v GitHub SSH

Opravte chybu „Oprávnění GitHub SSH odepřeno (veřejný klíč)“ kontrolou hostitele, aktivního klíče SSH, účtu GitHub, autorizace SSO, vzdálené adresy URL a přístupu na port 22.

Jak opravit chybu „Git Push Rejected: Non-FastForward“ bez ztráty změn

Jak opravit chybu „Git Push Rejected: Non-FastForward“ bez ztráty změn

Bezpečně opravte push chybu v Gitu, která neumožňuje rychlé přehrávání. Chraňte lokální práci, načítejte vzdálené commity, vyberte sloučení nebo rebase, vyřešte konflikty a pushujte bez ztráty změn.

Jak opravit chybu „Nginx 502 Bad Gateway“ při proxyování k Node.js

Jak opravit chybu „Nginx 502 Bad Gateway“ při proxyování k Node.js

Opravte chyby Nginx 502 Bad Gateway s upstreamem Node.js kontrolou portu aplikace, protokolů NGINX, adresy proxy_pass, sítě kontejnerů, časových limitů a opětovného načtení.

Jak opravit chybu „Typ 'null' nelze přiřadit typu“ v TypeScriptu

Jak opravit chybu „Typ 'null' nelze přiřadit typu“ v TypeScriptu

Oprava chyby „Typ 'null' nelze přiřadit typu“ v TypeScriptu u sjednocovacích typů, zúžení, výchozích hodnot a bezpečných asercí v rámci strictNullChecks.

Jak opravit chybu „Prisma Client Has Not Been Generated Yet“

Jak opravit chybu „Prisma Client Has Not Been Generated Yet“

Opravte chybu nevygenerovaného Prisma Client kontrolou generátoru, schématu, výstupní cesty, importů, verzí, nastavení monorepa a kroků sestavení při nasazení.

Jak opravit chybu „ERR_MODULE_NOT_FOUND“ v importech Node.js ESM

Jak opravit chybu „ERR_MODULE_NOT_FOUND“ v importech Node.js ESM

Opravte chybu Node.js ERR_MODULE_NOT_FOUND v ESM kontrolou cest importu, přípon souborů, instalace balíčků, exportů, režimu ESM a čistých instalací.

Jak opravit problém se SSL certifikátem: Nelze získat lokální certifikát vydavatele v Gitu

Jak opravit problém se SSL certifikátem: Nelze získat lokální certifikát vydavatele v Gitu

Opravte chybu Gitu 'nelze získat lokální certifikát vydavatele' identifikací důvěryhodného backendu, instalací správného řetězce CA a ponecháním ověřování SSL zapnutého.