A process-isolated Windows container stops starting after the host is upgraded to a newer Windows build. How do you diagnose it?

## The failure mode A nightly payments reconciliation batch runs in a Windows container built `FROM mcr.microsoft.com/windows/servercore:ltsc2019`. It has run for months. The host is rebuilt onto Windows Server 2022, and the very next run dies before producing a line of application output: ``` docker: Error response from daemon: hcsshim::CreateComputeSystem recon-batch: The container operating system does not match the host operating system. ``` The distinguishing feature is that there are no application logs at all, and `docker logs` is empty: the container never started, so nothing inside it ran. That separates this from a crash loop, from an entrypoint that exits, and from a mount or permissions problem, all of which produce at least some output or a nonzero exit code from your process. ## Why the rule exists Under process isolation the container's user-mode binaries execute directly against the host's Windows kernel. Windows does not offer a stable syscall ABI across builds the way Linux does, so a `servercore` or `nanoserver` image is built against a specific kernel build and is only supported on that build. The engine enforces this at container creation rather than letting the binaries fail unpredictably later. Concretely, the base image tags map to builds: - `ltsc2019` images carry `OsVersion` `10.0.17763.x` and process-isolate on Windows Server 2019 hosts. - `ltsc2022` images carry `OsVersion` `10.0.20348.x` and process-isolate on Windows Server 2022 hosts. Only the fourth component, the revision, is allowed to differ; on Windows Server 2019 and later a host patched to a higher revision than the image was built against still runs it. A different build number is a hard stop. ## Diagnosing it in order First establish the two numbers rather than guessing: ``` docker image inspect --format '{{.Os}} {{.OsVersion}}' recon-batch:4.2 docker info --format '{{.OSType}} {{.OperatingSystem}}' ``` The first prints something like `windows 10.0.17763.4737`; the second identifies the host. Read the host's own build number from the operating system as well, so you are not relying on a marketing name. If the two build numbers differ in any of the first three components, you have your answer and no further investigation is warranted. Second, confirm the mode actually in use. `docker inspect --format '{{.HostConfig.Isolation}}'` on a previous, successful container tells you whether the workload was ever relying on process isolation. If a developer's machine ran it under Hyper-V isolation, the mismatch was invisible there, which is often why the problem surfaces only in production. Third, check whether anything else changed with the host rebuild before declaring victory: a rebuilt host is also a new data root, a fresh image cache and possibly a different engine version. The distinctive error message keeps you honest here; if it is the OS mismatch text, the build numbers are the story. ## Fixing it, immediately and properly The immediate mitigation is `docker run --isolation=hyperv`. The container gets its own kernel from the image, so the host's build stops mattering and the batch can run tonight. Budget for a slower start and for the memory the extra kernel takes; for a single nightly batch that is irrelevant, for a fleet of long-running services it is a capacity change you should not make casually or permanently. The proper fix is to rebuild the image on the base tag matching the new host generation, `FROM mcr.microsoft.com/windows/servercore:ltsc2022`, and re-test. This is rarely a one-line change in practice: the newer base carries a newer set of OS components, and anything the application depends on inside the image, a runtime, an ODBC driver, a scheduled-task shim, has to be validated on the new base too. ## Preventing the recurrence The deeper defect is that a host upgrade and an image rebuild were treated as independent changes. Three habits stop it repeating. Pin explicitly. Never build a Windows workload `FROM` a floating tag that can move across generations; name the generation in the tag, and record the expected host build alongside it in the deployment manifest. Couple the two changes. Treat a host-generation upgrade as a fleet event that requires the images to be rebuilt and re-tested first, then rolled with the hosts, rather than a patch that operations can apply independently. Keep the host pool homogeneous per generation so a workload cannot land on a host of the wrong build by scheduling luck. Make the environments agree. If developers run under Hyper-V isolation by default and production runs process isolation, add an explicit `--isolation=process` smoke run in CI on a host of the production generation, so a mismatch is caught by a pipeline rather than by a payments batch missing its window. ## Summary The error is a version-compatibility check, not a bug. Process isolation binds the image's build to the host's build; a host generation upgrade therefore invalidates images built on the previous generation. Diagnose by comparing `OsVersion` with the host build, bridge with Hyper-V isolation if you need tonight's run, and fix by rebuilding on the matching base and coupling image rebuilds to host upgrades from then on.