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

[Luligu]

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 Windows 11 build 26200: sailor-ingest.sock startup fails with ERROR_CANT_ACCESS_FILE; native AF_UNIX fails under LocalAppData #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.

[Luligu]

Tried with 4.90.0 and same issue:

Docker VMM could not start.

You can switch to another virtual machine manager to carry on working, or restart to try again.

If this keeps happening, [collect diagnostics and submit an issue](https://docs.docker.com/desktop/troubleshoot/overview/?utm_source=docker_desktop_error_dialog#diagnose-from-the-terminal).

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)

[Luligu]

4.90.0 (238679) — dumped the export tables, the gap is the whole VM snapshot API

Following up on my previous comment with the actual symbol diff, since it narrows this down further than the error string does.

com.docker.sailor.exe binds 5 symbols that sailor.dll does not export:

sailor_vm_checkpoint
sailor_vm_pause          <- fails first, hence the error message
sailor_vm_restore
sailor_vm_resume
sailor_vm_run_restored

The DLL exports only the old lifecycle set — sailor_vm_create / run / stop / wait / free / is_running / dial_*. So it isn't one stray symbol: the entire VM suspend/resume/checkpoint API is present in the Go binding and absent from the packaged libsailor. Everything else in the sailor_* namespace (config, fs, exec, dgram, compositor, metrics) matches exactly — the only delta between the two binaries is those five.

Both files ship from the same 4.90.0 installer with timestamps 12 seconds apart, so this is a build-pipeline pairing problem rather than anything installer- or machine-side:

• %LOCALAPPDATA%\Programs\DockerDesktop\resources\sailor.dll — FileVersion 0.118.0, 7,740,336 bytes, 04/09/2026 15:13:31
• %LOCALAPPDATA%\Programs\DockerDesktop\resources\bin\com.docker.sailor.exe — 12,418,992 bytes, 04/09/2026 15:13:44
• Docker Desktop.exe — 4.90.0.238679

Note the DLL is byte-identical in size to the 4.89.0 one I reported originally (7,740,336) while com.docker.sailor.exe grew from 12,417,968 to 12,418,992 — consistent with the binding advancing across releases while libsailor stayed pinned to 0.118.0+9f348c0.

Failure timing on this build: sailor starts at 15:32:47.899, logs starting VM at .917, dies at 15:32:48.004 — ~105 ms, during symbol registration, before any virtualization call. The indefinite-spinner behaviour from the original report is unchanged in 4.90.0.

[Luligu]

Correction: it is not version skew. The amd64 and arm64 sailor.dll are the same sailor commit — arm64 just doesn't export the API.

I need to walk back the framing in my original report and my previous comment. I pulled sailor.dll out of the 4.90.0 amd64 package (where Docker VMM works) and diffed the real PE export tables against the arm64 one from the same release:

	amd64 (4.90.0)	arm64 (4.90.0)
Machine	0x8664	0xAA64
Size	10,044,336	7,740,336
FileVersion	0.118.0	0.118.0
Embedded version	0.118.0+9f348c0	0.118.0+9f348c0
Exported functions	142	137

Exported by amd64, missing from arm64 — exactly these 5, and nothing else:

sailor_vm_checkpoint
sailor_vm_pause
sailor_vm_resume
sailor_vm_restore
sailor_vm_run_restored

The reverse delta is empty: the arm64 DLL exports no symbol the amd64 one lacks. Apart from those five, the two export sets are identical function for function.

Both DLLs report the same build, 0.118.0+9f348c0. So the error message's self-diagnosis — "the dylib is likely older than this binding — rebuild/repackage libsailor and the Go bindings from the same sailor commit" — is misleading here, and it sent me down the wrong path. Nothing is stale and nothing is mispackaged.

What this actually looks like is that the VM snapshot API (checkpoint / pause / resume / restore / run_restored) is compile-time gated to x86_64 in libsailor, while the Go binding in com.docker.sailor.exe registers all five unconditionally at load. On aarch64 the first one to be registered (sailor_vm_pause) therefore aborts VM creation ~105 ms in, before any virtualization call happens.

If that's right, the fix isn't repackaging: it's either gating the Go-side symbol registration per target arch (with pause/resume/checkpoint reporting "unsupported on this platform"), or building the snapshot module for aarch64.

Also, credit where it's due — 4.90.0 fixes the worst symptom in my original report. The failure is no longer silent: it now surfaces as a proper error dialog offering ["Use a different VMM", "Restart", "Quit"], and reverting to WSL2 from the GUI works. The unbounded HEAD /_ping spinner and the hand-editing of %APPDATA%\Docker\settings-store.json I described are gone. Please disregard that part of the issue body — it describes 4.89.0 behaviour.

So the remaining ask is narrower than what I originally filed: Docker VMM is still offered in the UI on Windows arm64 even though the shipped DLL cannot support it, so selecting it always fails. Either build the snapshot module for aarch64, or hide/disable the option on this platform.

Happy to attach the export dumps from both DLLs if that's useful.

[thaJeztah]

Thx for reporting; I forwarded your report to the team working on this to see what's missing.