Fatal "Desktop CLR vs CoreCLR" debugger crash in VS Test Explorer when debugging xunit.v3 tests (net10.0, VS 2026 18.9.2)

Description

Debugging any xunit.v3 test via the Visual Studio Test Explorer's "Debug" command crashes VS immediately with:

A fatal error has occurred and debugging needs to be terminated. The debugger was
configured to use the Desktop CLR (.NET Framework) Managed debugger, but the target
process loaded the CoreCLR (.NET Core) runtime. To debug this project, configure it
to use the 'Managed (CoreCLR)' debugger.

This reproduces even on the simplest possible test (no external dependencies at all):

public class GeneralTests(ITestOutputHelper output)
{
    [Fact]
    public async Task GetRSA()
    {
        RSA rSA = RSA.Create();
        output.WriteLine("Public: " + Convert.ToBase64String(rSA.ExportRSAPublicKey()));
    }
}

• Running the same test (no debugger) via Test Explorer works fine and produces correct pass/fail results.
• F5-debugging a normal ASP.NET Core project (non-test) in the same solution, same VS instance, works fine and hits breakpoints normally — confirming the CoreCLR managed debug engine itself is installed and functional.
• Switching the exact same test project from xunit.v3 to classic xunit v2 (keeping xunit.runner.visualstudio 4.0.0 as the adapter) makes Test Explorer debugging work correctly again — breakpoints are hit as expected.

This strongly points to a bug specific to how the debug engine is selected/negotiated when Test Explorer launches the Microsoft Testing Platform (MTP) native host built by xunit.v3, as opposed to the classic VSTest testhost.exe path used by xunit v2.

Environment

• Visual Studio Community 2026, version 18.9.2 (build 18.9.12120.119)
• .NET SDK 10.0.400
• Test project: Microsoft.NET.Sdk.Web, TargetFramework net10.0
• Packages: Microsoft.NET.Test.Sdk 18.9.0, xunit.v3 4.0.0, xunit.runner.visualstudio 4.0.0

Repro steps

1. Create/open a net10.0 test project referencing xunit.v3 4.0.0, xunit.runner.visualstudio 4.0.0, Microsoft.NET.Test.Sdk 18.9.0.
2. Add a trivial [Fact] test (no fixtures, no external dependencies).
3. In Test Explorer, right-click the test → Debug.
4. VS immediately shows the fatal error dialog above and terminates the debug session.

Expected

The debugger attaches using the Managed (CoreCLR) engine and stops at breakpoints, same as it does for classic xunit v2 / VSTest-hosted tests.

Actual

Fatal crash dialog every time; debug session is torn down immediately.

What we already ruled out

Before concluding this is a framework/adapter-side issue, we ruled out:

• Full repair of Visual Studio (Community + Build Tools workloads)
• Full repair/reinstall of the .NET 10 SDK
• Deleting bin/obj/.vs and doing a clean rebuild
• Resetting the entire VS instance profile (%LocalAppData%\Microsoft\VisualStudio\<instance>, forcing a from-scratch MEF/registry rebuild)
• devenv /updateconfiguration
• Rebooting the machine
• Third-party VS extensions (none relevant installed)
• Setting <UseMicrosoftTestingPlatformRunner>false</UseMicrosoftTestingPlatformRunner> in the test project (no effect on the crash)

Separately, we also found that the VS "Just-In-Time debugger" individual component being uninstalled caused classic xunit v2 tests to silently fall back to a non-debugged "Run" when "Debug" was clicked (no error, just no breakpoint hit, no debug UI). Installing that component fixed the v2 path completely. It had no effect on the xunit.v3 fatal crash — that persisted with the component installed, and only reverting to xunit v2 resolved it. So these appear to be two independent issues.

Additional notes

Happy to provide a minimal repro repository if useful — the trivial GetRSA test above already triggers this in isolation, so a repro project should be very small.

Start with the minimal net10.0 C# test project and reproduce the failure from Visual Studio Test Explorer's Debug command. Compare the xunit.v3 Microsoft Testing Platform native-host path with the working xunit v2 VSTest path; done means the xunit.v3 test starts with the Managed (CoreCLR) debugger and breakpoints are hit.