Docker Desktop WSL2 VM Unexpectedly Exited: Fixes

The email hit at 14:47 on a Tuesday. Production deploy frozen. Twelve developers staring at the same modal: “Docker Desktop WSL2 VM unexpectedly exited.” I assumed memory pressure. Docker Desktop 4.21, 32GB RAM, nothing exotic. wsl --shutdown brought it back. Twenty minutes later, same crash. The actual culprit? CrowdStrike Falcon had pushed a sensor update at 14:30 that changed its WSL2 hook behavior. Two hours of collective downtime because I chased the wrong ghost.

That modal lies. It tells you the VM exited. It doesn’t tell you why the kernel terminated, and the gap between those two facts is where you’ll spend your afternoon.

⚡ TL;DR — Key takeaways

• Most “unexpected exits” are triggered by external processes—Windows updates, security tools, or manual `wsl –shutdown`—not Docker bugs.
• Resource exhaustion often manifests as VM exit rather than clean OOM, especially with default WSL2 memory limits.
• Antivirus real-time scanning of `%LOCALAPPDATA%\Docker\wsl` causes kernel panics that Docker Desktop cannot distinguish from crashes.
• The fix sequence matters: restart WSL2 first, check logs second, reset data only as last resort.
• Docker Desktop logs in `%APPDATA%\Docker\log` and WSL2 logs via `dmesg` contain the actual termination reason, not the dashboard.

📋

Before you start: Windows 10 version 2004+ or Windows 11 Build 22000+, WSL2 with kernel 5.10.16.3+, Docker Desktop 4.12+, PowerShell 5.1 or 7.x with Administrator rights.

What Causes the Docker Desktop WSL2 VM to Exit Unexpectedly?

The “Docker Desktop WSL2 VM unexpectedly exited” error occurs when the WSL2 virtual machine backing Docker Desktop terminates prematurely. Common causes include Windows updates, antivirus interference, corrupted WSL2 images, and insufficient system resources. To fix it, you can restart WSL2, reset Docker Desktop data, update WSL2 and Docker Desktop, or configure antivirus exceptions. Persistent issues may require checking virtualization settings and system logs.

That paragraph is what the search results regurgitate. Here’s what actually happens.

Docker Desktop doesn’t run containers directly on Windows. It spawns a WSL2 distribution—docker-desktop or docker-desktop-data—which hosts the Linux kernel and container runtime. When that kernel stops, Docker Desktop loses its backend. The dashboard catches this as a generic VM exit because WSL2’s termination signal doesn’t carry a detailed reason code through the Windows-WSL boundary.

Immediate Triggers

The fastest way to kill it is running wsl --shutdown yourself. I do this habitually when switching projects. It terminates all WSL2 instances immediately. Docker Desktop detects the loss and throws the exit error. Same with Windows Update: KB5034441 and similar patches occasionally restart the LxssManager service, which drops active WSL2 sessions without warning. You’ll see the error on first Docker command after update completion.

Windows Defender’s real-time protection is more subtle. When it scans %LOCALAPPDATA%\Docker\wsl\data\ext4.vhdx—the WSL2 virtual disk—while Docker has it mounted, the kernel hits a filesystem panic. In my CrowdStrike incident, the sensor’s WSL2 hook (introduced in sensor version 7.05) deadlocked with Docker’s networking stack. The kernel didn’t crash. It was terminated by the security tool’s watchdog. Docker Desktop just saw a vanished VM.

Underlying System Issues

Memory pressure is the silent killer. WSL2 defaults to 50% of total RAM. With 16GB physical, that’s 8GB. Run a few Java containers locally and you’ll hit the limit. WSL2’s OOM handler is brutal: it SIGKILLs the heaviest process, often dockerd, which triggers a VM exit rather than a graceful shutdown. I hit this with a local Elasticsearch cluster in 2022. P99 on my dev API went from 40ms to timeouts. The fix was a .wslconfig with explicit memory and swap limits.

Corruption in the ext4 filesystem backing docker-desktop-data also causes exits on mount. This happens after hard shutdowns or when antivirus quarantines part of the VHDX. The kernel aborts boot, Docker Desktop retries three times, then gives up with the exit error. In these cases, the logs show EXT4-fs error before the VM disappears. I learned to read %APPDATA%\Docker\log\vm\lifecycle-server.log before touching any reset buttons.

My take: Docker Desktop’s error messaging is technically accurate and practically useless. The VM did exit. What you need to know—whether it was killed, crashed, or starved—is buried in WSL2 logs that most engineers never check. The dashboard should surface dmesg tail on failure. It doesn’t. Until that changes, you’re doing forensics on a black box that Microsoft, Docker, and your security vendor each insist isn’t their problem.

Quick Fixes: Restart and Reset Procedures

Most engineers reach for the big red button too soon. I’ve been there. Last March, I spent forty minutes rebuilding a WSL2 distro when wsl --shutdown would have fixed it in eight seconds. Here’s the sequence that actually works, in order of destructiveness.

Restart WSL2 and Docker Desktop

Start with the gentle option. The WSL2 VM can hang without fully dying—Docker Desktop reports it as “exited” but what’s really happened is a kernel thread stuck in uninterruptible sleep. Windows can’t tell the difference.

Close Docker Desktop completely. Not just the window—right-click the whale icon, choose Quit. Then open an elevated PowerShell:

wsl --shutdown
wsl --unregister docker-desktop
wsl --unregister docker-desktop-data

Wait thirty seconds. Windows needs time to release the VHDX file handles. I’ve seen engineers restart immediately and hit “access denied” errors because the filesystem was still syncing.

Now restart Docker Desktop. It’ll recreate the WSL2 backing distros automatically. This preserves your images and volumes. Takes about ninety seconds on my machine with an NVMe drive. HDD users: go get coffee.

If the crash repeats immediately, check docker context ls. You want desktop-linux with a * and wsl2 backend. Wrong context means Docker’s talking to a dead Hyper-V VM from 2021. Delete stale contexts:

docker context rm -f desktop-linux-old
docker context use desktop-linux

Reset Docker Desktop to Factory Defaults

When restart fails, reset. But know what you’re destroying.

Docker Desktop’s factory reset wipes:

• All containers (running and stopped)
• All images
• All volumes—including named volumes you forgot existed
• Your .docker/config.json authentication

It does not touch:

• Files in bind mounts (your code)
• WSL2’s global .wslconfig

I learned this distinction the hard way in 2023. Reset cleared a PostgreSQL volume I’d been using for integration tests. No backup. Three hours of fixture regeneration.

Before resetting, export anything you need:

docker run --rm -v my_postgres:/volume -v ${PWD}:/backup alpine tar czf /backup/postgres-backup.tar.gz -C /volume .

Then: Settings → Troubleshoot → Reset to factory defaults. Docker Desktop will restart twice. First boot rebuilds the VM. Second boot initializes the backend.

Choose restart when: The error is intermittent, or started after a Windows update, or Docker Desktop was running fine yesterday.

Choose reset when: You’ve tried restart twice, or docker ps hangs indefinitely, or logs show corrupt overlay2 errors.

Update Windows, WSL2, and Docker Desktop

Version mismatches between these three components cause more exits than you’d expect. Docker Desktop 4.12 introduced a hard requirement: WSL2 kernel 5.10.16.3 or later. Run older kernel + newer Docker Desktop = instant crash on container start. I watched this happen across my team in June 2022. Five identical laptops, three worked, two didn’t. The difference was kernel versions.

Check Your WSL2 Version

Don’t trust Windows Update to handle this. WSL2’s kernel ships separately from the rest of Windows.

wsl --version

You’re looking for three numbers:

• WSL version: 2.0.14+ for Windows 11, 1.2.5+ for Windows 10
• Kernel version: 5.15.146.1+ (current as of early 2025)
• WSLg version: Any number means graphics support is present

If wsl --version errors with “unknown option,” you’re on WSL1 or an ancient build. Update immediately through the Microsoft Store, not Windows Update.

For the kernel specifically, check %SystemRoot%\system32\lxss\tools\kernel:

Get-ItemProperty "$env:SystemRoot\system32\lxss\tools\kernel" | Select-Object VersionInfo

Version should read 5.15.x or higher. Docker Desktop 4.12+ will silently fail with kernel 5.4.x from 2020.

Update WSL2 through the Microsoft Store app, then:

wsl --update
wsl --shutdown

Restart Docker Desktop after this. The new kernel loads on next WSL2 start.

Update Docker Desktop

Docker Desktop has three channels: Stable, Edge (now “Dev”), and specific version downloads from Docker Hub. I run Stable for production machines, Dev for my test laptop. Dev found a WSL2 networking regression two weeks before it hit Stable. Worth it.

Check your current version: whale icon → About Docker Desktop. Compare against Docker’s release notes. Versions 4.25 through 4.28 had specific fixes for WSL2 VM lifecycle bugs.

Update through Settings → Software Updates, or download the MSI directly if the auto-updater is stuck. I’ve seen the auto-updater fail when Docker Desktop’s backend is crashed—ironic, since that’s when you need the update most.

After updating, verify the WSL2 backend is selected: Settings → General → “Use the WSL 2 based engine.” The Hyper-V fallback still exists for legacy reasons. Accidentally enabling it causes “unexpected exit” errors that look identical to WSL2 crashes but need entirely different fixes.

Configure Antivirus and Windows Firewall Exceptions

Security tools love to “help” by terminating Docker’s processes. CrowdStrike was my nemesis, but Windows Defender causes plenty of exits too. The pattern is distinctive: Docker Desktop runs fine for ten to sixty minutes, then the VM vanishes. No error in Docker’s logs. The security tool’s logs show a “suspicious process termination” at the exact same timestamp.

Adding Docker Desktop Exceptions

Start with file paths. Docker Desktop stores its WSL2 data in %LOCALAPPDATA%\Docker\wsl. Antivirus real-time scanning on this directory causes I/O deadlocks during image pulls. Exclude:

%LOCALAPPDATA%\Docker
%PROGRAMFILES%\Docker
%LOCALAPPDATA%\Docker Desktop
%SystemRoot%\System32\lxss\tools

Add process exclusions too. The critical ones are:

• Docker Desktop.exe
• com.docker.backend.exe
• com.docker.service
• wsl.exe
• wslservice.exe

For Windows Defender: Windows Security → Virus & threat protection → Manage settings → Add or remove exclusions. Add folder exclusions first. Process exclusions second.

Third-party tools vary. CrowdStrike uses Prevention Policies with “Sensor Operation Mode” settings. You need an exclusion for dockerd in user-mode. McAfee requires “On-Access Scanner” exclusions by path. Symantec needs separate entries for Auto-Protect and SONAR. Check your corporate policy—some security teams block these exclusions. I spent a week arguing with InfoSec before they accepted that scanning every layer of a 2GB container image on every read was unusable.

Testing Firewall Rules

Windows Firewall blocks Docker’s internal networking by default. The symptom is subtle: containers start, but can’t reach the internet or each other. Then Docker Desktop’s health checks fail, and the backend stops.

Test connectivity from inside a container:

docker run --rm alpine:latest sh -c "ping -c 3 8.8.8.8 && wget -qO- https://httpbin.org/get"

Failure here means network isolation, not VM exit. But network failures cascade. Docker’s internal DNS (127.0.0.11) times out, health checks fail, and the backend terminates the VM as “unhealthy.”

Check Windows Firewall rules for Docker:

Get-NetFirewallRule | Where-Object { $_.DisplayName -like "*Docker*" } |
    Select-Object DisplayName, Enabled, Profile, Direction, Action

You should see Allow rules for Docker Desktop Backend and vpnkit-bridge. Missing rules happen after Windows updates. Docker Desktop reinstalls them on startup, but only if it has admin rights. Run as administrator once after any major Windows update.

For corporate networks with forced tunneling, add explicit allow rules for Docker’s subnet (usually 172.17.0.0/16 and 192.168.65.0/24). VPN clients like Zscaler or Palo Alto GlobalProtect sometimes capture these ranges. The VM exits when its networking stack can’t reconcile Docker’s bridge with the VPN’s virtual adapter.

I debugged this for a teammate in 2023. Her Docker Desktop crashed every time she connected to corporate VPN. The VPN client was injecting routes that overlapped with Docker’s internal networking. We moved Docker to 172.30.0.0/16 in daemon.json and the exits stopped.

Check Virtualization and System Resources

Hardware lying about its capabilities is more common than you’d think. I once burned a day chasing a Docker Desktop crash that turned out to be virtualization disabled after a BIOS update. The VM started, allocated memory, then died silently when the hypervisor call failed.

Enable Virtualization in BIOS/UEFI

Windows Pro and Enterprise ship with Hyper-V. Windows Home uses Microsoft’s “Virtual Machine Platform” instead. Both require CPU virtualization extensions: Intel VT-x or AMD-V.

Verify in PowerShell:

$cpu = Get-WmiObject -Class Win32_Processor
$cpu.VirtualizationFirmwareEnabled

True means the BIOS reports virtualization enabled. False means enter firmware setup and look for “Intel Virtualization Technology,” “SVM Mode,” or “AMD-V.” Disable “Hyper-V” first if you’re switching between Type-1 and Type-2 hypervisors—running VMware Workstation alongside WSL2 causes exactly the “unexpectedly exited” error we’re fixing.

Windows 11 Build 22000+ requires additional security features that complicate this. “Memory Integrity” in Core Isolation uses virtualization for its own hypervisor, which can conflict with WSL2’s allocation. Check status:

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object VirtualizationBasedSecurityStatus, HypervisorEnforcedCodeIntegrityStatus

VirtualizationBasedSecurityStatus of 2 means running and healthy. 0 means disabled—fine for Docker, but check your org’s security policy before turning features off.

flowchart TD
    A[Check CPU virtualization] --> B{BIOS enabled?}
    B -->|No| C[Enter BIOS/UEFI setup]
    B -->|Yes| D{Windows version}
    C --> E[Enable VT-x/AMD-V]
    D -->|Win 11| F[Check Memory Integrity]
    D -->|Win 10| G[Verify Hyper-V installed]
    F --> H{Conflict?}
    H -->|Yes| I[Disable Memory Integrity]
    H -->|No| G
    E --> D
    I --> J[Reboot and test]
    G --> J

Monitor Resource Usage

WSL2’s VM takes 50% of your RAM by default. I hit this limit running integration tests against Postgres, Redis, and Elasticsearch simultaneously. The kernel OOM killer terminated the VM, Docker Desktop reported “unexpectedly exited,” and I lost an hour before checking .wslconfig.

Create or edit %USERPROFILE%\.wslconfig:

[wsl2]
memory=8GB
processors=4
swap=2GB
swapFile=C:\\temp\\wsl-swap.vhdx
localhostForwarding=true

Without this file, WSL2 grows until Windows says no. The default swap is disk-backed and slow—set an explicit path on fast storage. I’ve seen VMs exit when Windows Update triggers a disk cleanup that fills the temp drive.

Disk space matters too. Docker Desktop stores WSL2 data in %LOCALAPPDATA%\Docker\wsl. My teammate’s VM crashed weekly until we found her 256GB drive had 4GB free. WSL2’s ext4.vhdx needs headroom to expand—20GB minimum, 50GB comfortable for active development.

Check current allocation:

Get-ChildItem -Path "$env:LOCALAPPDATA\Docker\wsl" -Recurse | Measure-Object -Property Length -Sum
$wslSize = (Get-ChildItem -Path "$env:LOCALAPPDATA\Docker\wsl" -Recurse | Measure-Object -Property Length -Sum).Sum / 1GB
Write-Host "WSL2 data occupies: $([math]::Round($wslSize, 2)) GB"

If you’re regularly hitting resource limits, my guide on optimizing Node.js Docker images can help reduce what you’re pulling into that constrained space.

---

Advanced Diagnostics: Logs and Error Messages

Generic error messages waste everyone’s time. “The virtual machine unexpectedly exited” tells you nothing. The logs underneath tell you everything—if you know where to look.

Reading Docker Desktop Logs

Docker Desktop logs live in %APPDATA%\Docker\log. On my machine that’s C:\Users\nilesh\AppData\Roaming\Docker\log. The files rotate, so check timestamps.

The key file is vm\VirtualMachine-*.log. Look for lines containing [fatal] or panic. I found this pattern in a crash from March 2024:

[2024-03-15T03:42:11.123Z] [fatal] com.docker.backend.exe: failed to create VM: rpc error: code = Unknown desc = failed to create shim: hcs::CreateComputeSystem: The virtual machine could not be started because a required feature is not installed.

“Required feature” meant Hyper-V was disabled by a Windows update that reverted my optional features. Re-enabling it fixed the exit.

Search recent logs efficiently:

$logPath = "$env:APPDATA\Docker\log"
Get-ChildItem -Path $logPath -Recurse -Filter "*.log" |
    Sort-Object LastWriteTime -Descending |
    Select-Object -First 5 |
    ForEach-Object {
        Write-Host "`n=== $($_.Name) ===" -ForegroundColor Cyan
        Get-Content $_.FullName -Tail 50 | Select-String -Pattern "fatal|panic|error|failed" -CaseSensitive:$false
    }

com.docker.backend.exe.log contains the high-level flow. host\host.log shows WSL2 integration events. Cross-reference timestamps between files—events in one log often explain crashes logged in another.

WSL2 Diagnostic Commands

WSL2 itself can fail before Docker Desktop knows about it. The wsl --system flag (added in WSL 2023 updates) gives you the WSL2 VM’s view of its own health.

Shut down WSL2 completely first to clear state:

wsl --shutdown

Then restart with debugging:

# To get a shell in the docker-desktop distro:
wsl -d docker-desktop -e sh

This drops you into a minimal Alpine environment running the actual WSL2 VM. Check kernel messages for OOM kills or filesystem errors:

dmesg | tail -50 | grep -E "(Out of memory|Killed process|EXT4-fs error)"

I found Killed process 1234 (dockerd) total-vm:4201234kB, anon-rss:3912345kB here once. The numbers confirmed my OOM theory—WSL2’s default memory limit was too low for our workload.

Check WSL2 kernel version against Docker Desktop’s requirements:

wsl --version

Docker Desktop 4.12+ needs kernel 5.10.16.3 or newer. I saw exits on a machine with 5.4.72 because the networking stack lacked features Docker assumed present. Update through Microsoft Store’s “WSL” app, not wsl --update alone—the latter sometimes lags.

Event Viewer catches what WSL2 and Docker miss. Filter Applications and Services Logs > Microsoft-Windows-Hyper-V-Compute/Admin for VM lifecycle events. Error 0xC0370106 means “The virtual machine could not be started”—usually missing virtualization or corrupted VHDX.

---

Common Error Messages and Their Solutions

Pattern matching beats guessing. These two error messages cover 80% of the “unexpectedly exited” reports I’ve handled.

WSL Distro Terminated Abruptly

The full error reads: “The WSL distro docker-desktop terminated abruptly.” This is WSL2’s way of saying the VM process died, not that Docker’s daemon crashed.

Causes:

• Kernel panic from OOM (check .wslconfig memory limits)
• Corrupted ext4.vhdx from unclean shutdown
• Antivirus locking the VHDX file during scan

Fix:

wsl --export docker-desktop "D:\backup\docker-desktop.tar"
wsl --unregister docker-desktop
# Create target directory first
New-Item -ItemType Directory -Force -Path "$env:LOCALAPPDATA\Docker\wsl\distro"
wsl --import docker-desktop "$env:LOCALAPPDATA\Docker\wsl\distro" "D:\backup\docker-desktop.tar" --version 2

Unregister destroys the VM. Import recreates it. I only do this after confirming the backup worked—wsl --list --verbose should show docker-desktop with version 2.

If the export fails with “The file cannot be accessed by the system,” your antivirus has locked the VHDX. Add %LOCALAPPDATA%\Docker\wsl\** to exclusions, reboot, retry.

Backend Stopped Unexpectedly

Docker Desktop’s own process crashed. The VM might be fine; Docker just can’t talk to it anymore.

Check if the backend actually stopped:

Get-Process "com.docker.backend" -ErrorAction SilentlyContinue
Get-Process "com.docker.proxy" -ErrorAction SilentlyContinue

Missing processes mean a crash. Check Windows Event Viewer Windows Logs > Application for `.NET runtime errors—Docker Desktop’s backend is C# and logs unhandled exceptions there.

Common fix: reset Docker Desktop’s internal state without destroying volumes:

Stop-Process -Name "com.docker*" -Force -ErrorAction SilentlyContinue
Remove-Item "$env:LOCALAPPDATA\Docker\pids\*" -Force -ErrorAction SilentlyContinue
Remove-Item "$env:LOCALAPPDATA\Docker\run\*" -Force -ErrorAction SilentlyContinue

This clears stale PID files and socket files that prevent clean restart. I scripted this after Docker Desktop 4.15 started leaving orphans on exit.

My take: Docker Desktop’s error messages are accurate but unhelpful by design. They don’t want to expose internals to casual users. But you’re debugging at 2am, not casually using anything. The logs are there, the patterns repeat, and once you’ve seen three of these crashes you start recognizing the signature before opening a file. Microsoft and Docker should surface WSL2’s dmesg and the backend’s fatal logs directly in the UI. Until then, PowerShell and grep are your UI.

The backend architecture I use for container orchestration in production follows patterns from my Sequelize repository pattern guide, where clear error boundaries and structured logging prevent exactly this kind of opaque failure mode.

Prevent Future Crashes: Best Practices

Crashes that wake you up at 2am usually share a signature: they happen after you’ve ignored something for weeks. Here’s what I actually do to keep Docker Desktop and WSL2 stable.

Regular Maintenance Routine

Treat WSL2 like you’d treat a production VM—because that’s what it is.

Weekly: Run wsl --update to catch kernel fixes. Docker Desktop 4.12+ requires WSL2 kernel 5.10.16.3+, and Microsoft ships patches without fanfare. Check your current version:

wsl --version

If the kernel line shows anything older than 5.10.16.3, update before Docker forces a cryptic failure.

Monthly: Export your docker-desktop-data and docker-desktop distributions. I keep three rotating backups in C:\wsl-backups\:

$date = Get-Date -Format "yyyy-MM-dd"
wsl --export docker-desktop-data "C:\wsl-backups\docker-desktop-data-$date.tar"
wsl --export docker-desktop "C:\wsl-backups\docker-desktop-$date.tar"

Each export runs about 8-12 minutes for a 60GB environment. I schedule this with Task Scheduler for Sunday 3am, when nothing’s running. The .tar files compress well—expect roughly 30% of your VHDX size.

Quarterly: Audit your .wslconfig. Memory pressure creeps up as projects accumulate. I review %UserProfile%\.wslconfig and adjust limits based on actual usage patterns from free -h inside WSL2.

Monitoring and Alert Setup

You can’t fix what you don’t see. I use a dead-simple PowerShell script that runs every 5 minutes via scheduled task:

$dockerBackend = Get-Process "com.docker.backend" -ErrorAction SilentlyContinue
$wslRunning = wsl --list --running 2>&1 | Select-String "docker-desktop"

if (-not $dockerBackend -or -not $wslRunning) {
    $timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    "$timestamp - Docker or WSL2 down" | Out-File "C:\logs\docker-failures.log" -Append

    # Send notification (Windows 11 native toast)
    Import-Module BurntToast -ErrorAction SilentlyContinue
    if ($?) {
        New-BurntToastNotification -Text "Docker Desktop Issue", "Backend or WSL2 not detected"
    }

    # Optional: attempt auto-restart
    # wsl --shutdown; Start-Sleep 5; Start-Process "C:\Program Files\Docker\Docker\Docker Desktop.exe"
}

The script logs to C:\logs\docker-failures.log and fires a toast notification. I disabled auto-restart after it masked a memory leak I needed to actually fix.

For resource monitoring, I keep wsl -d docker-desktop -e sh -c "dmesg | tail -20" in a terminal during heavy container workloads. OOM kills appear here before they surface in Docker Desktop’s UI.

My take: Most “unexpected” exits are actually expected if you’re paying attention. The WSL2 VM gives you roughly the observability of a black box with a few holes punched in it. Microsoft’s choice, not Docker’s. Until that changes, defensive exports and crude process monitoring beat reactive debugging every time. The patterns I use here mirror what I’ve written about in my Rust learning roadmap—explicit error handling and zero-trust assumptions about external state.

Frequently asked questions

How do I know if my Docker Desktop is using WSL2?

Open Docker Desktop Settings > Resources. If you see a “WSL Integration” tab with toggles for your distros, you’re on WSL2. The command-line check is faster: run wsl -l -v and look for docker-desktop and docker-desktop-data with VERSION 2. If they show VERSION 1, you’re somehow on WSL1 and should update before anything else breaks.Will resetting Docker Desktop delete my containers and images?

A full factory reset removes everything—containers, images, volumes, networks, the lot. I’ve lost hours of build cache this way. Before you reset, run docker save -o backup.tar image:tag for anything you can’t rebuild quickly. For volumes, I mount them to a temporary container and tar the contents. The Troubleshoot > “Clean / Purge data” option is gentler and lets you keep volumes while clearing everything else.Why does Docker Desktop work after reboot but crashes later?

This pattern screams resource exhaustion or scheduled interference. WSL2’s default memory limit is 50% of total RAM, and it doesn’t release memory back to Windows cleanly. Over hours of container churn, you hit the ceiling and the OOM killer terminates the VM. Check Event Viewer for Microsoft-Windows-Hyper-V-Worker/Operational entries. Also verify Windows Defender isn’t running a full scan—I’ve seen it trigger exactly 20 minutes after startup on multiple machines.

On Monday morning, I’d open PowerShell and run that wsl --version check, then verify my .wslconfig limits against actual container usage from last week. The export script would be running that night whether I remembered to think about it or not.

This approach has limits. If your crashes trace to Hyper-V itself—bsod under vmmem load, or firmware bugs in your particular laptop’s virtualization support—these fixes won’t touch it. You’ll need BIOS updates or a different machine. I hit this with a Dell XPS 13 9310 where every Windows patch cycle broke VT-x until I locked the firmware version.

What crashed for you? The docker-desktop distro, the backend process, or something weirder? Drop it in the comments with your Windows build number—I’ll read every one and update this if a new pattern emerges.