Skip to content

Docker Desktop Windows Service not started after upgrade via Chocolatey #917

Description

@theroch

Description

After upgrading Docker Desktop via Chocolatey (choco upgrade docker-desktop), the Docker Desktop Windows Service ("Docker Desktop Service" / com.docker.service) is left in a stopped state. A user with local administrator rights has to manually start the service before Docker Desktop functions correctly again.

This appears to be a gap in the installer's post-upgrade routine: on a normal interactive install/upgrade, the installer is expected to (re)start the service automatically as part of setup. When the upgrade is performed non-interactively via Chocolatey, this step seems to be skipped.

Environment

  • Docker Desktop for Windows (latest version via Chocolatey)
  • Package manager: Chocolatey
  • Installation type: Windows Service (com.docker.service)
  • OS: Windows 11 (enterprise/managed environment)
  • Update triggered via: choco upgrade docker-desktop (e.g. scheduled/automated via Windows Task Scheduler)

Steps to Reproduce

  1. Have Docker Desktop installed via Chocolatey.
  2. Run choco upgrade docker-desktop to update to a newer version.
  3. After the upgrade completes, check the status of the Docker Desktop Windows Service.

Expected Behavior
The Docker Desktop Windows Service should be running (or automatically restarted) after the upgrade completes, without requiring manual intervention.

Actual Behavior
The Docker Desktop Windows Service is left in a stopped state after the Chocolatey upgrade. A user with administrator privileges must manually start the service (e.g. via Start-Service com.docker.service or the Services MMC) before Docker Desktop can be used.

Impact
This breaks unattended/automated update workflows (e.g. scheduled upgrades via Task Scheduler), since the service does not come back online without manual admin action.

Workaround
Manually start the service after upgrade, e.g.:

Start-Service com.docker.service

Additional Context
This issue may be specific to Chocolatey-driven, non-interactive upgrades, as the standard installer flow (interactive) appears to handle service startup correctly.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions