Share and learn in the Docker community.
I have DD 4.54 that runs very well in “Linux containers “ mode. I try to switch to windows containers, I get “Privileged helper service is not running”. I searched in the services panel, there is no such service
I click on “start service” I get another prompt, click continue but it comes back saying
I click on QUIT, DD crashes and never comes back and start I need to reboot the machine as it keeps in the following state
Based on your other topics, I assume it happens on Windows 10. I couldn’t find if it is Pro or Home. According to the requirements documentation, only Pro, Enterprise and Education versions are supported, probably because there is an extended security updates program for Win10 at Microsoft.
I only have Windows 11. I got the first error message, but the helper script could start properly after clicking on Start. I can only recommend trying the “GAther diagnostics” button which will likely take you to the documentation which explains where and how you can report Docker Desktop issues.
If you can’t find a diagnostics button anymore, here is the documentation I think it would take you to
Hey @eliassal
Would you be able to collect the diagnostic logs using the commands outlined on the same document?
Also, just to confirm, did you have administrative privileges when installing Docker Desktop?
You don’t need admin privileges to run Docker Desktop, but you do need them during installation. This is especially important in your case because the privileged helper service runs with SYSTEM-level permissions to support Windows containers (which require deep integration with Windows, unlike Linux containers that run inside a VM).
If Docker Desktop was installed without admin rights, the privileged helper service may not have been created correctly.
Thanks, yes it is installed with admin privileges. With the GUI, “Gathering gets stuck for more than 15 minutes
Then I ran the command
com.docker.diagnose.exe" gather -upload
It finished with following output
[2025-12-12T09:17:47.009834300Z][com.docker.diagnose.exe.public] com.docker.backend is not running so starting a local HTTP proxy
Uploaded diagnostics to: https://docker-pinata-support.s3.amazonaws.com/incoming/3/09777C54-E71E-4BED-A514-5F81A9DCC7BD/20251212090658.zip
Diagnostics ID: 09777C54-E71E-4BED-A514-5F81A9DCC7BD/20251212090658 (uploaded)
I don’t know if you have access to this file but I have copy in my profile which I can share with you the full zip file and here I extracted the diag file
diagnostics.log (118.3 KB)
I don’t think it would be necessary as @kekcheeyoung413 seems to be from Docker.
Regarding diagnostics data, it showscommands timing out. I don’t know if it is related, but I also found this:
[2025-12-12T09:07:55.473830100Z][com.docker.diagnose.exe][W] C:\Windows\System32\winevt\Logs\Microsoft-Windows-Host-Network-Service-Admin.evtxopen C:\Windows\System32\winevt\Logs\Microsoft-Windows-Host-Network-Service-Admin.evtx: Access is denied.
I am not exactly sure if that specific access denied error is normal or not.I assume it would just include Windows system events when the current user has access to it. But these are the “deadline exceeded” messages
[2025-12-12T09:07:00.711170900Z][com.docker.diagnose.exe][W] /flush failed: Post "http://unix/flush": context deadline exceeded
[2025-12-12T09:07:26.380465500Z][com.docker.diagnose.exe][W] tasklist /V (timeout 0s) -> context deadline exceeded
[2025-12-12T09:07:37.541621100Z][com.docker.diagnose.exe][W] powershell -NoProfile -Command &{ Get-CimInstance win32_logicaldisk } (timeout 0s) -> context deadline exceeded
[2025-12-12T09:07:56.772893800Z][com.docker.diagnose.exe][W] hnsdiag list all (timeout 0s) -> context deadline exceeded
[2025-12-12T09:08:33.429800000Z][com.docker.diagnose.exe][W] wsl.exe -l -v (timeout 0s) -> context deadline exceeded
[2025-12-12T09:08:48.434806100Z][com.docker.diagnose.exe][W] wsl.exe --system dmesg (timeout 0s) -> context deadline exceeded
[2025-12-12T09:08:51.125050100Z][com.docker.diagnose.exe][W] wsl.exe --system ps uax (timeout 0s) -> context deadline exceeded
[2025-12-12T09:09:03.439794200Z][com.docker.diagnose.exe][W] wsl.exe --system free (timeout 0s) -> context deadline exceeded
[2025-12-12T09:09:06.459231600Z][com.docker.diagnose.exe][W] wsl.exe --system netstat -ntlp (timeout 0s) -> context deadline exceeded
[2025-12-12T09:09:11.397312900Z][com.docker.diagnose.exe][W] wsl.exe --system lsof (timeout 0s) -> context deadline exceeded
[2025-12-12T09:09:18.443796800Z][com.docker.diagnose.exe][W] wsl.exe --system cat /proc/cgroups (timeout 0s) -> context deadline exceeded
[2025-12-12T09:09:21.463025100Z][com.docker.diagnose.exe][W] wsl.exe --system mount (timeout 0s) -> context deadline exceeded
[2025-12-12T09:09:26.401352000Z][com.docker.diagnose.exe][W] wsl.exe --system cat /etc/wsl.conf (timeout 0s) -> context deadline exceeded
[2025-12-12T09:09:31.408280000Z][com.docker.diagnose.exe][W] wsl.exe -d docker-desktop -e cat /root/.docker/desktop/log/host/wsl-bootstrap.log (timeout 5s) -> context deadline exceeded
[2025-12-12T09:09:33.447157400Z][com.docker.diagnose.exe][W] wsl.exe --system ls -lR /sys/fs/cgroup (timeout 0s) -> context deadline exceeded
[2025-12-12T09:09:36.412044500Z][com.docker.diagnose.exe][W] wsl.exe -d docker-desktop -e dmesg (timeout 5s) -> context deadline exceeded
[2025-12-12T09:09:36.466721300Z][com.docker.diagnose.exe][W] wsl.exe --system bash -c for dev in /sys/block/sd*; do echo -n "\${dev} "; cat \${dev}/device/wwid ; done (timeout 0s) -> context deadline exceeded
[2025-12-12T09:09:38.450761400Z][com.docker.diagnose.exe][W] wsl.exe -d docker-desktop -e ps uax (timeout 5s) -> context deadline exceeded
[2025-12-12T09:09:41.417853500Z][com.docker.diagnose.exe][W] wsl.exe -d docker-desktop -e free (timeout 5s) -> context deadline exceeded
[2025-12-12T09:09:41.470976700Z][com.docker.diagnose.exe][W] wsl.exe -d docker-desktop -e netstat -ntlp (timeout 5s) -> context deadline exceeded
[2025-12-12T09:09:43.454575700Z][com.docker.diagnose.exe][W] wsl.exe -d docker-desktop -e lsof (timeout 5s) -> context deadline exceeded
[2025-12-12T09:09:46.422198600Z][com.docker.diagnose.exe][W] wsl.exe -d docker-desktop -e cat /proc/cgroups (timeout 5s) -> context deadline exceeded
[2025-12-12T09:09:46.473839600Z][com.docker.diagnose.exe][W] wsl.exe -d docker-desktop -e mount (timeout 5s) -> context deadline exceeded
[2025-12-12T09:09:48.459590000Z][com.docker.diagnose.exe][W] wsl.exe -d docker-desktop -e cat /etc/wsl.conf (timeout 5s) -> context deadline exceeded
[2025-12-12T09:09:51.428531100Z][com.docker.diagnose.exe][W] wsl.exe -d docker-desktop -e ls -lR /sys/fs/cgroup (timeout 5s) -> context deadline exceeded
[2025-12-12T09:10:18.461284400Z][com.docker.diagnose.exe][W] /diagnostics failed: Get "http://unix/diagnostics?timeout=30": context deadline exceeded
I wonder how a tasklist command can exceed contxt deadline
Is it possible you don’t have enough resources to run the diagnostics and that same resource issue causes the the problem with switching to Windows containers?
Rimelek, by “Resources, do you man RAM? If yes, I have 32G of RAM in the box. It is 8 CPUS
rimelek, I am not sure what I need to do and a little bit confused. Anyway, I tried (after restarting DD service)
docker desktop engine use linux
on command line in administrator command line, I get
unable to set engine to “linux”: Post “http://ipc/app/settings”: open \.\pipe\dockerBackendApiServer: The system cannot find the file specified.
rimelek, as I said now it is failing always as it is not able to start since I switched to Win containers.
Is there a config file foe DD that I can indicate to DD to start with using Linux containers when I reboot?
Seems enough, and I assume you know that the memory is also available.
Yes and you don’t even need to Reboot for that.
%APPDATA%/Roaming/Docker/settings-store.json
If Docker Desktop is stopped (should be if it couldn’t start) set useWindowsContainers to false.
"useWindowsContainers": false
update:
I recommended settings.json in my original post. It is actually settings-store.json
I did add restartedand hoop D D back again in life so we are back to ntial state
Also, I went through settings-store.json, I saw
DataFolder": “C:\ProgramData\DockerDesktop\vm-data”
I checked this directory, there is no vm-data folder, maybe because I use wsl?
Then, I checked the daemon.json, I saw
{
“data-root”: “H:\dockerStorage”,
“debug”: false,
“experimental”: false,
“insecure-registries”: null,
“registry-mirrors”: null,
“hosts”: [
“npipe:////./pipe/docker_engine_windows”
]
}
I remember 6 or 7 months ago, I had an issue and I thing you recommended to add the last statement npipe……
I’m not sure. I don’t really know which parametr is for what. I could only recognize some.
I don’t remember recommending that, but not impossible. If I recommended that, I must have known more than I do today. I see another file called windows-daemon.json. The npipe and the data-root you have in your daemon config seems to be for Windows containers, but as far as I know, daemon.json is for Linux, so I am a little confused. Do you have a windows-daemon.json as well?
I get it now. I was writing about the config files in the .docker folder under my user profile while you were writing about the Docker folder which is for Windows containers only.
I have the same pipe in my config file so it will not take us closer to the solution.
OK, I have windows-daemon.json at C:\Users\…\.docker
Here is the content
{
“data-root”: “H:\dockerStorage”,
“debug”: false,
“experimental”: false,
“insecure-registries”: null,
“registry-mirrors”: null
}
Do you see anything that is making the issue when switching to windows containers?
No. But my knowledge about Windows containers will not be enough here, so let’s see if @kekcheeyoung413 have time tomorrow to look at your logs, or you can go straight to GitHub
OK I will wait and see if he can help befor going to github
Hi @eliassal I managed to check the logs and I think we can try a quick test to rule out whether the windows-daemon.json file is causing the issue. The custom data-root (H:\dockerStorage) is not the default configuration, so reverting to the default may help us narrow things down.
Could you try the following:
C:\ProgramData\DockerDesktop\docker\windows-daemon.jsonwindows-daemon.json-bk-<today's-date>This should allow Docker Desktop to regenerate a clean default config, and it will help us determine if the issue is related to the current configuration.