Repository navigation
Description
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:
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-digitsEnvironment 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/arm64image via QEMU
Comparison environment:
- Same container/repo setup
.NET 10.0.8linux-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 45sObserved:
- xUnit discovery completes.
- Test execution starts.
- The single filtered test hangs.
--blame-hang-timeoutaborts 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 45sObserved 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 90sThe 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 90sObserved 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.TestsCuemon.AspNetCore.FunctionalTestsCuemon.AspNetCore.Mvc.FunctionalTestsCuemon.AspNetCore.Mvc.TestsCuemon.AspNetCore.Razor.TagHelpers.TestsCuemon.AspNetCore.TestsCuemon.Extensions.AspNetCore.Authentication.TestsCuemon.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
objfiles 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.0linux-arm64. - The same representative tests pass on
net10.0linux-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.
.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:
DebugandRelease - Test projects: generated dynamically from
test/**/*.csproj, exceptCuemon.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.
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsNo status
Activity
github-actions commentedon May 20, 2026
Triage Summary
Area:
area-middleware(the explicit repros involveHostingEnvironmentMiddlewareTestandBasicAuthenticationHandlerTest— 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
--blame-hang-timeout. The issue is architecture-specific (linux-arm64 only; Windows runners and linux-x64 are unaffected).Potential Duplicates
Notes
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.--no-build --no-restore, single filtered tests, and xUnit parallelism disabled — ruling out restore, build, and parallelism as causes.dotnet/runtimeteam for arm64-specific async/threading changes between .NET 10 and .NET 11 Preview 4.ubuntu-24.04-armrunner (not QEMU) would be needed to capture a useful hang dump for further diagnosis.Youssef1313 commentedon May 21, 2026
@gimlichael Thanks for raising this. Can you please provide us with the hang dump so we can investigate this?
gimlichael commentedon May 21, 2026
@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
createdumpfails with: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-armrunner?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.
Youssef1313 commentedon May 22, 2026
@gimlichael
Looks like one of the steps in your CI is also downloading the snk via some secret or something.
Youssef1313 commentedon May 22, 2026
Reproduced in https://github.com/Youssef1313/cuemon/actions/runs/26274332290/job/77334876685.
I'll extract the dumps from GH Actions.
Youssef1313 commentedon May 22, 2026
UseDefaultServiceProviderfromMicrosoft.Extensions.Hosting, but apparent locks or anything there.Probably stuck in native code?
gimlichael commentedon May 22, 2026
@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.
Youssef1313 commentedon May 22, 2026
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.
4 remaining items
AndyAyersMS commentedon May 22, 2026
This should be already fixed; will keep it open pending confirmation of the fix (once Preview 5 is out).
dotnet-policy-service commentedon May 22, 2026
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.
Youssef1313 commentedon May 22, 2026
@gimlichael Can you please try
DOTNET_ReadyToRun=0 dotnet testand let us know?gimlichael commentedon May 22, 2026
Yes, when I am back home from Mandalorian and Grogu. Thanks for taking the time with this issue ✨️
✨ add env variable for dotnet readiness in CI pipeline
🔧 add env variable for dotnet readiness in CI pipeline
gimlichael commentedon May 22, 2026
@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=0Did 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-argumentsapproach. After first fail - I asked Chat GPT 5.5 and it solved it neatly.AndyAyersMS commentedon May 22, 2026
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?
gimlichael commentedon Jun 29, 2026
A little late to the party - but preview 5 has fixed this issue. Thanks.