🐳 Docker Error Guide: 'hcsshim::CreateComputeSystem failed' Windows Container Failure

Exact Error Message

docker: Error response from daemon: container <id> encountered an error during hcsshim::System::CreateComputeSystem:
failed to create container <id>: The container operating system does not match the host operating system.
(0xc0370101)

You may also see close variants such as hcsshim::CreateComputeSystem <id>: The system cannot find the file specified, The requested operation could not be completed due to a virtual disk system limitation, or failed to create endpoint on network. All of them come from hcsshim, the Host Compute Service shim that Docker uses to launch Windows containers.

What It Means

Windows containers share the host kernel far more strictly than Linux containers do. The Host Compute Service (HCS), driven by hcsshim, refuses to start a container whose base image was built against a Windows kernel version that the host does not support. The classic case is running a ltsc2022 (Windows Server 2022) image on a Windows Server 2019 host, or vice versa.

Error code 0xc0370101 specifically means “the container operating system does not match the host operating system.” When the mismatch is only a minor build difference, Hyper-V isolation can bridge the gap by booting a lightweight utility VM with a compatible kernel. When you force process isolation, the host and container builds must line up much more precisely.

Common Causes

• The container’s base image (for example mcr.microsoft.com/windows/servercore:ltsc2022) targets a newer Windows build than the host runs.
• Process isolation is in use, which requires a tight host/container build match.
• Hyper-V isolation is unavailable because nested virtualization or the Hyper-V feature is disabled.
• The Docker daemon is in Linux-container mode while you are pulling a Windows image (or the reverse).
• A partially pulled or corrupted image layer left the compute system unable to mount its base layer.

Diagnostic Commands

Confirm the host OS build number:

[System.Environment]::OSVersion.Version
Get-ComputerInfo | Select-Object OsName, OsVersion, OsHardwareAbstractionLayer

Check which OS build the image was made for:

docker image inspect mcr.microsoft.com/windows/servercore:ltsc2022 --format "{{.Os}} {{.OsVersion}}"

Verify the daemon is in Windows-container mode and see the default isolation:

docker info --format "OSType={{.OSType}} Isolation={{.Isolation}}"

Confirm the Hyper-V feature is present if you plan to use hyperv isolation:

Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V

Step-by-Step Resolution

1. Compare the host build with the image’s OsVersion. If docker image inspect reports 10.0.20348.x (ltsc2022) but your host is 10.0.17763.x (ltsc2019), you have found the mismatch.

2. The most reliable fix is to match the base image tag to the host. Pull an image built for your host’s release:

docker pull mcr.microsoft.com/windows/servercore:ltsc2019

3. If you must run a newer image on an older host, switch to Hyper-V isolation so a compatible utility VM handles the kernel gap:

docker run --isolation=hyperv mcr.microsoft.com/windows/servercore:ltsc2022 cmd /c echo ok

4. To make Hyper-V isolation the default, set it in the daemon configuration and restart Docker:

{
  "exec-opts": ["isolation=hyperv"]
}

Restart-Service docker

5. If you intended process isolation for speed, ensure the image tag exactly matches the host build, then run:

docker run --isolation=process mcr.microsoft.com/windows/servercore:ltsc2019 cmd /c echo ok

6. If the daemon is in the wrong mode, switch it back to Windows containers (Docker Desktop tray menu, or DockerCli -SwitchWindowsEngine), then re-run and confirm:

ok

Prevention

• Pin base image tags to a specific LTSC release (ltsc2019, ltsc2022) that matches your fleet, rather than floating tags.
• Standardize host Windows Server builds across a cluster so the same image runs everywhere with process isolation.
• Default to Hyper-V isolation when you cannot guarantee build parity; it trades a little startup time for compatibility.
• Enable and validate the Hyper-V feature during host provisioning if any workload needs hyperv isolation.
• Add a CI check that inspects OsVersion on both the image and the target host before deploying.

Related Errors

• no matching manifest for windows/amd64 in the manifest list entries — the image has no Windows variant for your platform.
• The container operating system does not match the host operating system — the human-readable form of 0xc0370101.
• hcsshim::PrepareLayer failed — a corrupted or locked base layer rather than a build mismatch.
• failed to create endpoint on network nat — a Windows container networking failure, not an isolation problem.

Frequently Asked Questions

What does error code 0xc0370101 mean? It is HCS signalling that the container’s base OS build is incompatible with the host kernel. Match the image tag to the host or switch to Hyper-V isolation.

Can I run an ltsc2022 image on a Windows Server 2019 host? Not with process isolation. Use --isolation=hyperv, which boots a compatible utility VM, or use an ltsc2019-tagged image instead.

What is the difference between process and hyperv isolation? Process isolation runs the container directly on the host kernel and is faster but demands a matching build. Hyperv isolation runs a thin VM with a compatible kernel, so it tolerates build differences.

Why does this only happen with Windows containers? Windows containers depend on tight kernel/user-mode versioning enforced by HCS, whereas Linux containers share a more forgiving kernel ABI. For prompts to generate isolation-mode and Dockerfile fixes fast, use the DevOps AI prompt library.

Is Hyper-V required for all Windows containers? No. Process isolation works without Hyper-V when builds match, but Hyper-V isolation needs the Hyper-V feature enabled on the host. See more Docker guides.