[WASM][Debug][Windows 11] App no longer can be debugged

[DierkDroth]

I migrated my WASM solution from VisualStudio 2022 on Windows 10 to a new laptop with VisualStudio 2022 on Windows 11 and found that I no longer could start the app in DEBUG but saw tons of errors (below) in VS output window.

This made me tinker with launchSettings.json and compare it with the version of the sample solution which I was using here and which - to my big surprise - still did start on Windows 11 (however, I saw tons of errors in browser console but that's a different story likely related to the wrong default settings in 'launchSettings.json/iisSettings')

I finally found that adding

"inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}",

... as advised here was the problem (interestingly these lines weren't added by default by the generated working solution above, again another issue which should be looked into). Would I remove/add those lines to any solution I tested then the WASM head would work/not work.

Removing those lines got the WASM app started, but now I no longer could e.g. set breakpoints -> bad.

@jeromelaban any idea what needed to be done to get me going with proper WASM debugging on Windows 11?

System.InvalidOperationException: No output has been recevied from the application.
   at Uno.Wasm.Bootstrap.Cli.DebugProxyLauncher.LaunchAndGetUrl(IServiceProvider serviceProvider, IConfiguration configuration, String devToolsHost, Uri browserUrl) in D:\a\1\s\src\Uno.Wasm.Bootstrap.Cli\DebuggingProxy\DebugProxyLauncher.cs:line 126
   at Uno.Wasm.Bootstrap.Cli.DebugProxyLauncher.EnsureLaunchedAndGetUrl(IServiceProvider serviceProvider, IConfiguration configuration, String devToolsHost, Uri browserUrl) in D:\a\1\s\src\Uno.Wasm.Bootstrap.Cli\DebuggingProxy\DebugProxyLauncher.cs:line 60
   at Uno.Wasm.Bootstrap.Cli.DebuggingProxy.DebuggerHostExtensions.<>c__DisplayClass0_0.<<UseWebAssemblyDebugging>b__1>d.MoveNext() in D:\a\1\s\src\Uno.Wasm.Bootstrap.Cli\DebuggingProxy\DebugHostExtensions.cs:line 66
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Builder.Extensions.MapMiddleware.InvokeCore(HttpContext context, String matchedPath, String remainingPath)
   at Uno.Wasm.Bootstrap.Cli.Server.Startup.<>c.<<Configure>b__3_0>d.MoveNext() in D:\a\1\s\src\Uno.Wasm.Bootstrap.Cli\Server\Startup.cs:line 66
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)
Microsoft.AspNetCore.Hosting.Diagnostics: Information: Request finished HTTP/1.1 GET https://localhost/_framework/debug/ws-proxy?browser=ws%3A%2F%2F127.0.0.1%3A56450%2Fdevtools%2Fbrowser%2F15b7b7cb-1815-4415-8bde-22aa58db960f - - - 500 - text/plain;+charset=utf-8 12.4544ms
Microsoft.AspNetCore.Hosting.Diagnostics: Information: Request starting HTTP/1.1 GET https://localhost/_framework/debug/ws-proxy?browser=ws%3A%2F%2F127.0.0.1%3A56450%2Fdevtools%2Fbrowser%2F15b7b7cb-1815-4415-8bde-22aa58db960f - -
The program '' has exited with code 4294967295 (0xffffffff).
Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware: Error: An unhandled exception has occurred while executing the request.

[jeromelaban]

Windows 11 is supported properly. This error message is likely related to some environment issue that prevents the debugger proxy from starting properly. This process is built from the .NET SDK and is likely to fail for non-Uno projects as well.

You can try starting the the debugger proxy manually from a path that looks like this one:

dotnet "%temp%\dotnet-runtime-wasm-windows-XXXXXXXXX-Release\dbg-proxy\net6.0\BrowserDebugHost.dll"

and see if there are unusual error messages showing up.

Could you also indicate which version of VS 2022 is installed on your machine ?

[DierkDroth]

Thanks for follow up @jeromelaban

This is VS 2022 17.0.5

There are 2 such directories with identical names on both old and new laptop (screenshot below is from new laptop = not working). There is a diffence between old and new latop: on old laptop 'Content root path = C:\WINDOWS\system32' (not sure if that matters). Other than that output looks identical on old and new laptop, apart from port numbers which keep changing on every incarnation

[DierkDroth]

@jeromelaban I'm still stranded. What else could be done to get me going with UNO WASM again?

Also: not sure if this helps, but the very first exception I do see in my VS output window is this
Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware: Error: An unhandled exception has occurred while executing the request.

[jeromelaban]

There's nothing additional to do aside from investigating the issue. It could be an environment issue, a browser issue, a Visual Studio issue or a .NET issue, but without a repro, it's difficult to troubleshoot.

[DierkDroth]

@jeromelaban the repo which I provided here (also please see above) exhibits the exact same issue.

Also: the issue could be easily reproduced by any random UNo WASM project following directions here.

Note: you needed to add the offending lines as per above to launchSettings.json
"inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}",

[DierkDroth]

@jeromelaban correct, the repo linked above runs on .NET 5 - since this is what the UNo templates provide (I did not want to change that to not introduce variables to the case). However, my custom project runs on .NET 6 - and exhibits the same faulty behavior.

• I removed globals.json from the repo above -> problem persists
• I don't have a globals.json file on my custom project

[jeromelaban]

Thanks. Then other than a preview version, there's nothing else we can do at this point without reproducing.

[DierkDroth]

• What would I buy into if I installed a VS preview version? What other pieces of UNO would then fall apart?
• I don't even know how to install a VS preview. How would I do that? Is there a roll back if things go south?
• What happens on the final VS release? Could I just install it on top or would I have to go through a full uninstall/re-install cycle?

Also:

• what is it that UNO is trying to connect to as it fails? What could be done to understand why the 'thing which it's talking to' would not behave as expected?
• could the failing part be simulated in some shape or form in an attempt to analyze what's going wrong?
• is the difference in 'Content root path' between old and new machine (which I outlined above) of any relevance? If so, how could I 'make that equal'?

[DierkDroth]

When trying to understand the UNO sources I see this in DebugProxyLauncher.cs:

	var processStartInfo = new ProcessStartInfo
	{
		FileName = muxerPath,
		Arguments = $"exec \"{executablePath}\" --OwnerPid {ownerPid} --DevToolsUrl {devToolsHost}",
		UseShellExecute = false,
		RedirectStandardOutput = true,
	};

How about amending sources to trace out or log the relevant variables so I could try to reproduce the case in my custom code in order to understand why the ASP.NET process eithes does not start or does not send any data?

Another idea: I don't know it it even would be possible that I debugged this part of the UNO WASM bootstrapper directly?!?

[jeromelaban]

The parts that need to be debugged for this specific issue are directly from the .NET runtime and not the uno bootstrapper. Those communicate directly with Visual Studio which we cannot debug at all as they are private.

Here's the visual studio preview link: https://visualstudio.microsoft.com/vs/preview. You can use it side by side with stable builds of VS. A new release of VS 2022 should be released soon, so you cam wait for an update there.

Also, if you don't do anything specific to WebAssembly, debugging using the windows or GTK/WPF targets of your app is far more useful in all cases as the debugger has a lot more features.

[DierkDroth]

Thanks @jeromelaban

The parts that need to be debugged for this specific issue are directly from the .NET runtime and not the uno bootstrapper. Those communicate directly with Visual Studio which we cannot debug at all as they are private.

Hmm ... isn't the code which I provided above from UNO - and isn't it trying to start an ASP.NET process which apparently triggers .OutputDataReceived but 'string.IsNullOrEmpty(eventArgs.Data)' and hence the exception is thrown in DebugProxyLauncher.cs 188?

Believe me, I'm only debugging WASM as it's absolutely unavoidable (since WASM debugging still is close to a nightmare). However there are many scenarios where I needed to understand why stuff is working in WinUI, but not in WASM...

[jeromelaban]

Yes, the code provided is from Uno, but the failing process which seems to be not responding and that process is the one that is coming from the .NET runtime. You can also try to debug a WebAssembly Blazor application and see if it works, as it uses the same debugger binaries.

[DierkDroth]

Yep, that's why I suggested tracing out the parameters so I could replicate the scenario by some custom code - or even debug the very code to inspect the actual parameter values.

[DierkDroth]

@jeromelaban I just tried the Blazor tutorial. That worked no problem.

Next I tried

dotnet new blazorwasm -o blazor-web

... and ran the project from VS 2022. That worked no problem as well.

There is a difference to the UNO setup though as there is an additional CMD window coming up (below).

Is there any other Blazor app or setup which I should try in order to isolate the problem?

[DierkDroth]

@jeromelaban I just tried turning off my Windows Firewall -> make no difference, issue persists

So everything we have at this point - since it's not a firewall issue and blazor works no problem - is that UNO is trying to start the MS part in a way that would not work on my new laptop.

I see no other way than inspecting/debugging the UNO code/logic to understand why it's failing. Since you can't reproduce either you had to add tracing/logging info to the UNO pieces (where I then could try to replicate the failing scenario in some custom code, to better understand why things fall aprt) or we had to debug the case on my machine...

[DierkDroth]

@jeromelaban what would be next steps in order to restore the debugging feature?

How about amending UNO sources to trace out or log the relevant variables on call below so I could try to reproduce the case in my custom code in order to understand why the ASP.NET process eithes does not start or does not send any data?

	{
		FileName = muxerPath,
		Arguments = $"exec \"{executablePath}\" --OwnerPid {ownerPid} --DevToolsUrl {devToolsHost}",
		UseShellExecute = false,
		RedirectStandardOutput = true,
	};

[DierkDroth]

I just came across something which we should look into.

When trying to download and unzip the Uno.Wasm.Bootstrap sources from GitHub I got error below. I could have sworn I have enabled long path support before. Nevertheless I did it again as per here by

reg ADD HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem /v LongPathsEnabled /t REG_DWORD /d 1

... and rebooted.

But I'm still getting error below when trying to unzip the Uno.Wasm.Bootstrap sources?!?

Is there a problem with long path support on Windows 11?!?

[DierkDroth]

@jeromelaban I just ran
uno-check

...and

uno-check --target wasm

... and do see this (below). What does that mean and what should I be looking into?

When running

uno-check --verbose --target wasm

... I do see those strange issues

[DierkDroth]

@jeromelaban (I purposely started a new thread)

• I just installed latest VS 2022 17.1.0 -> issue persists on my custom project and repo project above
• to double check I'm not missing out on something I installed the latest UNO DEV pieces -> issue persists on my custom project and repo project above

Next I ran more tests - unfortunately with very inconsistent results:

• I created a new test solution A as per here and definitely was able to set a breakpoint in App.xaml.cs and got it working once
• Then I was working on my already existing repo project from above to reproduce the success ... but failed, came back to the solution A without changing anything and the breakpoint no longer worked
• Scratching my head I again created a new solution C as per here did not touch anything and breakpoints weren't working again
• On solution C I see tons of these errors in the browser console (below)

What needed to be done to get UNO WASM debuging working?

[DierkDroth]

@jeromelaban sure. Please see below

about the external process not providing output

Understand. But is the UNO code listening only to STDOUT or to STDERR as well?

[jeromelaban]

Thanks for the update. Can you try installing .NET 5 as well and see if this helps?

[jeromelaban]

As for stderr, indeed it's not. This particular piece is a clone of the .NET original which is not listening to stderr as well, but it's worth adding it.

[DierkDroth]

@jeromelaban oh my goodness. That was it! Problem solved.

Thanks for your support

[jeromelaban]

Thanks! We'll be pushing a bootstrapper update to avoid requiring the .NET 5 installation, as well as the stderr logging for future troubleshooting.