DockerAutoStartHelper

Makes Docker Desktop’s engine come back on its own after an unattended reboot.

Note

Docker Desktop is a per-USER desktop application, not a Windows service. Its engine only exists inside an interactive session - measured on devBuilder05, every com.docker.backend and Docker Desktop process ran in the RDP session and died with it, leaving the node with a docker CLI and no daemon. com.docker.service is only the privileged helper; it being Stopped/Manual is normal and does NOT mean the engine is up.

There is no supported headless mode, so the only way to have an engine on a node nobody is sitting at is to make sure a session exists. Four things are configured, and every one of them was needed:

  • Autologon. Creates the session at boot. The desktop is LOCKED again a few minutes later by a second task - locking does not end the session, so the engine keeps running behind the lock screen.

  • AutoStart in settings-store.json. It ships false, so Docker Desktop does not even start when somebody does log on. The file is seeded from a profile that already completed first run, which also skips the accept-terms dialog - that would otherwise block an unattended start dead. Written without a BOM: Docker parses this file with Go’s encoding/json, and a UTF-8 BOM makes the backend crash outright with invalid character 'i' looking for beginning of value.

  • A logon task that launches Docker Desktop. Belt and braces next to AutoStart, and it is the deterministic one. Note a task whose action is Docker Desktop and whose principal is Interactive dies with the session; that is only survivable because autologon keeps a session alive.

  • One seed entry in Windows Credential Manager. This looks absurd and is not: on a COMPLETELY EMPTY credential store, docker-credential-wincred / -desktop answer ERROR_NO_SUCH_LOGON_SESSION (1312) rather than "not found", the helper exits 1, and the docker CLI aborts with error getting credentials - even for an ANONYMOUS pull. Verified on devBuilder05: with an empty store docker pull hello-world failed, and adding a single dummy credential made the very same pull succeed.

Known limit: a plain WinRM connection is a NETWORK logon, and Windows will not open the credential store for one ("credentials cannot be saved from this logon session"). So docker pull driven straight over WinRM still fails even after this runs. Drive builds from the interactive session (a scheduled task, or an agent running there), or authenticate the WinRM session with CredSSP.

 
public static class DockerAutoStartHelper

1. Methods

1.1. EnableDockerAutoStart(ISystemHost, string, string, string)

Configures autologon plus the Docker Desktop startup chain on host. Idempotent - safe to re-run on a node that already has it.

public static void EnableDockerAutoStart(ISystemHost host, string autoLogonUser, string autoLogonPassword, string templateProfile = null)
Table 1. Parameters
Name Type Description

host

ISystemHost

Host to configure.

autoLogonUser

string

Local account to log on automatically. Must exist on the node.

autoLogonPassword

string

That account’s password, taken from the config’s User entity.

templateProfile

string

Optional profile whose Docker settings are copied to autoLogonUser so the first-run wizard is already done. Null skips the seeding and lets Docker Desktop create its own.