Repository navigation
nerdctl -d -t detached containers immediately exit with code 3221225786 (0xc000013a) on Windows #4899
Description
Description
When attempting to create a detached Windows container, the container exits immediately with code 3221225786 (0xc000013a):
C:\Users\mark>nerdctl run -d -t mcr.microsoft.com/windows/nanoserver:ltsc2025
369992f8d96f29ab0412dc800b3eff24c8a3a29596bbf5ba3629450f2dd709fc
C:\Users\mark>nerdctl ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
369992f8d96f mcr.microsoft.com/windows/nanoserver:ltsc2025 "c:\\windows\\system32…" 5 seconds ago Exited (3221225786) 2 seconds ago nanoserver-36999
The container starts and runs fine if used in interactive mode (i.e. not daemonised) via nerdctl run --rm -it mcr.microsoft.com/windows/nanoserver:ltsc2025.
Some initial research shows that code 3221225786 (0xc000013a) or STATUS_CONTROL_C_EXIT suggesting that the container has generated the equivalent of CTRL-C which causes it to exit prematurely.
Steps to reproduce the issue
- Open a command prompt in Windows and enter
nerdctl run -d -t mcr.microsoft.com/windows/nanoserver:ltsc2025 - Check the status of the container with
nerdctl ps -a - Note that the container has exited immediately with code 3221225786 (0xc000013a)
Describe the results you received and expected
The container should still be running, and hence visible via nerdctl ps.
What version of nerdctl are you using?
C:\Users\mark>nerdctl version
time="2026-05-14T10:54:50+01:00" level=warning msg="unable to determine buildctl version" error="exec: \"buildctl\": executable file not found in %PATH%"
time="2026-05-14T10:54:51+01:00" level=warning msg="unable to determine runc version" error="exec: \"runc\": executable file not found in %PATH%"
Client:
Version: v2.2.0
OS/Arch: windows/amd64
Git commit: 4eb4cbdb6b7ae82ab864a9829d1162a20eb61f81
buildctl:
Version:
Server:
containerd:
Version: v2.2.0
GitCommit: 1c4457e00facac03ce1d75f7b6777a7a851e5c41
runc:
Version:
Are you using a variant of nerdctl? (e.g., Rancher Desktop)
None
Host information
C:\Users\mark>nerdctl info
Client:
Namespace: default
Debug Mode: false
Server:
Server Version: v2.2.0
Storage Driver: windows
Logging Driver: json-file
Plugins:
Log: fluentd journald json-file none syslog
Storage: windows-lcow cimfs windows
Kernel Version: 10.0 26100 (26100.1.amd64fre.ge_release.240331-1435)
Operating System: Microsoft Windows Version 24H2 (OS Build 26100.8457)
OSType: windows
Architecture: x86_64
CPUs: 2
Total Memory: 7.916GiB
Name: AZ-
ID: 6442774b-b723-4cac-b2e3-a29a35c0406b
Activity
mcayland-ntx commentedon May 14, 2026
Amazingly I've found that if I run
nerdctl run -d -t mcr.microsoft.com/windows/nanoserver:ltsc2025enough times then it eventually works! It seems to work in about 1 in every 30 attempts or so on my setup here.If I run nerdctl with
--debug-fullduring a failed attempt, then nothing at all gets logged in the log file(!) which suggests something is failing very early on. I'm not overly familiar with nerdctl/containerd or Go, but I'll try and do some more digging.Given that this is racy, I'm starting to wonder if this is a possible dupe of #3437?
mcayland-ntx commentedon May 14, 2026
With a bit more work I was able to obtain logs from the output of
"C:\Program Files\containerd\bin\containerd.exe" -l debugfor both the good (working) and bad (non-working) cases:containerd-debug-bad.txt
containerd-debug-good.txt
There is an obvious difference between the good and bad cases visible in the log output at the point where the task starts at the log entry marked
name=containerd.task.v2.Task.Start:GOOD:
BAD:
It seems that in the bad case, as soon as the task starts there are log entries for
name=HcsGetProcessProperties,name="hcs::Process::waitBackground"andname="hcs::Process::CloseStdout"followed byname=StatewithexitStatus=3221225786which is our failure exit code. None of these entries are present in the good case.Questions:
HcsGetProcessPropertiesduring a critical section within the task startup process that is causing the issue? Is this internal to containerd or could this occur due to an external call from nerdctl during task startup? Alternatively perhaps some event on stdout/stderr during initial setup causes the equivalent of a CTRL_C event to be generated?mcayland-ntx commentedon May 15, 2026
The logs for the bad case suggest we're ending up in
hcs::Process::waitBackgroundwhich is part of hcsshim: https://github.com/microsoft/hcsshim/blob/main/internal/hcs/process.go#L207.This suggests that we must be returning from
waitNotificationwithhcsNotificationProcessExitedalmost immediately in order to call intoHcsGetProcessPropertiesjust after the process starts. Possibly we get here viaCreateProcessat https://github.com/microsoft/hcsshim/blob/main/internal/hcs/system.go#L788?mcayland-ntx commentedon Sep 16, 2026
UPDATE: I now have a PR for hcsshim that will fix this issue: microsoft/hcsshim#2923
Unfortunately it appears that recent bot-mitigating changes to GitHub now require all PR merge workflows to be manually approved, so it is stuck pending upstream approval/review.
@AkihiroSuda do you know if there is anyone we can contact in the hcsshim team to try and get some movement on this? This bug is critical to a number of our internal workflows.