Blazor debugging captures unrelated debug sessions and terminates them together

[ellahathaway]

Summary

While a Blazor WebAssembly debugging session is active, the C# extension captures unrelated debug sessions that start afterward. Closing the Blazor browser then terminates those unrelated sessions. The reverse also happens: stopping an unrelated session started after Blazor attachment terminates the Blazor browser and managed debugger.

Reproduced with the actual Marketplace C# extension, a real Edge browser rendering a Blazor WebAssembly app, monovsdbg_wasm, and independent Node debug processes. No provider mocks, replacement debug adapters, or Aspire extension code were used. Both directions reproduced in two complete runs.

Sessions started before Blazor attachment are unaffected: a preexisting Node session remained active and its process heartbeat continued advancing after both teardown scenarios.

Environment data

• Windows ARM64, OS build 10.0.26200.
• VS Code 1.137.0, commit 645f29cc3176500b4b5762ba887cf2a7f0ffdf2c.
• ms-dotnettools.csharp 2.148.23, Marketplace win32-arm64 VSIX.
• C# Dev Kit 3.20.207; .NET Install Tool 3.1.0.
• .NET SDK 10.0.112; standalone Blazor WebAssembly template targeting net10.0, WebAssembly/DevServer packages 10.0.12.
• Edge 152.0.4191.62, headless.
• Node 25.9.0 for the independent debuggees; extension-host Node 24.18.1.
• Execution used an isolated VS Code Extension Development Host with dedicated user-data and extension directories. Normal installed extensions/settings were not modified.

Inspected source: tag v2.148.23-prerelease, commit 2f5806a9f39575bfaf4ca16445f420440a43e050.

Steps to reproduce

The following sequence was executed through the VS Code debug API in the isolated Extension Development Host. All root sessions were launched independently: no compound launch, parent-session argument, or explicit cascade setting was assigned to either Node configuration.

1. Create and run a standalone .NET 10 Blazor WebAssembly app (dotnet new blazorwasm). Open the client folder in VS Code and wait for C#/Razor initialization.
2. Start an independent Node debug session named preexisting. Its program writes a heartbeat every 200 ms, allowing survival to be checked independently of VS Code's session list.
3. Start Blazor debugging against the already-running app using the configuration below. Wait for the actual browser/page sessions and monovsdbg_wasm, and for the page to render.
4. Start another independent Node debug session named unrelated-after, running the same heartbeat program.
5. Scenario A: close only the Blazor browser. In the executed reproduction, this was a CDP Browser.close request to the browser's real debugger endpoint, not a VS Code stop-all operation.
6. Observe that unrelated-after also terminates, although it has no relationship to the Blazor app. preexisting remains active and its heartbeat continues.
7. Repeat steps 2–4 with fresh sessions. Scenario B: call vscode.debug.stopDebugging(unrelatedAfterSession) for only the later Node root session.
8. Observe that the Blazor browser/page and monovsdbg_wasm also terminate. Again, preexisting survives and continues executing.

Blazor configuration used by the reproduction (paths and URL below are placeholders):

{
    type: "blazorwasm",
    request: "attach",
    name: "blazor-browser",
    projectPath: "<absolute path to BlazorClient.csproj>",
    cwd: "<absolute path to BlazorClient>",
    url: "<running Blazor server URL>",
    browser: "edge",
    webRoot: "<absolute path to BlazorClient/wwwroot>",
    browserConfig: {
        userDataDir: "<isolated browser profile>",
        runtimeArgs: [
            "--headless=new",
            "--no-first-run",
            "--no-default-browser-check"
        ],
        trace: true
    }
}

The independent sessions use ordinary pwa-node configurations with request: "launch", distinct names, program pointing at a long-running Node script, and console: "internalConsole". They are launched with vscode.debug.startDebugging(undefined, configuration) and no third argument. A minimal long-running program is:

setInterval(() => console.log(`heartbeat ${Date.now()}`), 200);

