Aspnetcore: Unbound breakpoint in VS Code when debugging Blazor WASM app on WSL 2

[michaelbpalmer]

Describe the bug

I cannot set a breakpoint when debugging a WASM app on VS Code (WSL 2) following the instructions here: https://docs.microsoft.com/en-us/aspnet/core/blazor/debug?view=aspnetcore-3.1

To Reproduce

1. Create a new WASM project: dotnet new blazorwasm -o Foo
2. Follow VS Code debugging instructions here: https://docs.microsoft.com/en-us/aspnet/core/blazor/debug?view=aspnetcore-3.1
3. Set a breakpoint in the IncrementCount method in the Counter component (Counter.razor).

Expected: Breakpoint resolves
Actual: Unbound breakpoint

Debug Console output from .NET Core Debug Blazor Web Assembly In Chrome:

Note: Using the "preview" debug extension
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
null: Uncaught DOMException: Entry already exists.
blazor Loaded 4.59 MB resources
This application was built with linking (tree shaking) disabled. Published applications will be significantly smaller.
mono_wasm_runtime_ready fe00e07a-5519-4dfe-b35a-f867dbaf2e28
null: Uncaught DOMException: Entry already exists.

If I expand one of the Uncaught exceptions above, I see following:

u @ localhost꞉5001/_framework/blazor.webassembly.js:1:45332
◀ Promise.then ▶
s @ localhost꞉5001/_framework/blazor.webassembly.js:1:45401
a @ localhost꞉5001/_framework/blazor.webassembly.js:1:45263
◀ Promise.then ▶
s @ localhost꞉5001/_framework/blazor.webassembly.js:1:45401
@ localhost꞉5001/_framework/blazor.webassembly.js:1:45411
r @ localhost꞉5001/_framework/blazor.webassembly.js:1:45211
e.addToCacheAsync @ localhost꞉5001/_framework/blazor.webassembly.js:1:49122
@ localhost꞉5001/_framework/blazor.webassembly.js:1:49032
@ localhost꞉5001/_framework/blazor.webassembly.js:1:46416
@ localhost꞉5001/_framework/blazor.webassembly.js:1:46521
a @ localhost꞉5001/_framework/blazor.webassembly.js:1:45267
◀ Promise.then ▶
s @ localhost꞉5001/_framework/blazor.webassembly.js:1:45401
a @ localhost꞉5001/_framework/blazor.webassembly.js:1:45263
◀ Promise.then ▶
s @ localhost꞉5001/_framework/blazor.webassembly.js:1:45401
@ localhost꞉5001/_framework/blazor.webassembly.js:1:45411
r @ localhost꞉5001/_framework/blazor.webassembly.js:1:45211
e.loadResourceWithCaching @ localhost꞉5001/_framework/blazor.webassembly.js:1:48588
e.loadResource @ localhost꞉5001/_framework/blazor.webassembly.js:1:47125
@ localhost꞉5001/_framework/blazor.webassembly.js:1:36314
@ localhost꞉5001/_framework/blazor.webassembly.js:1:35494
@ localhost꞉5001/_framework/blazor.webassembly.js:1:35599
@ localhost꞉5001/_framework/blazor.webassembly.js:1:34512
r @ localhost꞉5001/_framework/blazor.webassembly.js:1:34289
p.instantiateWasm @ localhost꞉5001/_framework/blazor.webassembly.js:1:36194
createWasm @ localhost꞉5001/_framework/wasm/dotnet.3.2.0-preview3.20168.1.js:1:18234
@ localhost꞉5001/_framework/wasm/dotnet.3.2.0-preview3.20168.1.js:1:184118

Further technical details

• ASP.NET Core version
• Include the output of dotnet --info
• The IDE (VS / VS Code/ VS4Mac) you're running on, and it's version

Environment:

• VS Code: 1.43.2
• C# Extension: 1.21.16
• JavaScript Debugger (Nightly): 2020.4.317
• JavaScript Debugger Companion: 0.0.4
• Chrome: 78.0.3904.130
• WSL 2.0 on Windows 10: 19592.1001

dotnet --info:

.NET Core SDK (reflecting any global.json):
Version: 3.1.201
Commit: b1768b4ae7

Runtime Environment:
OS Name: ubuntu
OS Version: 18.04
OS Platform: Linux
RID: ubuntu.18.04-x64
Base Path: /usr/share/dotnet/sdk/3.1.201/

Host (useful for support):
Version: 3.1.3
Commit: 4a9f85e9f8

.NET Core SDKs installed:
2.2.402 [/usr/share/dotnet/sdk]
3.1.201 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.2.7 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.2.7 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.3 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.2.7 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.3 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

[vindicatorr]

I'm in a similar boat with not being able to set a WASM breakpoint.
Watching the chrome devtools network, I see the files loading, and the site functions fine.

I also made sure my launcher contained:

"runtimeExecutable": "/usr/bin/google-chrome-stable",
            "runtimeArgs": [
                "--new-window",
                "--user-data-dir=${workspaceFolder}/userdata",
                "--remote-debugging-port=9222",
                "--incognito"
            ]

And I can go to http://localhost:9222/, which shows the remote page I'm on, as well as seeing http://localhost:9222/json contain:

[ {
   "description": "",
   "devtoolsFrontendUrl": "/devtools/inspector.html?ws=localhost:9222/devtools/page/9BD82C84E1AEF830CBDE97B06E88FD6F",
   "faviconUrl": "https://localhost:5001/favicon.ico",
   "id": "9BD82C84E1AEF830CBDE97B06E88FD6F",
   "title": "<projectName>",
   "type": "page",
   "url": "https://localhost:5001/counter",
   "webSocketDebuggerUrl": "ws://localhost:9222/devtools/page/9BD82C84E1AEF830CBDE97B06E88FD6F"
} ]

[eoneoff]

I've got a similar problem. The same project with exactly the same launch.json and launcSettings.json is loading breakpoints on Windows and does not on Linux.
The problem, according to my observation, arises during the launch of second debug process (".NET Core Debug Blazor Web Assembly in Chrome"). In this process debug console on Windows after the mono_wasm_get_loaded_files message the messages about loaded breakpoints appear and after that they turn from unbound to active. On Linux that is the last message in the console and nothing appears after it.

[InsaneWookie]

I ran into the same issue I think when setting up a brand new install. Looks like possibly some https issue. I was able to get debugging working in VS Code on Ubuntu using http instead of https.

In launch.json under the ".NET Core Debug Blazor Web Assembly in Chrome" launch configuration, change url to "http://localhost:5000"

Full launch config
```
{
"name": ".NET Core Debug Blazor Web Assembly in Chrome",
"type": "pwa-chrome",
"request": "launch",
"timeout": 30000,
// If you have changed the default port / launch URL make sure to update the expectation below
"url": "http://localhost:5000",
"webRoot": "${workspaceFolder}",
"inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}"
}

[captainsafia]

Thanks for reporting this issue. I'm trying to repro but am running into some unrelated problems.

To help with debugging, can you add "trace": true to the launch.json file like so:

         {
             "name": ".NET Core Debug Blazor Web Assembly in Chrome",
             // Standard config here
             "trace": true
         }

This should log to a JSON file that you can then attach to this issue.

[michaelbpalmer]

Thanks, @captainsafia! Attached. Please let me know if you need any additional info.
vscode-debugadapter-4.zip

[captainsafia]

Thanks, @michaelbpalmer! Some questions:

• Does using the HTTP-based URL as described above work for you?
• Can you try starting VS Code inside WSL from a folder located on the Windows filesystem (e.g. /mnt/c/Users/me/mycode/)?
• Can you try adding the following to the launch config?

"sourceMapPathOverrides": {
   "/mnt/c/*": "C:\\*"
}

[msftbot[bot]]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.

See our Issue Management Policies for more information.

[dselvan]

@captainsafia having the same issue as op/others have mentioned. tried the three mentioned items with no luck.

Thanks, @michaelbpalmer! Some questions:

• Does using the HTTP-based URL as described above work for you?
• Can you try starting VS Code inside WSL from a folder located on the Windows filesystem (e.g. /mnt/c/Users/me/mycode/)?
• Can you try adding the following to the launch config?

"sourceMapPathOverrides": {
   "/mnt/c/*": "C:\\*"
}

just commenting to make sure the issue doesn't get closed as I would really like to see this get resolved.

[atabibi]

I ran into the same issue I think when setting up a brand new install. Looks like possibly some https issue. I was able to get debugging working in VS Code on Ubuntu using http instead of https.

In launch.json under the ".NET Core Debug Blazor Web Assembly in Chrome" launch configuration, change url to "http://localhost:5000"

Full launch config

{
    "name": ".NET Core Debug Blazor Web Assembly in Chrome",
    "type": "pwa-chrome",
    "request": "launch",
    "timeout": 30000,
    // If you have changed the default port / launch URL make sure to update the expectation below
    "url": "http://localhost:5000",
    "webRoot": "${workspaceFolder}",
    "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}"
}

This method worked for me:

.NET Core SDK (reflecting any global.json):
Version: 3.1.202
Commit: 6ea70c8dca

Runtime Environment:
OS Name: linuxmint
OS Version: 19.3
OS Platform: Linux
RID: linux-x64
Base Path: /usr/share/dotnet/sdk/3.1.202/

Host (useful for support):
Version: 3.1.4
Commit: 0090613580

.NET Core SDKs installed:
3.1.202 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.App 3.0.3 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.4 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.0.3 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.4 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Microsoft.AspNetCore.Components.WebAssembly Version="3.2.0-rc1.20223.4"

[captainsafia]

I've got a lead on what causes the total failure option that can't be fixed by any of the approaches I outlined here.

I was able to reproduce the problem and it appears that in VS Code running under WSL the debug proxy is never launched. You can verify this by running:

ps aux | grep "devserver"

to get the process running the Blazor dev server, copying its PID, then running:

ps aux | grep $PID

to get child processes. In the case of this bug, there is no child process running DebugProxy.dll.

The debug proxy is launched as a child process of the Blazor dev server and is used to proxy debugging messages between the browser window and client. The fact that it doesn't launch explains why any attempt to execute a breakpoint operation, like set a breakpoint, no-op.

Now, it appears that the debug proxy is launching successfully in some scenarios. In particular, the ones where connecting to the non-HTTPS instance works well. So there might be some other conditions that cause it to launch in some WSL instances but not others.

[tredition]

I ran into the same issue I think when setting up a brand new install. Looks like possibly some https issue. I was able to get debugging working in VS Code on Ubuntu using http instead of https.
In launch.json under the ".NET Core Debug Blazor Web Assembly in Chrome" launch configuration, change url to "http://localhost:5000"
Full launch config

{
    "name": ".NET Core Debug Blazor Web Assembly in Chrome",
    "type": "pwa-chrome",
    "request": "launch",
    "timeout": 30000,
    // If you have changed the default port / launch URL make sure to update the expectation below
    "url": "http://localhost:5000",
    "webRoot": "${workspaceFolder}",
    "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}"
}

This method worked for me:

.NET Core SDK (reflecting any global.json):
Version: 3.1.202
Commit: 6ea70c8dca

Runtime Environment:
OS Name: linuxmint
OS Version: 19.3
OS Platform: Linux
RID: linux-x64
Base Path: /usr/share/dotnet/sdk/3.1.202/

Host (useful for support):
Version: 3.1.4
Commit: 0090613580

.NET Core SDKs installed:
3.1.202 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.App 3.0.3 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.4 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.0.3 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.4 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Microsoft.AspNetCore.Components.WebAssembly Version="3.2.0-rc1.20223.4"

This solution also worked for me! Thanks!

[captainsafia]

I'll close this issue as a dupe of #21466 as the issue with the DebugProxy not being launched is a result of issues with making inbound requests to the WSL.

It's likely that the issues that are resolved by accepting local dev certs happen in WSL instances that are already configuring to support arbitrary inbound connections.

If folks still have issues with this that aren't related to the above, please open another issue. It makes it easier to debug and peel out different issues.