AccessViolationException crashes w3wp on .NET 11 with IIS in-process hosting (SignalR hub invocation reads local endpoint in IISHttpContext.InitializeLocalEndpoint)

Open
  • Is something wrong?
#70,515 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
backend, networking

Research direction

Start by tracing the reported call path from SignalR's DefaultHubDispatcher.StartActivity through ConnectionEndpointTags.AddConnectionEndpointTags to IIS's IISHttpContext.InitializeLocalEndpoint and NativeRequestContext.GetEndPoint. The report gives no source files or minimal reproduction, so first determine when the native request memory becomes invalid during in-process hosting. Done means endpoint tag collection no longer crashes the worker process in the reported scenario, with the fix covered by a reproducible test.

Written by the indexing model from the issue text.

Description

area-signalr
Describe the bug

After upgrading a Blazor Web App (interactive server rendering) from .NET 10 to .NET 11.0.0, the IIS worker process is terminated by an AccessViolationException when it is hosted in-process. It happens during a SignalR hub method invocation (Blazor circuit traffic). After several crashes IIS rapid-fail protection stops the application pool and the site returns HTTP 503.

The faulting path is DefaultHubDispatcher.StartActivity → ConnectionEndpointTags.AddConnectionEndpointTags → IConnectionEndPointFeature.LocalEndPoint → IISHttpContext.InitializeLocalEndpoint → NativeRequestContext.GetEndPoint → SocketAddress.CopyOutAddress. The local endpoint is read lazily from the native request, apparently when that memory is no longer valid.

Expected Behavior

No crash. Reading the connection endpoint for activity tags should not touch native request memory that has been released, or should fail safely.

Steps To Reproduce

No minimal repro yet. Observed with:

  1. A Blazor Web App using AddInteractiveServerComponents() / AddInteractiveServerRenderMode(), targeting net11.0-windows, published self-contained for win-x64.
  2. Deployed to IIS with hostingModel="inprocess".
  3. Users open pages and interact; the worker process crashes with the stack below.

The same build on the same server with hostingModel="outofprocess" runs without the crash. The same application ran in-process on .NET 10 without it. The app does not register any OpenTelemetry or ActivityListener of its own.

Unverified guess: the invocation arrives on a connection whose originating HTTP request has already completed (for example the long-polling transport), so the native request backing IISHttpContext is gone when the endpoint is first read.

Exceptions (if any)
Application: w3wp.exe
CoreCLR Version: 11.0.26.53018
.NET Version: 11.0.0
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
Stack:
   at System.Runtime.EH.DispatchEx(System.Runtime.StackFrameIterator ByRef, ExInfo ByRef)
   at System.Runtime.EH.RhThrowHwEx(UInt32, ExInfo*)
   at Microsoft.AspNetCore.HttpSys.Internal.SocketAddress.CopyOutAddress(Windows.Win32.Networking.WinSock.SOCKADDR*)
   at Microsoft.AspNetCore.HttpSys.Internal.NativeRequestContext.GetEndPoint(Boolean)
   at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.InitializeLocalEndpoint()
   at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.Microsoft.AspNetCore.Http.Features.IHttpConnectionFeature.get_LocalIpAddress()
   at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.Microsoft.AspNetCore.Connections.Features.IConnectionEndPointFeature.get_LocalEndPoint()
   at Microsoft.AspNetCore.Shared.ConnectionEndpointTags.AddConnectionEndpointTags(System.Diagnostics.TagList ByRef, Microsoft.AspNetCore.Http.Features.IFeatureCollection)
   at Microsoft.AspNetCore.SignalR.Internal.DefaultHubDispatcher`1.StartActivity(System.String, System.Diagnostics.ActivityKind, System.Diagnostics.Activity, System.IServiceProvider, System.String, System.Collections.Generic.IDictionary`2<System.String,System.String>, Microsoft.Extensions.Logging.ILogger, Microsoft.AspNetCore.SignalR.HubConnectionContext)
   at Microsoft.AspNetCore.SignalR.Internal.DefaultHubDispatcher`1.<Invoke>g__ExecuteInvocation|24_0(...)
   at Microsoft.AspNetCore.SignalR.Internal.DefaultHubDispatcher`1.Invoke(Microsoft.AspNetCore.SignalR.Internal.HubMethodDescriptor, Microsoft.AspNetCore.SignalR.HubConnectionContext, Microsoft.AspNetCore.SignalR.Protocol.HubMethodInvocationMessage, Boolean, Boolean)
   at Microsoft.AspNetCore.SignalR.Internal.DefaultHubDispatcher`1+<>c.<ProcessInvocation>b__23_0(...)
   at Microsoft.AspNetCore.SignalR.Internal.ChannelBasedSemaphore.RunTask(...)
   at Microsoft.AspNetCore.SignalR.Internal.ChannelBasedSemaphore.RunAsync(...)
   at Microsoft.AspNetCore.SignalR.Internal.DefaultHubDispatcher`1.ProcessInvocation(Microsoft.AspNetCore.SignalR.HubConnectionContext, Microsoft.AspNetCore.SignalR.Protocol.HubMethodInvocationMessage, Boolean)
   at Microsoft.AspNetCore.SignalR.Internal.DefaultHubDispatcher`1.DispatchMessageAsync(Microsoft.AspNetCore.SignalR.HubConnectionContext, Microsoft.AspNetCore.SignalR.Protocol.HubMessage)
   at Microsoft.AspNetCore.SignalR.HubConnectionHandler`1.DispatchMessagesAsync(Microsoft.AspNetCore.SignalR.HubConnectionContext)
   at System.Runtime.CompilerServices.AsyncHelpers+RuntimeAsyncTask`1.DispatchContinuations()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
   at System.Threading.PortableThreadPool+WorkerThread.WorkerDoWork(System.Threading.PortableThreadPool)
   at System.Threading.PortableThreadPool+WorkerThread.WorkerThreadStart()
   at System.Threading.Thread.StartCallback(System.Threading.Thread*)
.NET Version

11.0.0 (self-contained, win-x64; SDK 11.0.100)

Anything else?
  • Hosting: IIS, in-process, self-contained deployment.
  • Server OS version, whether the IIS WebSocket Protocol feature is installed, and the installed ASP.NET Core Hosting Bundle version: not yet confirmed; will add in a comment.
  • Workaround: hostingModel="outofprocess".
Dominant language
C#
Stars
38.5k
Forks
11.6k
Avg merge
3d 1h
Merged PRs (30d)
289

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dotnet/aspnetcore

All issues in dotnet/aspnetcore

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.