Fourteen failures, grouped by where they come from. Each one starts with the symptom you will actually see on screen, then why it happens, then the command that ends it. All of these happened on a real machine here before they got written down.
You are on Docker Desktop 4.74.0, which has a Windows only regression. Several internal services try to listen on malformed socket paths that mix a Unix scheme with a Windows path. Each one fails in turn, you get an unexpected error dialog, and the Linux backend never comes up.
Stop Docker, switch off the AI feature in the settings store, clear the zombie socket, then go back to 4.73.1. Re running the installer does the downgrade and the AI disable for you.
# set "EnableDockerAI": false in %APPDATA%\Docker\settings-store.json # clear the zombie socket file PS> wsl -- rm -f /mnt/c/Users/$env:USERNAME/AppData/Local/Docker/run/dockerInference # then let the installer pin the version back PS> .\install.ps1
Docker Desktop is sitting behind a first run dialog waiting on you. License acceptance or a telemetry consent screen, usually. The daemon never comes online so the installer keeps waiting.
Open Docker Desktop by hand from the Start menu, click through whatever it is asking, then re run install.ps1.
Docker Hub login is optional. The installer prints a warning and carries on. All you lose is the higher pull rate limit that comes with being signed in, which in practice rarely matters for these images.
Press Ctrl and C at the restart prompt. Nothing is left in a broken state. Reboot whenever you can, then run install.ps1 again. The script is idempotent and resumes rather than starting over.
wsl --update is flaky over a poor link. Re run the installer. It picks up from where it stopped and the step is safe to repeat.
The installer warns and continues, because Tailscale is only needed if you want the sibling machine tunnels. Install it by hand from tailscale.com after the script finishes, then run tailscale up once.
The master key on this machine does not match the public recipient the vault was encrypted to. Secrets in this repo are encrypted at rest, and the master key is the only thing that opens them.
Either restore the correct key from your password manager or backup, or delete the encrypted files and let the installer fall back to a fresh env file and a newly generated SSH key. Back that master key up somewhere off the machine. If it is gone, the vault is gone with it.
The image is private or the namespace is wrong. Sign in to the registry with a token that carries the read:packages scope, then pull again. For any other image, check the repo namespace in the compose file before assuming it is an auth problem.
PS> docker login ghcr.io PS> docker compose --profile mission-control up -d
This is the one people trip on most. The dashboard container joins the gateway's network namespace directly and caches the original container ID. If you recreate the gateway on its own, the dashboard is left pointing at a namespace that no longer exists and just retries forever.
Never recreate the gateway alone. Use the wrapper, which recreates both together.
# do not do this PS> docker compose up -d --force-recreate openclaw # do this PS> .\scripts\recreate-openclaw.ps1
The operator allowlist is empty, so the bot is refusing everybody. That is the safe default and it is working as intended. Take the numeric ID out of that message, or get it from @userinfobot, and write it into the allowlist.
PS> $id = "<your-telegram-numeric-id>" PS> '{"channels":{"telegram":{"accounts":{"default":{"allowFrom":["' + $id + '"]}}}}}' | docker exec -i belken-openclaw openclaw config patch --stdin
Re running install.ps1 also works. Its Telegram step prompts for the ID again.
The sidecars run as a non root user but their named profile volumes come up owned by root, so the very first write fails. The installer fixes ownership after the containers are up, and this happens when that block ran before the containers were ready.
Re running the installer is safe, since the fix is idempotent and only does anything on a fresh volume. Or do it by hand.
PS> foreach ($c in 'belken-browser-ken','belken-browser-lucy','belken-browser-youtube') {
docker exec -u 0 $c chown -R 999:999 /data
}
Confirm nvidia-smi works from PowerShell first. If it does not, the Windows driver is the problem, not Docker. Install a current NVIDIA driver and reboot. Docker Desktop's WSL2 backend picks up GPU support automatically once the Windows side is healthy, so there is no separate container toolkit to install.
Do not guess at this one. Run the crash analysis script from an elevated shell. It reads the Windows minidumps and prints the faulting driver, which turns a vague stability problem into a named component.
Three culprits cover almost every case. nvlddmkm.sys means the NVIDIA driver, and for AI workloads pick the Studio driver over the Game Ready one. vmm.sys points at Hyper V or Docker Desktop. ntoskrnl.exe usually means memory, so run a memory test and check Event Viewer for antivirus or disk errors.
PS> .\scripts\analyze-crashes.ps1 Caused By Driver nvlddmkm.sys
The installer warns but does not fail, because a slow first start is normal on a cold disk. Wait another minute and check again. If it is still unhealthy, read the container log before touching anything else.
PS> docker inspect --format='{{.State.Health.Status}}' belken-postgres PS> docker logs belken-postgres
Collect these four outputs before you ask anyone anything. Between them they answer most of the questions a first reply would have asked you, which usually saves a full round trip.
PS> docker compose ps PS> docker compose logs --tail=200 PS> wsl --version PS> docker version
Hit something that is not on this page. Tell us and it goes on it.