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

Aperta
  • Qualcosa non va?
#70,515 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
csharp
Ambito
backend, networking

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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".
Lingua principale
C#
Stelle
38.5k
Fork
11.6k
Merge medio
3g 1h
PR unite (30g)
289

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dotnet/aspnetcore

Tutte le issue di dotnet/aspnetcore

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.