Skip to content

Process.Start() and PowerShell Start-Process hang on newer mcr.microsoft.com/windows/servercore:ltsc2019 / .NET Framework 4.8 LTSC2019 images #645

Open
Open
Process.Start() and PowerShell Start-Process hang on newer mcr.microsoft.com/windows/servercore:ltsc2019 / .NET Framework 4.8 LTSC2019 images#645
Labels
bugSomething isn't workingtriageNew and needs attention

Description

@mariskahoogenboom
Mariska Hoogenboom (mariskahoogenboom)
opened on Aug 7, 2026

Description of the bug

We are seeing a regression in newer Windows Server Core LTSC 2019 container images.

Starting a child process from inside the container hangs indefinitely. This affects both:

  • .NET System.Diagnostics.Process.Start()
  • PowerShell Start-Process

This used to work a few weeks ago and still works on an older pinned .NET Framework SDK image.

Known-good image

The following images still works correctly:

  • mcr.microsoft.com/dotnet/framework/sdk:4.8-20260512-windowsservercore-ltsc2019
  • mcr.microsoft.com/windows/servercore:10.0.17763.8880

On this image, both:

  • .NET Process.Start()
  • PowerShell Start-Process

return normally.

Regressed images

The problem occurs on newer images based on updated LTSC2019 Server Core, including:

  • mcr.microsoft.com/windows/servercore:ltsc2019
  • current floating mcr.microsoft.com/dotnet/framework/sdk:4.8
  • current floating mcr.microsoft.com/dotnet/framework/sdk:4.8-windowsservercore-ltsc2019

Expected behavior

Starting cmd.exe /c echo hello should return immediately.

Expected output for the .NET repro:

Before
After

Expected output for the PowerShell repro:

Before
After

Actual behavior

The process-start call hangs indefinitely.

For the .NET repro, output is:

Before

and Process.Start() never returns.

For the PowerShell repro, output is:

Before

and Start-Process never returns.

Container OS versions observed

Known-good older image lineage:

  • 10.0.17763.8880

Failing newer image lineage:

  • 10.0.17763.9020

Minimal PowerShell repro

Run:

docker run -ti --rm mcr.microsoft.com/windows/servercore:ltsc2019 powershell

Inside the container:

Write-Host "Before"
Start-Process cmd.exe -ArgumentList '/c echo hello' -Wait
Write-Host "After"

Actual result on the failing image:

Before

and then it hangs.

Minimal .NET repro

Run:

docker run -ti --rm mcr.microsoft.com/windows/servercore:ltsc2019 powershell

Inside the container:

Add-Type @"
using System;
using System.Diagnostics;

public class Test {
    public static void Run() {
        var p = new Process();
        p.StartInfo.FileName = "cmd.exe";
        p.StartInfo.Arguments = "/c echo hello";
        Console.WriteLine("Before");
        p.Start();
        Console.WriteLine("After");
    }
}
"@

[Test]::Run()

Actual result on the failing image:

Before

and then it hangs.

Notes

  • This does not appear to be specific to .NET Framework, because the same behavior is reproducible on plain mcr.microsoft.com/windows/servercore:ltsc2019.
  • The regression appears to have been introduced after the 2026-05-12 .NET Framework SDK LTSC2019 image.
  • We are currently pinning to mcr.microsoft.com/dotnet/framework/sdk:4.8-20260512-windowsservercore-ltsc2019 as a temporary workaround.

Environment

  • Host OS: Windows Server 2019
  • Container base: mcr.microsoft.com/windows/servercore:ltsc2019
  • Affected higher-level image: mcr.microsoft.com/dotnet/framework/sdk:4.8
  • Working higher-level image: mcr.microsoft.com/windows/servercore:10.0.17763.8880

Question

Is this a known regression in the updated LTSC2019 Server Core image, or an intentional change in process creation behavior inside Windows containers?

