System.Net.Sockets.SocketException (995)

[Ervin304]

When publishing a .NET API as a self-contained application for Win64 and hosting it on Windows Server 2016 as a Windows service, I encounter the following exception.

But when I host the application as framework-depended (only Release) it works ok. I am using .NET 6.0.

Category: Microsoft.AspNetCore.Server.Kestrel
EventId: 0
ConnectionId: 0HMUKF2V30C3N

Connection processing ended abnormally.

Exception: 
System.Net.Sockets.SocketException (995): The I/O operation has been aborted because of either a thread exit or an application request.
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketAwaitableEventArgs.<GetResult>g__ThrowSocketException|5_0(SocketError e)
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketAwaitableEventArgs.GetResult(Int16 token)
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketConnection.DoReceive()
   at System.IO.Pipelines.Pipe.GetReadResult(ReadResult& )
   at System.IO.Pipelines.Pipe.GetReadAsyncResult()
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication`1 application)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequestsAsync[TContext](IHttpApplication`1 application)

Could someone please assist me? I'm having trouble finding the problem?

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

When publishing a .NET API as a self-contained application for Win64 and hosting it on Windows Server 2016 as a Windows service, I encounter the following exception.

But when I host the application as framework-depended (only Release) it works ok. I am using .NET 6.0.

Category: Microsoft.AspNetCore.Server.Kestrel
EventId: 0
ConnectionId: 0HMUKF2V30C3N

Connection processing ended abnormally.

Exception:
System.Net.Sockets.SocketException (995): The I/O operation has been aborted because of either a thread exit or an application request.
at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketAwaitableEventArgs.g__ThrowSocketException|5_0(SocketError e)
at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketAwaitableEventArgs.GetResult(Int16 token)
at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketConnection.DoReceive()
at System.IO.Pipelines.Pipe.GetReadResult(ReadResult& )
at System.IO.Pipelines.Pipe.GetReadAsyncResult()
at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication1 application) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequestsAsync[TContext](IHttpApplication1 application)

Could someone please assist me? I'm having trouble finding the problem?

Author:	Ervin304
Assignees:	-
Labels:	area-System.Net.Sockets
Milestone:	-

[amcasey]

You're not on ARM, are you? We recently fixed a crash in SocketAwaitableEventArgs on ARM.

[amcasey]

We also have an issue about running as a service, but that's on a mac and has different symptoms.

[amcasey]

Looks like this error handling changed in 7.0. I can't tell whether this PR comment was addressed:

We'd only need to throw when app code is in the middle of reading a request body. Otherwise, we can handle the error without ever throwing or catching an exception.

[amcasey]

Perhaps @halter73 or @sebastienros remembers whether #38094 was more than just a perf improvement?

[amcasey]

@Ervin304 is your client seeing errors or is this only happening after the connection ends?

[amcasey]

Also, a sample project exhibiting the problematic behavior would be very helpful.

[sebastienros]

But when I host the application as framework-depended (only Release) it works ok. I am using .NET 6.0.

Is it possible that some roll-forward rule is applied and you are using whatever .NET major version is available? The referenced PR might have fixed your problem (in .NET 7.0). What versions of dotnet do you have on the system? (dotnet --list-runtimes)

Is this issue about the differences in behavior or the fact that one throws an exception?

[amcasey]

@sebastienros My question to you was whether (you remembered whether) the change in 7.0 made it throw less often (i.e. in scenarios where it was safe to continue).

[sebastienros]

It made it throw less often, yes. That was the goal, since we were seeing these exceptions while closing the connections from the client at a high rate in benchmarks.

[danmoseley]

@Ervin304 do you have the ability to try it on 8.0 RC2?

[Ervin304]

is your client seeing errors or is this only happening after the connection ends?

Yes, the clients can see the errors because the HTTP request is being interrupted, leading to an error. When they send a new request, it may work