Skip to content

Multiple ASP.NET Core-related test projects hang on .NET 11 Preview 4 linux-arm64 #128490

Closed

Description

@gimlichael

Is there an existing issue for this?

  • I have searched the existing issues

Describe the bug

Multiple ASP.NET Core-related test projects hang on .NET 11 Preview 4 when running on linux-arm64.

This appears isolated to ASP.NET Core-related tests in my repository. Non-ASP.NET Core test projects do not appear to fail the same way. The same representative tests pass on .NET 10.0.8 linux-arm64, and the full suite works on Windows runners.

The original CI symptom was that ARM64 Linux jobs eventually failed with exit code 143, after test execution appeared to start but never complete. After isolating locally in an Ubuntu 24.04 ARM64 Docker environment, the hang reproduces with:

  • --no-build
  • --no-restore
  • -p:TestTfmsInParallel=false
  • xUnit test collection parallelization disabled
  • single filtered tests

This suggests the problem is not restore/build, SDK build/test orchestration, multi-TFM parallelism, or xUnit test collection parallelism.

Related prior issue with a similar observable dotnet test hang symptom:

dotnet/sdk#43432

This new case appears different because it still reproduces with --no-build --no-restore and single filtered ASP.NET Core tests.

Expected Behavior

ASP.NET Core middleware/authentication tests should complete on .NET 11 Preview 4 linux-arm64, as the representative tests do on .NET 10.0.8 linux-arm64 and as the suite does on Windows runners.

Steps To Reproduce

Repository / branch for maintainers to clone and test:

https://github.com/codebeltnet/cuemon/tree/v11.0.0/double-digits

Clone command:

git clone https://github.com/codebeltnet/cuemon.git
cd cuemon
git checkout v11.0.0/double-digits

Environment used for local reproduction:

  • Ubuntu 24.04
  • linux-arm64 / aarch64
  • .NET SDK: 11.0.100-preview.4.26230.115
  • Runtime: 11.0.0-preview.4.26230.115
  • xUnit VSTest Adapter: 3.1.5
  • Docker Desktop running linux/arm64 image via QEMU

Comparison environment:

  • Same container/repo setup
  • .NET 10.0.8
  • linux-arm64

Repro 1: authentication test hangs on net11.0

This single test hangs on .NET 11 Preview 4 linux-arm64:

dotnet test test/Cuemon.AspNetCore.Authentication.Tests/Cuemon.AspNetCore.Authentication.Tests.csproj \
  --framework net11.0 \
  --configuration Debug \
  --no-build \
  --no-restore \
  --filter "FullyQualifiedName=Cuemon.AspNetCore.Authentication.Basic.BasicAuthenticationHandlerTest.HandleAuthenticateAsync_ShouldReturn401WithUnauthorizedMessage_WhenAuthenticatorIsNotProbablySetup" \
  --logger "console;verbosity=detailed" \
  --logger "trx;LogFileName=net11.0.arm64.single.trx" \
  --results-directory /tmp/cuemon-results \
  -p:TestTfmsInParallel=false \
  --blame \
  --blame-hang \
  --blame-hang-timeout 45s

Observed:

  • xUnit discovery completes.
  • Test execution starts.
  • The single filtered test hangs.
  • --blame-hang-timeout aborts the run.

The same test passes on .NET 10.0.8 linux-arm64:

dotnet test test/Cuemon.AspNetCore.Authentication.Tests/Cuemon.AspNetCore.Authentication.Tests.csproj \
  --framework net10.0 \
  --configuration Debug \
  --no-build \
  --no-restore \
  --filter "FullyQualifiedName=Cuemon.AspNetCore.Authentication.Basic.BasicAuthenticationHandlerTest.HandleAuthenticateAsync_ShouldReturn401WithUnauthorizedMessage_WhenAuthenticatorIsNotProbablySetup" \
  --logger "console;verbosity=detailed" \
  --logger "trx;LogFileName=net10.0.arm64.single.trx" \
  --results-directory /tmp/cuemon-results \
  -p:TestTfmsInParallel=false \
  --blame \
  --blame-hang \
  --blame-hang-timeout 45s

Observed on .NET 10.0.8:

  • Test run successful
  • Total tests: 1
  • Passed: 1

Repro 2: ASP.NET Core middleware test hangs on net11.0

With xUnit test collection parallelization disabled, this test also hangs on .NET 11 Preview 4 linux-arm64:

dotnet test test/Cuemon.AspNetCore.Tests/Cuemon.AspNetCore.Tests.csproj \
  --framework net11.0 \
  --configuration Debug \
  --no-build \
  --no-restore \
  --filter "FullyQualifiedName=Cuemon.AspNetCore.Hosting.HostingEnvironmentMiddlewareTest.InvokeAsync_ShouldHaveHostingEnvironmentHeader_ConfiguredByIOptions" \
  --logger "console;verbosity=detailed" \
  --logger "trx;LogFileName=Cuemon.AspNetCore.Tests.net11.0.arm64.single.trx" \
  --results-directory /tmp/cuemon-results \
  -p:TestTfmsInParallel=false \
  --blame \
  --blame-hang \
  --blame-hang-timeout 90s

The broader project run also identifies the same test as long-running/hung:

Cuemon.AspNetCore.Hosting.HostingEnvironmentMiddlewareTest.InvokeAsync_ShouldHaveHostingEnvironmentHeader_ConfiguredByIOptions

The same filtered test passes on .NET 10.0.8 linux-arm64:

dotnet test test/Cuemon.AspNetCore.Tests/Cuemon.AspNetCore.Tests.csproj \
  --framework net10.0 \
  --configuration Debug \
  --no-build \
  --no-restore \
  --filter "FullyQualifiedName=Cuemon.AspNetCore.Hosting.HostingEnvironmentMiddlewareTest.InvokeAsync_ShouldHaveHostingEnvironmentHeader_ConfiguredByIOptions" \
  --logger "console;verbosity=detailed" \
  --logger "trx;LogFileName=Cuemon.AspNetCore.Tests.net10.0.arm64.single.trx" \
  --results-directory /tmp/cuemon-results \
  -p:TestTfmsInParallel=false \
  --blame \
  --blame-hang \
  --blame-hang-timeout 90s

Observed on .NET 10.0.8:

  • Test run successful
  • Total tests: 1
  • Passed: 1
  • The test itself completes in about 1 second.

Affected CI pattern

The failing CI jobs are ARM64 Linux jobs for ASP.NET Core-related test projects, including:

  • Cuemon.AspNetCore.Authentication.Tests
  • Cuemon.AspNetCore.FunctionalTests
  • Cuemon.AspNetCore.Mvc.FunctionalTests
  • Cuemon.AspNetCore.Mvc.Tests
  • Cuemon.AspNetCore.Razor.TagHelpers.Tests
  • Cuemon.AspNetCore.Tests
  • Cuemon.Extensions.AspNetCore.Authentication.Tests
  • Cuemon.Extensions.AspNetCore.Mvc.*
  • Cuemon.Extensions.AspNetCore.Tests

Debug and Release ARM64 Linux jobs are affected.

Exceptions (if any)

No managed exception is thrown by the test itself. The testhost hangs until VSTest --blame-hang-timeout aborts the run.

Example output from the net11.0 middleware repro:

[xUnit.net] Starting: Cuemon.AspNetCore.Tests (parallel test collections = off, stop on fail = off, explicit = off, seed = ...)
[xUnit.net] Cuemon.AspNetCore.Tests: [Long Running Test] 'Cuemon.AspNetCore.Hosting.HostingEnvironmentMiddlewareTest.InvokeAsync_ShouldHaveHostingEnvironmentHeader_ConfiguredByIOptions', Elapsed: 00:01:25

Data collector 'Blame' message: The specified inactivity time of 90 seconds has elapsed. Collecting hang dumps from testhost and its child processes.

The active Test Run was aborted because the host process exited unexpectedly.
The test running when the crash occurred:
Cuemon.AspNetCore.Hosting.HostingEnvironmentMiddlewareTest.InvokeAsync_ShouldHaveHostingEnvironmentHeader_ConfiguredByIOptions

Local Docker ARM64 via QEMU cannot produce a useful dump because createdump fails with:

ptrace(ATTACH, ...) FAILED Function not implemented (38)

I believe this is a QEMU/user-mode diagnostic limitation, not the underlying product failure. A native ubuntu-24.04-arm GitHub Actions runner may be better suited for dump capture.

.NET Version

11.0.100-preview.4.26230.115

Anything else?

dotnet --info from the ARM64 repro container:

.NET SDK:
 Version:           11.0.100-preview.4.26230.115
 Commit:            4370ea1634
 Workload version:  11.0.100-manifests.bd820daa
 MSBuild version:   18.7.0-preview-26230-115+4370ea163

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  24.04
 OS Platform: Linux
 RID:         linux-arm64
 Base Path:   /usr/share/dotnet/sdk/11.0.100-preview.4.26230.115/

Host:
  Version:      11.0.0-preview.4.26230.115
  Architecture: arm64
  Commit:       4370ea1634

.NET SDKs installed:
  10.0.100 [/usr/share/dotnet/sdk]
  11.0.100-preview.4.26230.115 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 10.0.8 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 11.0.0-preview.4.26230.115 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 10.0.8 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 11.0.0-preview.4.26230.115 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Notes:

  • The repro was isolated in a clean Linux copy of the repository to avoid Windows-generated obj files leaking Visual Studio/NuGet fallback paths into the container.
  • The issue reproduces with --no-build --no-restore.
  • The issue reproduces with -p:TestTfmsInParallel=false.
  • The issue reproduces with xUnit test collection parallelization disabled.
  • At least two independent ASP.NET Core-related representative tests hang on net11.0 linux-arm64.
  • The same representative tests pass on net10.0 linux-arm64.
  • Windows runners pass.
  • Original CI symptom was exit code 143, consistent with the hung test process eventually being terminated.
  • This was found in a mature multi-targeted OSS codebase rather than a synthetic minimal repro. The single-test filters above are the current minimized repros.

cuemon-results.zip

.NET Version

11.0.100-preview.4.26230.115

Anything else?

CI platform matrix

The CI pipeline exercises a broad OS/architecture/configuration matrix:

  • Linux x64: ubuntu-24.04
  • Linux ARM64: ubuntu-24.04-arm
  • Windows x64: windows-2025
  • Windows ARM64: windows-11-arm
  • Configurations: Debug and Release
  • Test projects: generated dynamically from test/**/*.csproj, except Cuemon.Data.SqlClient.Tests.csproj

The relevant workflow is:

https://github.com/codebeltnet/cuemon/blob/v11.0.0/double-digits/.github/workflows/ci-pipeline.yml

The failures are concentrated in ASP.NET Core-related test projects on Linux ARM64. The Windows matrix passes, and representative tests pass on .NET 10.0.8 linux-arm64.

Activity

  1. github-actions commented on May 20, 2026

    @github-actions
    Contributor

    Triage Summary

    Area: area-middleware (the explicit repros involve HostingEnvironmentMiddlewareTest and BasicAuthenticationHandlerTest — both are middleware/pipeline concerns; the pattern of hangs spans the entire ASP.NET Core middleware stack on linux-arm64)
    Type: bug (reproducible regression — tests pass on .NET 10.0.8 linux-arm64 but hang indefinitely on .NET 11 Preview 4 linux-arm64)

    Regression Info

    • Previously working version: .NET 10.0.8 / ASP.NET Core 10.0.8
    • Broken since: .NET 11 Preview 4 (11.0.0-preview.4.26230.115)
    • ASP.NET Core middleware and authentication tests complete successfully on .NET 10.0.8 linux-arm64 (in ~1s), but hang indefinitely on .NET 11 Preview 4 linux-arm64, eventually being aborted by --blame-hang-timeout. The issue is architecture-specific (linux-arm64 only; Windows runners and linux-x64 are unaffected).

    Potential Duplicates

    • None found — searches for similar hang/arm64 reports in this repo returned no matching open issues.

    Notes

    • The repro is in a third-party OSS repository (codebeltnet/cuemon), not in aspnetcore itself, but the hang is isolated to ASP.NET Core-related test projects vs. non-ASP.NET Core tests in the same repo.
    • The hang reproduces with --no-build --no-restore, single filtered tests, and xUnit parallelism disabled — ruling out restore, build, and parallelism as causes.
    • Multiple affected areas (authentication, middleware, MVC, Razor, etc.) suggest a low-level regression — possibly in TestHost, Kestrel, or the async/IO plumbing on arm64.
    • A core runtime regression may also be involved; it may be worth cross-filing or checking with the dotnet/runtime team for arm64-specific async/threading changes between .NET 10 and .NET 11 Preview 4.
    • A native ubuntu-24.04-arm runner (not QEMU) would be needed to capture a useful hang dump for further diagnosis.

    Generated by Issue Triage Agent for dotnet/aspnetcore for issue #128490 · ● 1.6M · ◷

  2. Youssef1313 commented on May 21, 2026

    @Youssef1313
    Member

    @gimlichael Thanks for raising this. Can you please provide us with the hang dump so we can investigate this?

  3. gimlichael commented on May 21, 2026

    @gimlichael
    Author

    @Youssef1313 - although I can reproduce this locally, I cannot provide a useful hang dump from my setup because the ARM64 container is running via QEMU and createdump fails with:

    ptrace(ATTACH, ...) FAILED Function not implemented (38)
    

    The issue contains the branch, exact commands, and single-test repros. Since this likely needs native ARM64 diagnostics, could someone on the ASP.NET Core/.NET side collect the hang dump from native ARM64 hardware or a native ubuntu-24.04-arm runner?

    Considered the amount of time I have invested into this Preview 4 issue, I would hope you guys can take over from here.
    Last time it was a .NET 9 preview issue - this time its a .NET 11 .. and my library is just complex enough to trigger these edge cases.

    I gladly assist - but as far as providing more evidence, I think you should have enough to get your going.

    Maybe reach out to nohwnd - he already has experience with my repo and assumedly also with these edge cases?

    Thank you for your understanding regarding this matter.

  4. Youssef1313 commented on May 22, 2026

    @Youssef1313
    Member

    @gimlichael

    CSC : error CS7027: Error signing output with public key from file '/home/runner/work/cuemon/cuemon/cuemon.snk' -- Could not find file '/home/runner/work/cuemon/cuemon/cuemon.snk'. [/home/runner/work/cuemon/cuemon/src/Cuemon.Kernel/Cuemon.Kernel.csproj::TargetFramework=net11.0]
    

    Looks like one of the steps in your CI is also downloading the snk via some secret or something.

  5. Youssef1313 commented on May 22, 2026

    @Youssef1313
    Member

    Reproduced in https://github.com/Youssef1313/cuemon/actions/runs/26274332290/job/77334876685.

    I'll extract the dumps from GH Actions.

  6. Youssef1313 commented on May 22, 2026

    @Youssef1313
    Member
    • This might be ARM-specific
    • Hang dump is pointing at UseDefaultServiceProvider from Microsoft.Extensions.Hosting, but apparent locks or anything there.
    Image Image

    Probably stuck in native code?

  7. gimlichael commented on May 22, 2026

    @gimlichael
    Author

    @Youssef1313 thanks for the thorough investigation - I have two tasks; update docs for Cuemon and see if this is .NET 11 Preview 4 bug only triggered in my sister library, xUnit Extensions.

  8. added theissue type on May 22, 2026
  9. Youssef1313 commented on May 22, 2026

    @Youssef1313
    Member

    This is ARM-specific. So it's more likely to be a runtime issue.

    @AndyAyersMS Could this be related to #127293 which didn't make it into preview 4?

    I don't have enough capacity to test this with preview 5 right now though.

  10. 4 remaining items

  11. added
    area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
    and removed
    untriagedNew issue has not been triaged by the area owner
    on May 22, 2026
  12. added this to the 11.0.0 milestone on May 22, 2026
  13. AndyAyersMS commented on May 22, 2026

    @AndyAyersMS
    Member

    This should be already fixed; will keep it open pending confirmation of the fix (once Preview 5 is out).

  14. dotnet-policy-service commented on May 22, 2026

    @dotnet-policy-service
    Contributor

    Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
    See info in area-owners.md if you want to be subscribed.

  15. Youssef1313 commented on May 22, 2026

    @Youssef1313
    Member

    @gimlichael Can you please try DOTNET_ReadyToRun=0 dotnet test and let us know?

  16. gimlichael commented on May 22, 2026

    @gimlichael
    Author

    Yes, when I am back home from Mandalorian and Grogu. Thanks for taking the time with this issue ✨️

  17. gimlichael commented on May 22, 2026

    @gimlichael
    Author

    @Youssef1313 and @AndyAyersMS - confirmed with my sister library that i made a troubleshooting branch from: https://github.com/codebeltnet/xunit/blob/v11.0.0/arm64-issue-66760/.github/workflows/ci-pipeline.yml

    It works with the env. trick that i had to pass like this directly to dotnet test --environment DOTNET_ReadyToRun=0
    Did the same for cuemon and seems like its also working: https://github.com/codebeltnet/cuemon/blob/v11.0.0/double-digits/.github/workflows/ci-pipeline.yml


    To those of interest; just got home and was excited to try out the workaround, I accidently used Claude Haiku 4.5 to propose a suggestion after hinting to use the flexible test-arguments approach. After first fail - I asked Chat GPT 5.5 and it solved it neatly.

  18. AndyAyersMS commented on May 22, 2026

    @AndyAyersMS
    Member

    Ok, good.

    Preview 5 should be available around June 9th. When it comes out, will you be able to confirm that it fixes the problem?

  19. gimlichael commented on Jun 29, 2026

    @gimlichael
    Author

    A little late to the party - but preview 5 has fixed this issue. Thanks.

  20. locked and limited conversation to collaborators on Jul 30, 2026
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

    area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

    Type

    Projects

    • Status
      No status

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions