Blazor WebAssembly (.NET 10) debug crash: Mono assertion “should not be reached” (class-accessors.c:93) when hitting HttpClient in component; JS debug adapter exits 0xffffffff

[SorenBech2]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

While debugging a standalone Blazor WebAssembly app targeting net10.0, the debugger crashes as soon as a component executes an HttpClient GET during an async method. The browser console shows repeated Mono assertions and then a RuntimeError: memory access out of bounds. Visual Studio then reports both JavaScript debug adapters exiting with code 0xffffffff and terminates the session.

This only happens under debugging with ASP.NET JavaScript debugging enabled. The app runs fine without debugging, and also runs if ASP.NET JS debugging is disabled.

Expected Behavior

Debug session continues and HttpClient calls can be stepped through normally.

Actual

• Browser console repeatedly logs:
  • [MONO] * Assertion: should not be reached at /__w/1/s/src/runtime/src/mono/mono/metadata/class-accessors.c:93
  • Followed by RuntimeError: memory access out of bounds and jit-info.c assertions.
• Visual Studio Output shows:
  • “The program 'localhost:#### « JavaScript debug adapter' has exited with code 4294967295 (0xffffffff).”
  • Eventually iisexpress is torn down.

Steps To Reproduce

1. In Visual Studio:
   • Ensure ASP.NET JS debugging is enabled: Tools > Options > Debugging > General > “Enable JavaScript debugging for ASP.NET (Chrome, Edge, and IE)” = checked.
   • Use either the IIS Express profile or the Project “https” profile that includes inspectUri.
2. F5 to start debugging.
3. Navigate to a page with a component that issues an HttpClient GET to a relative API endpoint during an async method (e.g., OnInitializedAsync or a called method).
4. As soon as the request completes and execution returns to the awaited line, the browser console logs a Mono assertion followed by a WASM RuntimeError and the VS JavaScript debug adapters exit with 0xffffffff.

Exceptions (if any)

(trimmed)
[MONO] * Assertion: should not be reached at /__w/1/s/src/runtime/src/mono/mono/metadata/class-accessors.c:93
Error
at Mc (_framework/dotnet.runtime..js:3:172283)
at dotnet.native.wasm.wasm_trace_logger (…dotnet.native..wasm:wasm-function[16401]:0x383582)
…
at dotnet.native.wasm.get_async_method_builder (…wasm-function[4670]:0x1586d9)
program exited (with status: 1), but keepRuntimeAlive() is set …
RuntimeError: memory access out of bounds
Stack trace:

at dotnet.native.wasm.interp_frame_iter_next (…wasm-function[2675]:0xe0638)
…
[MONO] * Assertion at /__w/1/s/src/runtime/src/mono/mono/metadata/jit-info.c:918, condition `' not met
…
The program 'localhost:#### « JavaScript debug adapter' has exited with code 4294967295 (0xffffffff).

.NET Version

.NET 10.0.100

Anything else?

Environment

• Project type: Standalone Blazor WebAssembly
• Target framework: net10.0
• SDK: .NET 10.0.x
• Packages:
  • Microsoft.AspNetCore.Components.WebAssembly 10.0.0
  • Microsoft.AspNetCore.Components.WebAssembly.DevServer 10.0.0
• Visual Studio 2026 (18.0.0)
• Windows 11 (262000)
• Browser: Edge (142.0.3595.80)
• App specifics:
  • Service worker present (ServiceWorkerAssetsManifest set; wwwroot/service-worker.js configured)
  • <WasmBuildNative>true</WasmBuildNative>; AOT disabled (<RunAOTCompilation> not set)
  • Using IIS Express or the “Project/https” profile with inspectUri enabled

Workarounds tried

• Disable ASP.NET JS debugging in VS: Tools > Options > Debugging > General > uncheck “Enable JavaScript debugging for ASP.NET …” → Avoids crash, but no JS-side debugging.
• Disable Browser Refresh by setting ASPNETCORE_BROWSER_REFRESH_DISABLED=1 in launch profile → No effect.
• Use Kestrel “https” profile instead of IIS Express → No effect.
• Clear browser site data; unregister service worker; delete bin/obj; restart VS → No effect.
• Code variations:
  • Use HttpClient.GetAsync with ResponseContentRead vs SendAsync with ResponseHeadersRead → No effect.
  • Remove using var around HttpResponseMessage → No effect.
  • Add/remove ConfigureAwait(false) → No effect.
• App runs fine without debugging.

[dotnet-policy-service]

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

[steveisok]

@SorenBech2 I'm not able to reproduce your issue following the steps you outlined. Any chance you can supply a repro so that I can better match what you're doing?

[dotnet-policy-service]

This issue has been marked needs-author-action and may be missing some important information.