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

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.

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".