Blazor apps with .NET 10 and Docker deployment do not trigger events

[gavdgavd]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

We are migrating all our Blazor applications from .NET 8 to .NET 10:

• Applications are deployed on a Windows Server running WSL, using Docker containers.
• For .NET 8, we rely on the Docker image mcr.microsoft.com/dotnet/aspnet:8.0, and for .NET 10 we use mcr.microsoft.com/dotnet/aspnet:10.0.
• IIS 10 is configured as a reverse proxy (with ARR installed and set up) to expose all applications to the internet. Each app runs under a subdomain of our main domain, with valid certificates ensuring HTTPS connections.

Our Blazor apps have been running smoothly for months on .NET 8 without issues. The migration to .NET 10 began after the release of Visual Studio 2026 on November 12, 2025. On development machines, the updated applications run correctly, and they also work as expected when deployed to Docker and accessed via localhost.

However, when connected through IIS and subdomains, the applications load and display properly, but user interactions fail. For instance, buttons in the interface can be clicked, yet the associated events never trigger.

Expected Behavior

We expect the applications to behave identically under .NET 10 as they currently do with .NET 8. User interface interactions, such as button clicks, combo box selections, and similar events, should consistently trigger their corresponding event handlers.

Steps To Reproduce

To reproduce the issue, we created two baseline applications using Visual Studio 2026 and the Blazor Web App template:

• Test_BlazorDN8 configured to run on .NET 8
• Test_BlazorDN10 configured to run on .NET 10

Application Setup

• No functional changes were made, except for an additional <p> tag on the Home page to display the .NET version.
• Both applications were tested locally on development machines to confirm correct behavior.
• Each app was compiled in Release mode, and the published output was copied into the corresponding Docker volumes.
• A Docker container was created for each application using the following docker-compose.yml configuration (example shown for the .NET 8 app):

services:
  testblazorapp:
    image: mcr.microsoft.com/dotnet/aspnet:8.0
    container_name: con_TestBlazorDN8
    working_dir: /app   
    volumes:
      - /mnt/c/DockerFiles/ConfigAndDataFiles/Test_BlazorDN8/publish:/app
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
    ports:
      - "9028:8080"  # Port 9029 used for .NET 10
    command: ["dotnet", "/app/Test_BlazorApp_DotNet8.dll"]
    deploy:
      replicas: 1
      restart_policy:
        condition: unless-stopped

Localhost Testing

• Running both applications via http://localhost:9028 (for .NET 8) or http://localhost:9029 (for .NET 10) works without issues.
• All UI interactions, including button clicks, behave as expected.

IIS Reverse Proxy Configuration

• IIS was configured as a reverse proxy (ARR enabled) to expose the applications over HTTPS using a subdomain.
• Example ARR configuration for the .NET 8 app:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="ReverseProxyInboundRule_TestBlazorDN" enabled="true" stopProcessing="true">
                    <match url="(.*)" />
                    <action type="Rewrite" url="http://127.0.0.1:9028/{R:1}" />
                    <serverVariables>
                        <set name="HTTP_X_Forwarded_Host" value="{HTTP_HOST}" />
                        <set name="HTTP_X_Forwarded_Proto" value="https" />
                        <set name="HTTP_X_Forwarded_Port" value="443" />
                        <set name="HTTP_X_Forwarded_For" value="{REMOTE_ADDR}" />
                        <set name="HTTP_HOST" value="{HTTP_HOST}" />
                    </serverVariables>
                </rule>
            </rules>
        </rewrite>
        <httpErrors errorMode="Detailed" />
    </system.webServer>
</configuration>

Results

