IHostedService.StopAsync not invoked with `8.0-windowsservercore-ltsc2019` image

[SaurabhSunil]

Describe the bug

We are using A .NET 8.0 hosted service application on a windows container based on mcr.microsoft.com/dotnet/runtime:8.0-windowsservercore-ltsc2019 as base.

We are getting a weird behavior where the HostedService.StopAsync is not invoked on container shut down.

The same application is working fine when
`mcr.microsoft.com/dotnet/runtime:8.0-nanoserver-1809' is used.

Which .NET image(s) are you using?

mcr.microsoft.com/dotnet/runtime:8.0-windowsservercore-ltsc2019, `mcr.microsoft.com/dotnet/runtime:8.0-nanoserver-1809'

Steps to reproduce

Minimal Repro project in https://github.com/SaurabhSunil/Shutdown

##Steps to Reproduce
Build the shutdown project in Debug mode. This is required as docker file uses ./bin/Debug/net8.0 to copy from.
Build the docker image. For this navigate to the Shutdown project location docker build . -t shutdown-trial
Run a container using the image shutdown-trial
Stop the container after starting

Other information

When does this issue occur?
When using mcr.microsoft.com/dotnet/runtime:8.0-windowsservercore-ltsc2019

Does it occur consistently?
Yes

Do you know of any workarounds?
No

Output of docker version

Client:
 Version:           27.2.0
 API version:       1.47
 Go version:        go1.21.13
 Git commit:        3ab4256
 Built:             Tue Aug 27 14:17:17 2024
 OS/Arch:           windows/amd64
 Context:           desktop-windows

Server: Docker Desktop 4.34.2 (167172)
 Engine:
  Version:          27.2.0
  API version:      1.47 (minimum version 1.24)
  Go version:       go1.21.13
  Git commit:       3ab5c7d
  Built:            Tue Aug 27 14:16:14 2024
  OS/Arch:          windows/amd64
  Experimental:     false

Output of docker info

Client:
 Version:    27.2.0
 Context:    desktop-windows
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.16.2-desktop.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-buildx.exe
  compose: Docker Compose (Docker Inc.)
    Version:  v2.29.2-desktop.2
    Path:     C:\Program Files\Docker\cli-plugins\docker-compose.exe
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.34
    Path:     C:\Program Files\Docker\cli-plugins\docker-debug.exe
  desktop: Docker Desktop commands (Alpha) (Docker Inc.)
    Version:  v0.0.15
    Path:     C:\Program Files\Docker\cli-plugins\docker-desktop.exe
  dev: Docker Dev Environments (Docker Inc.)
    Version:  v0.1.2
    Path:     C:\Program Files\Docker\cli-plugins\docker-dev.exe
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.25
    Path:     C:\Program Files\Docker\cli-plugins\docker-extension.exe
  feedback: Provide feedback, right in your terminal! (Docker Inc.)
    Version:  v1.0.5
    Path:     C:\Program Files\Docker\cli-plugins\docker-feedback.exe
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.3.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-init.exe
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-sbom.exe
  scout: Docker Scout (Docker Inc.)
    Version:  v1.13.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-scout.exe

Server:
 Containers: 2
  Running: 0
  Paused: 0
  Stopped: 2
 Images: 11
 Server Version: 27.2.0
 Storage Driver: windowsfilter
  Windows:
 Logging Driver: json-file
 Plugins:
  Volume: local
  Network: ics internal l2bridge l2tunnel nat null overlay private transparent
  Log: awslogs etwlogs fluentd gcplogs gelf json-file local splunk syslog
 Swarm: inactive
 Default Isolation: hyperv
 Kernel Version: 10.0 19045 (19041.1.amd64fre.vb_release.191206-1406)
 Operating System: Microsoft Windows Version 22H2 (OS Build 19045.5737)
 OSType: windows
 Architecture: x86_64
 CPUs: 24
 Total Memory: 63.69GiB
 Name: XXXXXXXX
 ID: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 Docker Root Dir: C:\ProgramData\Docker
 Debug Mode: false
 Labels:
  com.docker.desktop.address=npipe://\\.\pipe\docker_cli
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine

[lbussell]

Thank you for the detailed repro. I was able to reproduce this with the following steps:

• dotnet build --configuration Debug
• pushd Shutdown
• docker build --pull -t shutdown-trial .
• docker run --rm shutdown-trial
• Stop the container from Docker Desktop GUI
• Confirmed that Starting my Application... was shown but not Stopping my Application...
• Confirmed that both Starting my Application... and Stopping my Application... are shown when using a nanoserver-1809 image.

I also confirmed this behavior occurs when building the App inside the Dockerfile like so:

FROM mcr.microsoft.com/dotnet/sdk:8.0-windowsservercore-ltsc2019 AS build
WORKDIR /source
COPY *.csproj .
RUN dotnet restore
COPY . .
RUN dotnet publish --configuration Debug -o /app

FROM mcr.microsoft.com/dotnet/runtime:8.0-windowsservercore-ltsc2019
WORKDIR /app
COPY --from=build /app .
USER ContainerUser
ENTRYPOINT ["dotnet", "Shutdown.dll"]

I also tested the following variables:

• Microsoft.Extensions.Hosting version 8.0.1 vs. 9.0.4 (no change)
• .NET 8 vs. .NET 9 SDK and TargetFramework (no change)
• Release vs. Debug publish configuration (no change)
• windowsservercore-ltsc2025 images (no change)

/cc @jkotas - should we transfer this to the runtime repo for further investigation?

[lbussell]

Transferred to runtime since this might be a bug with Microsoft.Extensions.Hosting.

[iJinsPeter]

Thank you too for taking this up too..
Introducing myself, I worked with @SaurabhSunil on identifying this issue and making a repro

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-extensions-hosting
See info in area-owners.md if you want to be subscribed.

[ericstj]

I suspect this is the same Windows Service shutdown bug being discussed in #83093

Can you try the workaround we mention there #83093 (comment) - that can help us understand if this is the same bug.

    using var registration = PosixSignalRegistration.Create(PosixSignal.SIGTERM, (context) => context.Cancel = true);