Activity

  1. Mariska Hoogenboom (mariskahoogenboom)
    added
    bugSomething isn't working
    triageNew and needs attention
    on Aug 7, 2026

  2. github-actions commented on Aug 7, 2026

    @github-actions
    github-actionsBot
    on Aug 7, 2026 – with GitHub Actions

    Thank you for creating an Issue. Please note that GitHub is not an official channel for Microsoft support requests. To create an official support request, please open a ticket here. Microsoft and the GitHub Community strive to provide a best effort in answering questions and supporting Issues on GitHub.

  3. microsoft-github-policy-service commented on Sep 9, 2026

    @microsoft-github-policy-service
    microsoft-github-policy-serviceBot
    on Sep 9, 2026 – with Microsoft GitHub Policy Service
    Contributor

    This issue has been open for 30 days with no updates.
    no assignees, please provide an update or close this issue.

  4. jy-cimcloud commented on Sep 15, 2026

    @jy-cimcloud
    jy-cimcloud
    on Sep 15, 2026

    Independently hit this and can confirm, with three additions.

    1. It is not an indefinite hang — it is a flat ~1800 s timeout.

    The call does return, after almost exactly 30 minutes. Four runs across three
    images all landed between 1801 and 1802 seconds, which is a hard timeout rather
    than variance. Anyone who gives up before the 30-minute mark reads this as a
    hang, which I think is why it has been reported that way.

    2. 10.0.17763.9020 already reproduces, which narrows it to one servicing step.

    Combined with your known-good 8880, and since there was no June 2026 release,
    8880 and 9020 are consecutive updates.

    Windows build Image TotalSeconds
    10.0.17763.8880 dotnet/framework/runtime:4.8-20260512-windowsservercore-ltsc2019 1.43
    10.0.17763.9020 dotnet/framework/runtime:4.8-20260714-windowsservercore-ltsc2019 1801.75
    10.0.17763.9245 windows/servercore:ltsc2019 1802.01

    Repro, on a Server 2019 host with process isolation:

    docker run --rm mcr.microsoft.com/windows/servercore:ltsc2019 powershell -NoProfile -Command "Measure-Command { Start-Process C:\Windows\SysWOW64\regsvr32.exe -ArgumentList '/s','C:\Windows\SysWOW64\scrrun.dll' -Wait } | Select TotalSeconds"

    3. -NoNewWindow avoids it, which may point at the shell-launch path.

    Same container, minutes apart:

    Variant Launch path Time
    Start-Process ... -Wait ShellExecuteEx (PowerShell default) ~1806 s
    Start-Process ... -Wait -NoNewWindow CreateProcess 1.03 s

    -NoNewWindow switches Start-Process from UseShellExecute = $true to
    CreateProcess. Since .NET Framework's ProcessStartInfo.UseShellExecute also
    defaults to true, that would explain why both of your repros hang. It predicts
    that Process.Start() with UseShellExecute = false will not — worth confirming,
    since it would separate the shell path from process creation.

    Also possibly useful: during the stall, the target process never appears in
    tasklist inside the container at all, so it looks like the block happens before
    the child is created.

    Other things I ruled out here, in case it saves someone repeating them: it is not
    the target binary (reproduces on stock in-image scrrun.dll), not a network wait
    (netstat in the stalled container shows completed connections in TIME_WAIT,
    nothing in SYN_SENT), and not the host — 8880 returns in 1.4 s on the same
    host, same hour, same Docker daemon.

    Environment: Windows Server 2019 host, process isolation, Docker 20.10.9 (API 1.41).

    Disclosure: I used Claude (Anthropic) to help investigate this and draft this
    comment. The measurements were run on my own host and I have checked them.

  5. mariskahoogenboom commented on Sep 16, 2026

    @mariskahoogenboom
    Mariska Hoogenboom (mariskahoogenboom)
    on Sep 16, 2026
    Author

    Thanks for the workaround with the -NoNewWindow. That's quite useful.

  6. bobsira commented on Oct 15, 2026

    @bobsira
    bob sira (bobsira)
    on Oct 15, 2026

    Mitigation: update the container host and reimport affected images

    For Windows Server 2019 hosts running servercore:ltsc2019 containers:

    1. Update the container host and reboot. The correction is included in KB5120238 (OS build 17763.9121). Install the current applicable cumulative update; a host already on newer supported servicing does not need to revert to the August update. Apply the update to the container host, not inside the container.

    2. Pull the image after the host has been updated and rebooted. If the affected image was already imported before patching, remove the old cached copy first. Schedule a maintenance window, back up application data, retain the configuration needed to recreate containers, and stop affected workloads.

      Cleanup warning: docker system prune -f removes all stopped containers, unused networks, dangling images and unused build cache. Data stored only in deleted containers' writable layers is lost unless backed up. Volumes are not removed by this command by default, but application backups are still necessary. Use this cleanup only when those resources can safely be removed.

      For a previously imported affected image, use the following sequence, substituting your actual image tag or digest if different:

      docker rmi mcr.microsoft.com/windows/servercore:ltsc2019
docker system prune -f
docker pull mcr.microsoft.com/windows/servercore:ltsc2019

      If docker rmi reports a container dependency, removal has not completed. Confirm the referencing containers are stopped and safe to delete before pruning. Other tags or dependent images may retain layers; resolve remaining references before reimporting. Do not bypass unresolved dependencies with force-removal flags or manually delete Docker storage directories.

      If the image was not previously imported, no cache cleanup is needed; pull it after updating and rebooting the host.

    3. Rebuild dependent images where needed and recreate the containers. Restore application data as required, then repeat the affected installation or launch. For the VC++ redistributable scenario, run vc_redist.x64.exe /install /quiet and confirm successful installation using its exit status and installer logs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingtriageNew and needs attention

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions