Wasm debugging from VS Code ends at once when WasmEnableThreads is on, even with no threads started #137142

Description

Related to #81282 (support debugging multi-threaded apps).

Turning on <WasmEnableThreads>true</WasmEnableThreads> makes a .NET browser app impossible to debug from VS Code.
The browser opens, then closes straight away, the debugging session ends, and no breakpoint is hit. The app needn't
start any threads of its own: enabling threads is enough. The same app with threads off debugs normally.

The session goes through the wasm debug proxy (BrowserDebugProxy, which dotnet run's dev server starts at
/_framework/debug/ws-proxy), as the C# extension's blazorwasm launch type sets up.

A workaround is attached under Known Workarounds (dotnet-debug-proxy-workaround.zip). It hosts the SDK's own
BrowserDebugProxy.dll with fixes for five problems the proxy has with Web Workers:

1. Resuming a worker ends the session, and a breakpoint hit on a worker isn't shown.
2. Commands sent through a new worker, before its runtime has started, end the session.
3. A worker's C# frames have no source.
4. Readying a worker's context clears every breakpoint, the page's included.
5. A thread that never returns to JavaScript can't be stopped on.

The first two end the session, which is what this repro shows. With the workaround, the repro debugs normally. Each
problem's cause is under Other information.

Reproduction Steps

Four files in one folder.

ThreadsRepro.csproj:

<Project Sdk="Microsoft.NET.Sdk.WebAssembly">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <Nullable>enable</Nullable>
    <WasmEnableThreads>true</WasmEnableThreads>
  </PropertyGroup>
</Project>

Program.cs:

using System;
using System.Threading.Tasks;

// Starts no threads of its own. Main calls Tick once a second.
for (int ticks = 1; ; ticks++)
{
    Console.WriteLine($"main, tick {ticks}: {Tick(10)}");
    await Task.Delay(1000);
}

static int Tick(int count)
{
    int total = 0;
    for (int i = 0; i < count; i++)
    {
        total += i;
    }
    return total;
}

wwwroot/index.html:

<!doctype html>
<html>
<head>
    <meta charset="utf-8">
    <title>threads repro</title>
</head>
<body>
    <p>The app's output is in the browser's console.</p>
    <script type="module">
        import { dotnet } from './_framework/dotnet.js';
        await dotnet.run();
    </script>
</body>
</html>

Properties/launchSettings.json:

{
    "profiles": {
        "ThreadsRepro": {
            "commandName": "Project",
            "launchBrowser": false,
            "applicationUrl": "http://127.0.0.1:5000"
        }
    }
}

1. Install the .NET 10 SDK, its wasm-tools workload, and VS Code's C# extension.

2. Open the folder in VS Code, and add this launch configuration (.vscode/launch.json):

   {
       "type": "blazorwasm",
       "request": "launch",
       "name": "repro",
       "cwd": "${workspaceFolder}",
       "url": "http://127.0.0.1:5000/",
       "browser": "chrome"
   }

3. Set a breakpoint on line 13 of Program.cs (int total = 0;).

4. Start debugging with repro.

Expected behavior

The breakpoint is hit once a second.

Actual behavior

Chrome opens, then closes, and the debugging session ends. The breakpoint isn't hit.

With <WasmEnableThreads>false</WasmEnableThreads>, and nothing else changed, the breakpoint is hit.

Regression?

No

Known Workarounds

The attached dotnet-debug-proxy-workaround.zip is a small ASP.NET Core app that hosts the SDK's own
BrowserDebugProxy.dll, patched by reflection, with a fix for each of the five problems in the description. Its
README.md and the header of its Program.cs describe each fix. It's released into the public domain (the Unlicense,
LICENSE), to use, modify and share as you wish.

To use it with the repro:

1. Run the app with dotnet run in the repro's folder.

2. Run the workaround with dotnet run in its folder. It listens at http://127.0.0.1:8791.

3. Debug with this configuration in place of repro:

   {
       "type": "chrome",
       "request": "launch",
       "name": "workaround",
       "url": "http://127.0.0.1:5000/",
       "inspectUri": "ws://127.0.0.1:8791/?browser={browserInspectUri}",
       "webRoot": "${workspaceFolder}",
       "timeout": 60000
   }

The breakpoint is then hit.

dotnet-debug-proxy-workaround.zip

Configuration

Other information

With threads on, .NET runs on Web Workers, even when the app starts no threads: its worker pool, and its own threads.
We found these five problems debugging a larger multithreaded app, by reading the proxy's source and its log.

Two of them end the session, and both happen as soon as a threaded app starts, as each new worker attaches to the
debugger. The debugger resumes the new worker, and the proxy throws in ClearState (1). The debugger sends the new
worker its settings and breakpoints, which the proxy sends on through a worker whose runtime hasn't started yet, and
they fail (2). Either failure ends the session. The other three don't end it, but hide stops, frames or breakpoints on
workers, once a session runs.

1. A breakpoint hit on a worker isn't shown, and resuming a worker ends the session. The proxy makes an
   ExecutionContext for each worker without its page's debugger data (SdbAgent, and the loaded symbols). It copies
   them in only when a pause has an asyncStackTraceId, which Chrome sends only when the worker's code was called from
   another target. Without them, SendCallStack throws when a breakpoint is hit on the worker, and the proxy resumes
   the worker without showing the stop. ClearState throws when the debugger resumes a worker, which ends the
   debugging session.
2. Commands sent through a new worker end the session. Once a worker's context is ready, the proxy sends its
   commands (setPauseOnExceptions, breakpoints) through that worker. They fail while a new worker is paused before
   its runtime has started, and the failure ends the session.
3. A worker's C# frames have no source. The proxy announces the C# sources (Debugger.scriptParsed) only on the
   page's session. The debugger looks for a frame's source among its own thread's scripts, so it can't show the
   worker's C# frames.
4. Readying a worker's context clears every breakpoint. For a context that isn't ready (RuntimeReady, as for
   getPossibleBreakpoints, which the debugger sends after each pause), the proxy first clears every breakpoint. The
   runtime's debugger agent serves every thread, so this clears the page's breakpoints too.
5. A thread that never returns to JavaScript can't be stopped on. The proxy reads a worker's debugger commands
   through getDotnetRuntime(0). .NET's script registers the runtime on a worker only as the last step of its start
   (preInitWorker), after awaits. A thread started as its worker finishes loading runs first. If it then never
   returns to JavaScript, as a thread running a blocking loop doesn't, those awaits never finish. Every breakpoint hit
   on it then throws in the proxy (Cannot read properties of undefined (reading 'INTERNAL')), and the proxy drops it.