Skip to content

[✨ Triage] dotnet/runtime#127129 by VincentBu - Test failure: System.Net.Quic.Tests.MsQuicPlatformDetectionTests.Sup ... #200

@MihuBot

Description

@MihuBot

Triage for dotnet/runtime#127129.
Repo filter: All networking issues.
MihuBot version: 5a5ee7.
Ping MihaZupan for any issues.

This is a test triage report generated by AI, aimed at helping the triage team quickly identify past issues/PRs that may be related.
Take any conclusions with a large grain of salt.

Tool logs
dotnet/runtime#127129: Test failure: System.Net.Quic.Tests.MsQuicPlatformDetectionTests.SupportedWindowsPlatforms_IsSupportedIsTrue by VincentBu
Extracted 5 search queries: MsQuicPlatformDetectionTests.SupportedWindowsPlatforms_IsSupportedIsTrue assertion failure (expected True, got False), System.Net.Quic msquic IsSupported returns false on Windows 11 Arm64 ReadyToRun (crossgen2), Quic platform detection failing on Windows 11 ARM64 TestReadyToRun builds, System.Net.Quic MsQuic detection test failing under crossgen2 / ReadyToRun runtime, SupportedWindowsPlatforms_IsSupportedIsTrue test failure in System.Net.Quic.Tests
Found 25 candidate issues
  • Issue #82885 (Mar 2023) - Test failure System.Net.Quic.Tests.MsQuicPlatformDetectionTests.SupportedWindowsPlatforms_IsSupportedIsTrue
    Summary: Same failing test reported on Windows ARM64. Discussion traced it to changes around which msquic bits we consume for ARM (switch to internal feed / packaging differences) and lack of test coverage for that change. Outcome: the test was temporarily disabled (follow-up PRs addressed packaging). Useful background for an ARM64 Windows IsSupported=false failure.

  • PR #73713 (Aug 2022) - consume MsQuic 2.1 for windows ARM64 builds
    Summary: Adds consumption of Windows ARM64 msquic DLLs (MsQuic 2.1) because CI didn’t have a build pipeline for ARM. Shows we historically handled Windows/ARM msquic specially — relevant if tests run against different msquic build artifacts.

  • Issue #81447 (Jan 2023) - msquic.dll is no longer included in the Windows shared runtime
    Summary: A repo change accidentally stopped placing msquic.dll into the shared runtime packaging, which made Quic.IsSupported return false on Windows and caused tests to be skipped or fail. The root cause in csproj conditions was fixed (PRs #81490/#81492) and a test was added to catch regressions. Very relevant: missing msquic.dll yields the exact symptom (IsSupported == false).

  • PR #82780 (Feb 2023) - [QUIC] Disable failing test on arm machines
    Summary: A small PR to disable the failing test on ARM machines (consequence of ARM-specific msquic issues). Shows that at times the team chose to gate/disable the test while addressing msquic packaging/compatibility.

  • PR #83104 (Mar 2023) - get transport MsQuic for Windows arm64
    Summary: Reverts an earlier temporary disable and ensures ARM64 Windows msquic transport bits are available again (addresses #82885). If your failure is due to missing/incorrect ARM msquic bits, this PR is the corrective action that was taken in 2023.

  • PR #81481 (Feb 2023) - [QUIC] Added tests to check IsSupported
    Summary: Introduced the MsQuicPlatformDetectionTests (including SupportedWindowsPlatforms_IsSupportedIsTrue). The PR discussion explains the test intent and trade-offs (how to detect native msquic presence vs. loadability). Good to review to understand what the test asserts (expected msquic presence/loadability on CI images).

  • Issue #74952 (Sep 2022) - System.Exception : Failed to create MsQuicApi instance
    Summary: Reports ARM64 failures where msquic initialization failed (QUIC_STATUS_OUT_OF_MEMORY from msquic, actually pthread_create failures). Discussion covered that MsQuic sometimes fails to initialize on some ARM CI environments and that the error can manifest as IsSupported==false or initialization exceptions. Shows another class of ARM-specific msquic failures (not just missing DLL).

  • Issue #82316 (Feb 2023) - dotnet seems to abort when libmsquic exist but cannot be loaded
    Summary: On Linux the native loader (NativeLibrary.TryLoad) can return a handle even when dependencies are missing, leading to crashes later when calling into msquic. Team discussion concluded there's little product-side remedy besides being careful and that native lib bugs can cause process crashes. Relevant conceptually: presence of msquic file does not guarantee successful load/usable IsSupported.

  • Issue #82077 (Feb 2023) - SupportedLinuxPlatforms_IsSupportedIsTrue fails on distros without quic
    Summary: The test suite initially assumed msquic availability on CI images; that caused failures on distros without msquic. Discussion settled on making tests skip appropriately (or detect libmsquic loadability). Useful precedent: tests need to handle missing native support gracefully and CI images must be aligned with test expectations.

  • PR #125772 (Mar 19 2026) - [QUIC] Disable platform tests as well
    Summary: More recent (Mar 2026) change to skip MsQuicPlatformDetectionTests on problematic VMs (AzureLinux 3) where msquic can fail with OUT_OF_MEMORY. Shows the team continues to disable/suppress platform detection tests in specific hostile CI environments rather than risk flaky failures.

  • Issue #87275 (Jun 2023) and Issue #87038 (Jun 2023) - MsQuicPlatformDetectionTests failures in CI / Failing test SupportedLinuxPlatforms_IsSupportedIsTrue
    Summary: Broad CI flakiness across many legs caused by msquic package republishing (libnuma dependency, other payload/packaging churn) and by msquic initialization issues. The team tracked package/CI image changes and updated images or msquic package versions; sometimes tests were disabled while fixes rolled out. Reinforces that IsSupported failures often track packaging, native dependency, or msquic-internal changes rather than managed test code.

  • PR #82933 (Mar 2023) - use PlatformSpecific attribute to suppress platform specific Quic tests
    Summary: Adjusts test attributes to avoid noisy conditional skips on platforms where tests are not applicable. Shows test infra evolution to reduce noise and avoid confusing ConditionalFact skip logs.

Takeaways for the new failure (System.Net.Quic.Tests.MsQuicPlatformDetectionTests.SupportedWindowsPlatforms_IsSupportedIsTrue on Windows/ARM64):

  • Historically the same test failure has been caused by msquic packaging/consumption for Windows ARM64 (missing or wrong msquic.dll in runtime/testhost), by msquic initialization failures on ARM CI, or by changes to csproj packaging that removed msquic from the shared runtime (fixed in 2023).
  • The team often responds by: (a) ensuring correct msquic bits for Windows ARM64 (consume appropriate msquic packages / PRs like #73713 / #83104), (b) fixing packaging conditions so msquic.dll is included in the shared runtime (fixed via #81490/#81492), or (c) disabling/suppressing tests on specific broken CI images while the native issue is fixed.
  • Next diagnostics to check (based on past threads): verify the msquic.dll present in the testhost/shared framework for Windows.Arm64, check msquic version/backend (SChannel vs OpenSSL), and inspect native load/init errors in the Helix logs (DLL missing, unresolved symbols, or msquic init errors such as worker thread failures).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions