Blazor WebAssembly browser debugging fails with UriFormatException using recent Chrome versions

[stefanomontani]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When attempting to debug a Blazor WebAssembly standalone app in a recent version of a Chromium browser (Chrome or Edge), an unhandled exception is thrown: System.UriFormatException: Invalid URI: Invalid port specified.

This occurs immediately when switching to the "debug in browser" mode, even with the default Blazor WebAssembly template, on a completely clean system.

Update

After further testing, the issue appears to be related to recent versions of Chromium-based browsers.

Debugging works correctly using older versions of Chrome (e.g., version 128 or earlier), but fails with the latest stable version. This suggests the issue may stem from changes in the DevTools protocol or URI handling behavior introduced in Chromium.

This regression prevents proper debugging of Blazor WebAssembly apps in all .NET SDK versions tested (6, 8, and 9).

Expected Behavior

Debugging should start normally without throwing a UriFormatException.

Steps To Reproduce

1. Create a clean VM with Windows Server 2022
2. Install the latest .NET SDK 9 (reproducible with earlier 8.x versions too)
3. Run:

dotnet new blazorwasm -o BlazorWebAssemblyApp
cd BlazorWebAssemblyApp
dotnet run

4. Start the browser in debug mode: msedge --remote-debugging-port=9222
5. Open the app in the browser and attempt to start debugging with SHIFT+ALT+D

The same behavior occurs across different machines and environments.

Exceptions (if any)

Exception: System.UriFormatException

Stack Trace:
fail: Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware[1]
An unhandled exception has occurred while executing the request.
System.UriFormatException: Invalid URI: Invalid port specified.
at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind, UriCreationOptions& creationOptions)
at System.Uri..ctor(String uriString)
at Microsoft.AspNetCore.Components.WebAssembly.Server.TargetPickerUi.GetDevToolsUrlWithProxy(HttpRequest request, BrowserTab tabToDebug)
at Microsoft.AspNetCore.Components.WebAssembly.Server.TargetPickerUi.Display(HttpContext context)
at Microsoft.AspNetCore.Builder.WebAssemblyNetDebugProxyAppBuilderExtensions.<>c.<b__0_1>d.MoveNext()
--- End of stack trace from previous location ---
at Microsoft.AspNetCore.Builder.Extensions.MapMiddleware.InvokeCore(HttpContext context, PathString matchedPath, PathString remainingPath)
at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

.NET Version

9.x.x, 8.x.x., 6.x.x

Anything else?

Additional Diagnostics

The output from http://localhost:9222/json is valid (contains a valid webSocketDebuggerUrl)

The UriFormatException seems to occur in the debugger infrastructure when trying to parse the WebSocket URL or during the connection phase.

Environment

OS: Windows Server 2022 (clean install, fully updated)

.NET SDK: 9.x.x (also tried 8.x.x and 6.x.x)

Browsers: Chrome 135.0.7049.96, Edge 135.0.3179.73

Project type: Blazor WebAssembly standalone

Notes

This issue seems to be systemic and not project-specific. It is reproducible even with a minimal blazorwasm template. It may be related to a regression in the .NET SDK or debug proxy tools.

Please advise if there's a patch, fix, or workaround to restore normal debugging support.

[bengavin]

We're seeing this behavior as well, at first thought it was related to recently added authentication, but even with authentication disabled, the problem still occurs.

[MichaelVach]

Same for me. Does anyone have a link to older versions of chrome?

[Dona278]

Same for us! This is a huge problems for developers who can't debug in other ways..

[ekotovqa]

During debugging of the Microsoft.AspNetCore.Components.WebAssembly.Server library,
the TargetPickerUi.GetDevToolsUrlWithProxy() method was able to understand what was happening.
The exception is thrown due to an erroneous value of tabToDebug.DevtoolsFrontendUrl.

I set a breakpoint on line 370 and intercept the necessary values ​​and, using a small script, generate the necessary working link.
I really hope for a speedy restoration of functionality.

[Dona278]

I've prepared a fix for the debug middleware and I can create a PR if possible but I think that I need to have the "ok" from aspnet team for that..

[javiercn]

It's strange that this didn't get labeled as untriaged by the bot.

@thaystg do you know what's going on here?

@lewing this is patch worthy if debugging is broken an we need to fix something.

@Dona278 thanks for volunteering to create a PR with a fix. I'm not super familiar with what the change is to fix this, so it will greatly help us if you can clarify a couple of questions:

• Impact: From what I understand this affects all recent versions of chrome/edge, does it reproduce with a brand-new project template? or are there any changes in the project required to cause this to happen?
• Fix: What is the exact code change that needs to be made? If its localized and you can post a snippet it will be great, if otherwise you are happy putting a tentative PR just to show what changes are needed, that would also work too.

If this affects older/released versions we will likely need to backport the fix.

[thaystg]

Looking at the description it looks like the format of the http://localhost:9222/json was changed. I can investigate it.
Or we can accept the PR from @Dona278 and review the PR.
Please let me know what do you prefer.

[Dona278]

Thanks @javiercn!
As @stefanomontani said, this can be reproduced event with a new project: simply create a Blazor wasm project, start and then try to debug from chrome / edge with the "shift + alt + d" shortcut. This will result in a new opened page which return the exception described.
I think that this issue affects all dotnet versions because of chromium changes (which I can't find) which change the result of the active tabs for the endpoint "http://localhost:9222/json" called in TargetPickerUi.cs:L270.

The "new" result:

[
  {
    "description": "",
    "devtoolsFrontendUrl": "https://chrome-devtools-frontend.appspot.com/serve_rev/@031848bc6ad02b97854f3d6154d3aefd0434756a/inspector.html?ws=localhost:9222/devtools/page/719FE9D3B43570193235446E0AB36859",
    "id": "719FE9D3B43570193235446E0AB36859",
    "title": "localhost:9222/json",
    "type": "page",
    "url": "http://localhost:9222/json",
    "webSocketDebuggerUrl": "ws://localhost:9222/devtools/page/719FE9D3B43570193235446E0AB36859"
  }
]

The property devtoolsFrontendUrl, which is used to create the Uri which throws the exception, contains an absolute path now but it's used as "relative path" in TargetPickerUi.cs:369.

Proposal: If that url was normalized by "removing domain" and then "ensure that start with devtools/", then will result in the correct url.

[thaystg]

@Dona278 go ahead and open the PR if you want!

[Dona278]

@thaystg sorry but I totally missed your comment!
PR created, thank you.

[Enbidi77]

Same problem! Here is what I have gotten:

[Dona278]

Same problem! Here is what I have gotten:

Already fixed here

[Enbidi77]

Same problem! Here is what I have gotten:

Already fixed here

Appreciate your work!