You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Blazor WebAssembly debugger: decode_ptr_id assertion at startup, BPs solid-red but never hit — VS2026 18.6.0 + dn10 SDK 10.0.300 (similar to #121738 which is reportedly fixed) #128407
VS2026 18.6.0 paired with dn10 SDK 10.0.300 produces an unusable debug experience for a large Standalone Blazor WebAssembly app. The symptoms closely match those reported in #121738, but that issue's final comment indicates a fix shipped in VS 18.3 Insiders 2 — I'm on 18.6.0 (later) and reproducing, so this looks like either a regression or a closely related-but-distinct issue.
A vanilla dotnet new blazorwasm -f net10.0 project on the same machine debugs perfectly. So VS + SDK + browser are functional in isolation; something about my (large, ABP 10.3-based, ~100 project references) solution amplifies the problem.
Reproduction Steps
I do not currently have a minimal repro — the issue appears to be sensitive to solution scale (~100 project refs vs vanilla's ~5). Steps I take when reproducing locally:
Open the solution in VS2026 18.6.0
F5 multi-startup (tenant API + host API + tenant WASM client + host WASM client)
Once the tenant WASM app loads in the browser, set a breakpoint in any reachable C# code (e.g. a Razor page's OnInitializedAsync, a button click handler, an ABP module's ConfigureServices)
Trigger the path
I'm willing to work toward a minimal repro if a maintainer can confirm interest — the scale-dependence makes it non-trivial.
Expected behavior
Breakpoints bind (solid red) and hit when the underlying code executes
No [MONO] * Assertion in the browser console when setting breakpoints
No spurious JS-side breaks at startup
Stopping the debug session completes promptly and releases all file handles
Actual behavior
Three persistent symptoms:
"Play-button plague" — many JS-side breakpoints fire at WASM startup; user has to click play repeatedly before VS hooks up.
Managed breakpoints never hit. VS shows them solid-red (PDB binding succeeds at IDE level) but they're inert at runtime. Stack trace captured in browser console when setting a BP:
[MONO] * Assertion at /__w/1/s/src/runtime/src/mono/mono/component/debugger-agent.c:2043, condition `<disabled>' not met
at Mc (logging.ts:125:60)
at dotnet.native.wasm.wasm_trace_logger
at dotnet.native.wasm.eglib_log_adapter
at dotnet.native.wasm.monoeg_g_logv_nofree
at dotnet.native.wasm.monoeg_assertion_message
at dotnet.native.wasm.mono_assertion_message
at dotnet.native.wasm.mono_assertion_message_disabled
at dotnet.native.wasm.decode_ptr_id (debugger-agent.c:2043)
at dotnet.native.wasm.mono_process_dbg_packet
at dotnet.native.wasm.mono_wasm_send_dbg_command
at ccall (dotnet.native.js:6715)
at mono_wasm_send_dbg_command (debug.ts:94)
at (anonymous) (eval.cdp:1)
at (anonymous) (debug.ts:33)
at configureEmscriptenStartup (startup.ts:340)
Path: startup.ts:340 → onRuntimeInitialized → mono_wasm_runtime_ready (which executes debugger; when globalThis.dotnetDebugger is set) → VS catches the break → CDP eval calls mono_wasm_send_dbg_command with a ptr_id that fails the g_assert (id > 0 && GINT_TO_UINT(id) <= ids[type]->len) check in decode_ptr_id. The agent's state appears corrupted from boot; subsequent BPs are silently inert.
Sometimes accompanied by program exited (with status: 1), but keepRuntimeAlive() is set shortly after.
Stop-debug hangs, eventually requiring "force stop"; leaves a persistent file lock on project-ref DLLs held by devenv.exe (e.g. MyApp.Components.Shared.dll), preventing the next build.
Regression?
Likely. Closest matching issue #121738 was reportedly fixed in VS 18.3 Insiders 2, but I'm reproducing on 18.6.0. Behavioural notes:
I cannot test prior VS2026 versions easily but did upgrade to 18.6.0 mid-investigation with no change in symptoms.
The app debugged correctly under VS 2022 / .NET 8 prior to our dn8 → dn10 upgrade. So the regression entered with the dn10 SDK + VS2026 combination.
A colleague on the same codebase using Rider does not see any of these symptoms — different debug protocol adapter, so the problem looks specific to the VS WASM debug adapter.
Known Workarounds
None that I have found that retain working managed debug. Things tried and confirmed not to fix it:
Disable / comment out our custom service worker registration (the dev SW is a passthrough with no fetch handler, so this was expected to be inert; confirmed).
"Nuclear" cache reset: close VS, kill all helper processes, dotnet build-server shutdown, delete .vs/, all bin/ and obj/ solution-wide, VS ComponentModelCache at %LOCALAPPDATA%\Microsoft\VisualStudio\18.0_*\ComponentModelCache, dotnet restore, browser SW unregister + clear site data. No effect.
VS upgrade from earlier to 18.6.0.
Removing inspectUri from launchSettings.json suppresses the symptoms but only by disabling the managed debug channel entirely — i.e. no debug at all, not a real workaround.
The only thing that works in practice: switch to Rider.
Browser: Chrome (latest stable). Symptom reproduces in Edge too.
Other information
Vanilla comparator on the same machine:dotnet new blazorwasm -f net10.0 in C:\Temp\vanilla-dn10-wasm, opened in VS, F5 — BPs bind AND hit, no play-button plague, no decode_ptr_id assertion, no DLL locks. So this is specifically an interaction between something in the large solution and the VS2026 WASM debug adapter.
Property diff between my csproj and the vanilla template (just the properties I set that vanilla doesn't): BlazorWebAssemblyLoadAllGlobalizationData=true, ServiceWorkerAssetsManifest, WasmFingerprintAssets=false, BlazorFingerprintBlazorJs=false, WasmBuildNative=true, EmitCompilerGeneratedFiles=true. Toggling each individually did not move the needle.
Hypothesis (best guess from outside): the dn10 WASM debug agent's ids[type] array isn't fully populated at the moment VS issues its startup debug commands via CDP eval, leading to out-of-bounds ptr_id lookups in decode_ptr_id. Large solutions may load assemblies more slowly relative to VS's attach pacing, exposing the race. The assertion silently corrupts agent state, and all subsequent BP-set commands then fail to wire through to the runtime.
Happy to provide more diagnostic info, build logs, launchSettings, or work toward a minimal repro if useful — please flag what would be most helpful.
Description
VS2026 18.6.0 paired with dn10 SDK 10.0.300 produces an unusable debug experience for a large Standalone Blazor WebAssembly app. The symptoms closely match those reported in #121738, but that issue's final comment indicates a fix shipped in VS 18.3 Insiders 2 — I'm on 18.6.0 (later) and reproducing, so this looks like either a regression or a closely related-but-distinct issue.
A vanilla
dotnet new blazorwasm -f net10.0project on the same machine debugs perfectly. So VS + SDK + browser are functional in isolation; something about my (large, ABP 10.3-based, ~100 project references) solution amplifies the problem.Reproduction Steps
I do not currently have a minimal repro — the issue appears to be sensitive to solution scale (~100 project refs vs vanilla's ~5). Steps I take when reproducing locally:
OnInitializedAsync, a button click handler, an ABP module'sConfigureServices)I'm willing to work toward a minimal repro if a maintainer can confirm interest — the scale-dependence makes it non-trivial.
Expected behavior
[MONO] * Assertionin the browser console when setting breakpointsActual behavior
Three persistent symptoms:
"Play-button plague" — many JS-side breakpoints fire at WASM startup; user has to click play repeatedly before VS hooks up.
Managed breakpoints never hit. VS shows them solid-red (PDB binding succeeds at IDE level) but they're inert at runtime. Stack trace captured in browser console when setting a BP:
Path:
startup.ts:340→onRuntimeInitialized→mono_wasm_runtime_ready(which executesdebugger;whenglobalThis.dotnetDebuggeris set) → VS catches the break → CDPevalcallsmono_wasm_send_dbg_commandwith aptr_idthat fails theg_assert (id > 0 && GINT_TO_UINT(id) <= ids[type]->len)check indecode_ptr_id. The agent's state appears corrupted from boot; subsequent BPs are silently inert.Sometimes accompanied by
program exited (with status: 1), but keepRuntimeAlive() is setshortly after.Stop-debug hangs, eventually requiring "force stop"; leaves a persistent file lock on project-ref DLLs held by
devenv.exe(e.g.MyApp.Components.Shared.dll), preventing the next build.Regression?
Likely. Closest matching issue #121738 was reportedly fixed in VS 18.3 Insiders 2, but I'm reproducing on 18.6.0. Behavioural notes:
Known Workarounds
None that I have found that retain working managed debug. Things tried and confirmed not to fix it:
WasmBuildNative,OverrideHtmlAssetPlaceholders,<HotReloadEnabled>,WasmFingerprintAssets,BlazorFingerprintBlazorJs,BlazorWebAssemblyLoadAllGlobalizationDataindividually.fetchhandler, so this was expected to be inert; confirmed).dotnet build-server shutdown, delete.vs/, allbin/andobj/solution-wide, VSComponentModelCacheat%LOCALAPPDATA%\Microsoft\VisualStudio\18.0_*\ComponentModelCache,dotnet restore, browser SW unregister + clear site data. No effect.Removing
inspectUrifromlaunchSettings.jsonsuppresses the symptoms but only by disabling the managed debug channel entirely — i.e. no debug at all, not a real workaround.The only thing that works in practice: switch to Rider.
Configuration
Other information
Vanilla comparator on the same machine:
dotnet new blazorwasm -f net10.0inC:\Temp\vanilla-dn10-wasm, opened in VS, F5 — BPs bind AND hit, no play-button plague, nodecode_ptr_idassertion, no DLL locks. So this is specifically an interaction between something in the large solution and the VS2026 WASM debug adapter.Property diff between my csproj and the vanilla template (just the properties I set that vanilla doesn't):
BlazorWebAssemblyLoadAllGlobalizationData=true,ServiceWorkerAssetsManifest,WasmFingerprintAssets=false,BlazorFingerprintBlazorJs=false,WasmBuildNative=true,EmitCompilerGeneratedFiles=true. Toggling each individually did not move the needle.Hypothesis (best guess from outside): the dn10 WASM debug agent's
ids[type]array isn't fully populated at the moment VS issues its startup debug commands via CDP eval, leading to out-of-boundsptr_idlookups indecode_ptr_id. Large solutions may load assemblies more slowly relative to VS's attach pacing, exposing the race. The assertion silently corrupts agent state, and all subsequent BP-set commands then fail to wire through to the runtime.Happy to provide more diagnostic info, build logs, launchSettings, or work toward a minimal repro if useful — please flag what would be most helpful.