[Problem/Bug]: Remote debugging endpoint refuses connections in non-elevated hosts on 153.0.4234.32 (regression from 152; related to #5640)

What happened?

After the Evergreen WebView2 Runtime auto-updated to 153.0.4234.32, debugging a
Blazor WebAssembly Office add-in hosted in Microsoft Word from Visual Studio fails.
The debugger cannot connect to WebView2's DevTools endpoint.

This looks like the same failure mode as #5640 (DevTools endpoint unreachable, same
BrowserExecutableFolder workaround), but it is not that bug as described:

• The host process is not elevated. Visual Studio and Word both run at medium integrity.
• It started with 153, not 150. Runtime 152.0.4191.62 works on the same machine.

So it appears 153 extends the #5640 behaviour to non-elevated hosts.

Evidence

• Ports are assigned dynamically and change on every launch, but within any single
  launch the port the debug proxy is refused on is exactly the port the runtime
  advertised in DevToolsActivePort
  (%TEMP%\vscode-js-debug-userdatadir_0\EBWebView\DevToolsActivePort). Example from
  one run, where both show 63925:

  DevToolsProxy.Run: System.Net.WebSockets.WebSocketException (0x80004005): Unable to connect to the remote server
   ---> System.Net.Sockets.SocketException (10061): No connection could be made because the target machine actively refused it. (127.0.0.1:63925)
     at Microsoft.WebAssembly.Diagnostics.DevToolsProxy.RunForDevTools(...)
  

  So the runtime starts with remote debugging enabled and writes its port, but doesn't
  accept connections on it.

• Visual Studio reports (port from a separate run):
  Failed to launch debug adapter. Unable to launch browser: "Could not open wss://localhost:44312/_framework/debug/ws-proxy?browser=ws://127.0.0.1:<port>/devtools/browser/<guid>",
  then terminates Word after about a minute.

• Chrome 153 and Edge 153 (the browser) both debug the same Blazor WebAssembly app
  fine. Only the WebView2-hosted case is broken.

• Pinning Office to Fixed Version 152.0.4191.62 via BrowserExecutableFolder fixes
  it immediately, with nothing else changed.

Importance

Blocks debugging entirely. The only workaround is pinning Word, Excel and PowerPoint
together to an older Fixed Version runtime, which also removes them from WebView2
security updates.

This only affects development.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

153.0.4234.32 (broken). 152.0.4191.62 Fixed Version x64 (works).

SDK Version

N/A. The host is Microsoft Word (Office 16.0.20326.20144, Click-to-Run), not our own WebView2 app.

Framework

Office Add-in (Blazor WebAssembly), debugged from Visual Studio Professional 2026 18.9.0

Operating System

Windows 11 Pro, build 26200

Repro steps

1. Evergreen WebView2 Runtime at 153.0.4234.32. Visual Studio not elevated.
2. Launch a Blazor WebAssembly Office add-in into Word from Visual Studio, with
   inspectUri set to {wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}.
3. Observe the debug adapter failure and the refused connection to the port in
   DevToolsActivePort.
4. Set HKLM\SOFTWARE\Policies\Microsoft\Edge\WebView2\BrowserExecutableFolder
   for WINWORD.EXE, EXCEL.EXE and POWERPNT.EXE to the Fixed Version 152.0.4191.62
   runtime. Repeat: debugging works.

Repros in Edge Browser

No, issue does not reproduce in the corresponding Edge version

Regression

Regression in newer Runtime. Last working: 152.0.4191.62. First broken: 153.0.4234.32
(auto-installed 2026-09-15).

Last working version (if regression)

152.0.4191.62