Windows arm64: enabling Docker VMM fails instantly — sailor.dll 0.118.0 missing exported symbol "sailor_vm_pause"; backend then waits for dockerd forever

Reproduce the Docker VMM startup failure on Windows arm64 and begin with the reported sailor.dll and com.docker.sailor.exe versions, backend logs, and settings-store.json recovery setting. Trace the sailor_vm_pause binding failure and the daemon readiness retry path; done means VMM starts, or unsupported VMM is blocked and failures surface with recovery to WSL2 instead of an indefinite spinner.

Bug description

On Windows on ARM (Snapdragon X Elite), switching the container engine from WSL2 to Docker VMM makes Docker Desktop unable to start a VM at all. The sailor process exits ~20 ms after launch because the bundled sailor.dll does not export a symbol the backend binds to:

[com.docker.backend.exe.engines] docker daemon not ready, continuing: context canceled
(cancel cause: sailor process terminated unexpectedly (exit status 1): creating VM: loading sailor:
sailor: failed to register symbol "sailor_vm_pause": The specified procedure could not be found.
(loaded libsailor reports version "0.118.0+9f348c0"; if the symbol is missing the dylib is likely
older than this binding — rebuild/repackage libsailor and the Go bindings from the same sailor commit))

The error message states its own diagnosis: the shipped libsailor is older than the Go binding compiled into com.docker.backend. Both files come from the same 4.89.0 installer and carry the same timestamp (28/08/2026), so this is not a partial or interrupted update on my side — it looks like a packaging mismatch in the Windows arm64 build.

The failure is silent in the UI. After sailor exits, the backend neither surfaces an error nor falls back to WSL2. It enters an unbounded retry loop:

[com.docker.backend.exe.enginedependencies] still waiting for docker daemon to be ready after 1m44.7575902s
[com.docker.backend.exe.ipc][W] (...) C<-S ConnectionClosed HEAD /_ping (1.0001859s): Head "http://ipc/_ping": context deadline exceeded

...repeating once per second indefinitely. docker info returns 500 Internal Server Error — the named pipe exists with nothing behind it. The GUI shows a permanent starting spinner and becomes unusable, so the setting cannot be reverted from the UI. Recovery requires killing the Docker processes and editing %APPDATA%\Docker\settings-store.json by hand to set "UseLibkrun": false.

Note that engines.sailor: VM started is logged 19 ms before the symbol failure, so the UI briefly indicates progress. In my backend logs, across five separate VMM attempts, engine linux/sailor is running and a sailor docker daemon ready never appear once — the VM never actually serves a daemon.

Reproduction steps

1. Windows 11 on ARM (Snapdragon X Elite), Docker Desktop 4.89.0, WSL2 backend working normally.
2. Enable beta features, then Settings → General → set the container engine to Docker VMM. (This also raises VM memory to 4096 MiB for the VMM 4 GB minimum.)
3. Apply & restart.
4. WSL2 shuts down cleanly, engine linux/sailor starts, then exits status 1 after ~20 ms with the symbol error above.
5. Docker Desktop never finishes starting; the backend loops on HEAD /_ping forever.

Reproduced 5/5 times, including from a clean restart with no leftover state.

Expected behavior

Either Docker VMM starts, or — if VMM is not supported on Windows arm64 — the option is hidden/disabled on this platform. In either case a failure to create the VM should surface as an error and fall back to the previously working engine, rather than an indefinite spinner that locks the user out of the setting that caused it.

Additional context

• C:\Program Files\Docker\Docker\resources\sailor.dll — FileVersion 0.118.0, 7,740,336 bytes, 28/08/2026 14:25:48
• C:\Program Files\Docker\Docker\resources\bin\com.docker.sailor.exe — 12,417,968 bytes, same timestamp
• Docker Desktop.exe — 4.89.0.238018, same timestamp
• The Docker VMM docs list Mac (Apple Silicon) and Windows but do not mention Windows on ARM; the toggle is nonetheless offered in the UI on this machine.
• Setting "UseLibkrun": false in %APPDATA%\Docker\settings-store.json restores a working WSL2 setup (daemon ready in ~7 s).
• Secondary and probably distinct: on the next launch after a VMM failure, the backend crashed once on the leftover sailor-ingest.sock with Win32 1920 ERROR_CANT_ACCESS_FILE, then self-restarted. That matches the already-open #631 on the same Windows build (26200). Mentioned only because the VMM failure is what leaves the stale socket behind.

Platform

Windows

Version information

Client:
 Version:           29.7.2
 API version:       1.55
 Go version:        go1.26.5
 Git commit:        a7dcaa6
 Built:             Thu Aug  6 10:36:32 2026
 OS/Arch:           windows/arm64
 Context:           desktop-linux

Server: Docker Desktop 4.89.0 (238018)
 Engine:
  Version:          29.7.2
  API version:      1.55 (minimum version 1.40)
  Go version:       go1.26.5
  Git commit:       6a43e3d
  Built:            Wed Aug  5 18:28:35 2026
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          v2.3.3
  GitCommit:        aad11006b869517fcd3009450b6f82da282e1a9b
 runc:
  Version:          1.4.3
  GitCommit:        v1.4.3-0-gbb14dabe
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

# Host
Windows 11 Pro ARM 64-bit, 25H2, build 26200.9168
CPU: Snapdragon(R) X 12-core X1E80100 @ 3.40 GHz (12 logical)
RAM: 31.6 GB
WSL version 2.7.13.0, kernel 6.18.33.2-2
Storage driver: overlayfs (containerd snapshotter enabled)

# NOTE
The output above is from the working WSL2 configuration. With Docker VMM
enabled no daemon ever starts, so `docker version` reports only the client
and `docker info` returns 500.