• When accessed via the configured subdomain (https://subdomain.domain.com) and routed to the .NET 8 app, everything works correctly.
• After updating the ARR configuration to point to the .NET 10 app (http://127.0.0.1:9029/{R:1}), the application loads and displays properly.
• However, user interactions fail: for example, the Counter button renders but does not trigger its event.

Exceptions (if any)

• In the .NET 10 version, the user interface displays the message: An unhandled error has occurred. Reload
• No errors are recorded in the Docker application logs.
• When inspecting with the browser’s Developer Tools, the Console tab shows four distinct errors.

blazor.web.j8lzlu28q6.js:1 [2025-11-14T10:43:00.816Z] Information: Normalizing '_blazor' to 'https://subdomain.domain.com/_blazor'.
blazor.web.j8lzlu28q6.js:1 [2025-11-14T10:43:01.192Z] Information: WebSocket connected to wss://subdomain.domain.com/_blazor?id=1hKPq-GMA-LbQpnCideIHg.
blazor.web.j8lzlu28q6.js:1  [2025-11-14T10:43:01.193Z] Error: Connection disconnected with error 'Error: WebSocket closed with status code: 1006 (no reason given).'.
	log @ blazor.web.j8lzlu28q6.js:1
	_stopConnection @ blazor.web.j8lzlu28q6.js:1
	(anonymous) @ blazor.web.j8lzlu28q6.js:1
	_close @ blazor.web.j8lzlu28q6.js:1
	(anonymous) @ blazor.web.j8lzlu28q6.js:1
blazor.web.j8lzlu28q6.js:1  [2025-11-14T10:43:01.194Z] Error: Error: WebSocket closed with status code: 1006 (no reason given).
	log @ blazor.web.j8lzlu28q6.js:1
	unhandledError @ blazor.web.j8lzlu28q6.js:1
	startConnection @ blazor.web.j8lzlu28q6.js:1
	await in startConnection
	startCore @ blazor.web.j8lzlu28q6.js:1
	start @ blazor.web.j8lzlu28q6.js:1
	rr @ blazor.web.j8lzlu28q6.js:1
	await in rr
	or @ blazor.web.j8lzlu28q6.js:1
	startCircutIfNotStarted @ blazor.web.j8lzlu28q6.js:1
	resolveRendererIdForDescriptor @ blazor.web.j8lzlu28q6.js:1
	determinePendingOperation @ blazor.web.j8lzlu28q6.js:1
	refreshRootComponents @ blazor.web.j8lzlu28q6.js:1
	(anonymous) @ blazor.web.j8lzlu28q6.js:1
blazor.web.j8lzlu28q6.js:1  [2025-11-14T10:43:01.195Z] Error: Failed to start the circuit.
	log @ blazor.web.j8lzlu28q6.js:1
	rr @ blazor.web.j8lzlu28q6.js:1
	await in rr
	or @ blazor.web.j8lzlu28q6.js:1
	startCircutIfNotStarted @ blazor.web.j8lzlu28q6.js:1
	resolveRendererIdForDescriptor @ blazor.web.j8lzlu28q6.js:1
	determinePendingOperation @ blazor.web.j8lzlu28q6.js:1
	refreshRootComponents @ blazor.web.j8lzlu28q6.js:1
	(anonymous) @ blazor.web.j8lzlu28q6.js:1
blazor.web.j8lzlu28q6.js:1  Uncaught (in promise) Error: Circuit host not initialized.
    at Ho.disconnect (blazor.web.j8lzlu28q6.js:1:141177)
    at Ho.unhandledError (blazor.web.j8lzlu28q6.js:1:146461)
    at Ho.startConnection (blazor.web.j8lzlu28q6.js:1:139950)
    at async Ho.startCore (blazor.web.j8lzlu28q6.js:1:137535)
    at async rr (blazor.web.j8lzlu28q6.js:1:164409)
	disconnect @ blazor.web.j8lzlu28q6.js:1
	unhandledError @ blazor.web.j8lzlu28q6.js:1
	startConnection @ blazor.web.j8lzlu28q6.js:1
	await in startConnection
	startCore @ blazor.web.j8lzlu28q6.js:1
	start @ blazor.web.j8lzlu28q6.js:1
	rr @ blazor.web.j8lzlu28q6.js:1
	await in rr
	or @ blazor.web.j8lzlu28q6.js:1
	startCircutIfNotStarted @ blazor.web.j8lzlu28q6.js:1
	resolveRendererIdForDescriptor @ blazor.web.j8lzlu28q6.js:1
	determinePendingOperation @ blazor.web.j8lzlu28q6.js:1
	refreshRootComponents @ blazor.web.j8lzlu28q6.js:1
(anonymous) @ blazor.web.j8lzlu28q6.js:1

• The message WebSocket closed is not observed when running the .NET 8 version.
• In the .NET 10 version, the errors Failed to start the circuit and Circuit host not initialized appear, suggesting a potential issue with SignalR. However, the exact cause remains unidentified.

.NET Version

Version 8 and 10

Anything else?

Summary

• Two Blazor applications were created with Visual Studio 2026: one targeting .NET 8, the other .NET 10.
• Both applications were deployed to Windows WSL Docker containers.
• IIS (ARR) was configured as a reverse proxy, using identical settings, to expose the apps through a subdomain.
• The .NET 8 application runs without any issues.
• The .NET 10 application loads correctly and displays its interface, but user interactions (e.g., button clicks, combo box selections) fail to trigger the associated events.
  Any help will be welcome.

[javiercn]

@gavdgavd thanks for contacting us.

Can you capture the server logs in Debug mode to see if there are issues showing up there?

[gavdgavd]

@gavdgavd thanks for contacting us.

Can you capture the server logs in Debug mode to see if there are issues showing up there?

Hi Javier,

Thank you for your quick response. Could you please provide me with instructions on how to obtain the server logs in debug mode? Are you referring to the logs on the host Windows Server (that is running WSL), or the Docker container logs where the application is running?

I’m not very experienced with this kind of setup, as my focus is more on development. Detailed, step‑by‑step guidance on how to gather the logs would be greatly appreciated.

Best regards, Gustavo

[javiercn]

@gavdgavd thanks for the additional details.

1. Increase ASP.NET Core log level (appsettings.json)

Add or extend logging configuration in your app’s appsettings.json (or appsettings.Production.json). Important categories: Microsoft.AspNetCore.SignalR and Microsoft.AspNetCore.Http.Connections. Example snippet:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information",
      "Microsoft.AspNetCore.SignalR": "Debug",
      "Microsoft.AspNetCore.Http.Connections": "Debug",
      "Microsoft.AspNetCore": "Debug"
    }
  }
}

Place this in the published folder you mount into the Docker container so the container reads it on startup. SignalR uses those logger categories for hub and transport diagnostics.

Documentation: Logging and diagnostics for SignalR explains the logger categories to enable and what they cover.

3. Capture container logs (stdout/stderr) and container filesystem

• Use docker logs -f to follow console output (this shows Console provider logs).
• If you used a file logger, enter the container (docker exec -it sh) and inspect the log file under /app or configured path.

Ensure your container process writes logs to stdout/stderr or to files within an accessible volume so they persist across restarts.

4. Enable and collect SignalR-specific diagnostics

Enable detailed SignalR logs on the server by setting the SignalR categories to Debug (done in step 1 or 3). Look specifically for messages from:

• Microsoft.AspNetCore.SignalR — hub lifecycle, invocation, negotiation
• Microsoft.AspNetCore.Http.Connections — transport negotiation, WebSockets, Long Polling

Those categories and what they log are described in the SignalR diagnostics documentation.

5. Capture reverse-proxy (IIS/ARR) and WebSocket diagnostics

Because the problem only appears through IIS/ARR, gather proxy-side traces:

• Enable WebSocket support in IIS and ARR (ensure server roles and ARR proxy websockets are allowed).
• Enable Failed Request Tracing (FREB) in IIS for the site bound to your subdomain; record trace events for status codes and connection issues.
• Enable ARR proxy logging and check Application Request Routing logs.
• Enable HTTP.SYS / IIS WebSocket logging where applicable (IIS logs won’t show WebSocket frames, but FREB + ARR logs can show failures during upgrade/negotiation).

IIS/ARR troubleshooting steps are outside ASP.NET Core docs, but the SignalR diagnostics document explicitly calls out that proxies and intermediaries can break WebSockets and recommends checking the proxy configuration when transport errors occur.

[gavdgavd]

DockerLogs.txt
fr000001.xml
fr000002.xml
freb.xsl_.txt
web.config_.txt

Good afternoon Javier,

Thank you for the detailed instructions. Please find below the collected information:

1. Docker Container details after modifying appsettings.json are available in the attached DockerLogs.txt file.
2. IIS logs generated after enabling FREB can be found in the fr000001.xml, fr000002.xml, and freb.xsl files.
3. WebSockets Protocol is enabled as a Server Role on the Windows Server. The application runs correctly with .NET 8 under this configuration.
4. The IIS ARR configuration is included in web.config file.

In addition, I have exposed two applications (compiled with .NET 8 and .NET 10) to the internet using the URLs below. For now, they are accessible via HTTP to exclude any certificate-related issues. Both were created using the Visual Studio 2026 default Blazor template.

• [Blazor app compiled with .NET 10](http://dn10.gavd.biz)
• [Blazor app compiled with .NET 8](http://dn8.gavd.biz)

Each app contains two buttons:

• Weather – demonstrates that Blazor functionality works correctly in both .NET 8 and .NET 10.
• Counter – includes a button event for the Click me button. This event works as expected in .NET 8 but does not function in .NET 10.

You can also use the browser Developer Tools to trace network activity, errors, and related details.

Please let me know if you need any additional information or further assistance.

Best regards,
Gustavo

[javiercn]

@gavdgavd thanks for the additional details.

From what I can tell from the logs

dbug: Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport[14]
      Socket connection closed prematurely.
      System.Net.WebSockets.WebSocketException (0x80004005): The remote party closed the WebSocket connection without completing the close handshake.
         at System.Net.WebSockets.ManagedWebSocket.ThrowEOFUnexpected()
         at System.Net.WebSockets.ManagedWebSocket.EnsureBufferContainsAsync(Int32 minimumRequiredBytes, CancellationToken cancellationToken)
         at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1.StateMachineBox`1.System.Threading.Tasks.Sources.IValueTaskSource.GetResult(Int16 token)
         at System.Net.WebSockets.ManagedWebSocket.ReceiveAsyncPrivate[TResult](Memory`1 payloadBuffer, CancellationToken cancellationToken)
         at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1.StateMachineBox`1.System.Threading.Tasks.Sources.IValueTaskSource<TResult>.GetResult(Int16 token)
         at Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsServerTransport.StartReceiving(WebSocket socket)
dbug: Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport[4]
      Waiting for the application to finish sending data.
dbug: Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport[2]
      Socket closed.
dbug: Microsoft.AspNetCore.SignalR.HubConnectionContext[2]
      Handshake was canceled.
dbug: Microsoft.AspNetCore.Http.Connections.Internal.HttpConnectionManager[2]
      Removing connection qDPpOUUPBaUij3yOzQ9Ybw from the list of connections.

This points to a configuration issue somewhere in your deployment infrastructure. This seems to be specific to the websocket/signalr configuration.

@BrennanConroy do you have any thoughts/ideas on how to troubleshoot this?