The executed driver additionally writes heartbeats to separate files and asserts that the preexisting process keeps executing after teardown. Browser rendering was confirmed through the page session's DAP evaluate request: document.body.innerText.includes("Hello, world!") returned true before starting the unrelated session.

Expected behavior

Only debug sessions owned by the same Blazor launch should participate in its cascade termination. An independent session must remain independent regardless of whether it starts before or after Blazor attachment.

• Closing the Blazor browser should not stop an unrelated Node session.
• Stopping that Node session should not stop Blazor debugging.

Actual behavior

Trigger	Blazor browser/managed sessions	Unrelated session started after attach	Preexisting session
CDP Browser.close	Terminated	Unexpectedly terminated	Survived; heartbeat advanced
Stop only unrelated-after	Unexpectedly terminated	Terminated as requested	Survived; heartbeat advanced

Logs / runtime evidence

Condensed from the successful onDidStartDebugSession / onDidTerminateDebugSession event trace on September 11, 2026 (UTC). The driver observes events; it does not stop any additional sessions until after recording each scenario result.

15:35:40.153  started preexisting (pwa-node)
15:35:40.958  requested Blazor attach
15:35:44.969  started Wasm Managed Debugger (monovsdbg_wasm)
15:35:48.852  started Blazor browser (pwa-msedge)
15:35:56.335  Blazor DOM rendering confirmed
15:35:56.846  started unrelated-after (pwa-node)
15:35:57.514  requested CDP Browser.close
15:35:57.885  browser page terminated
15:35:58.836  managed debugger terminated
15:35:58.863  browser root terminated
15:36:02.642  unrelated-after root terminated
15:36:03.007  result: preexisting survived; heartbeat advanced

15:36:06.129  requested fresh Blazor attach (after fresh preexisting Node start)
15:36:08.897  started Wasm Managed Debugger (monovsdbg_wasm)
15:36:13.947  started Blazor browser (pwa-msedge)
15:36:22.845  Blazor DOM rendering confirmed
15:36:24.028  started unrelated-after (pwa-node)
15:36:24.900  requested stopDebugging(unrelatedAfterSession) only
15:36:25.720  unrelated-after root terminated
15:36:25.772  browser page terminated
15:36:26.594  managed debugger terminated
15:36:26.621  browser root terminated
15:36:26.835  result: preexisting survived; heartbeat advanced

An earlier complete run reproduced both directions at 15:28 UTC as well. Raw C# diagnostics contain machine-local paths and are omitted here; the structured trace above contains the directly observed lifecycle evidence.

Code gap

The observed timing matches the static tracking in BlazorDebugConfigurationProvider:

1. Lines 73–98: one static tracking flag/set/map; onDidStartDebugSession captures every session while tracking is enabled, with no ownership or launch-group filter.
2. Lines 101–116: when any captured session terminates, the handler calls stopDebugging on every captured peer.
3. Lines 136–142: resolveDebugConfiguration clears the collections and enables tracking. Tracking remains enabled until a captured session terminates, rather than being scoped to sessions owned by this launch.
4. Lines 795–800: tryToUseVSDbgForMono enables the same global state.

Please scope cascade tracking to the sessions owned by each Blazor launch, with regression coverage for unrelated sessions started during an active Blazor session in both termination directions.

Additional context

This was identified while reviewing the new managed-browser integration in microsoft/aspire#20001, which calls the high-level blazorwasm attach provider. The reproduction deliberately omits Aspire to isolate the upstream behavior.

This is distinct from #7864 (processes left running/port conflicts after closing debugging) and #7386 (an older C# Dev Kit/Aspire shutdown issue).

The successful reproduction used a headless browser and VS Code API automation, not UI-click automation. It confirms real browser rendering and managed-debugger lifetime, but does not assert a managed C# breakpoint or cover two simultaneous Blazor launch groups. All reproduction-owned processes were cleaned up afterward.

[gregg-miskelly]

CC @thaystg