Aspnetcore: IIS in-process hosting incorrectly throws ConnectionResetException for HTTP POST

[martincostello]

Describe the bug

An ASP.NET Core 2.2.0 application using IIS in-process hosting will intermittently throw ConnectionResetException while reading the request body of an HTTP POST request, causing the request to fail, if the request does not provide an Content-Length HTTP header.

Additionally, if the UseStatusCodePages() exception handler is used, the exception handler fails with an ArgumentException due to a duplicate key.

Based on observed behaviour in our application environment in aggregate, it is _possible_ that this may be related to #6332 and/or #4789 (particularly this).

If a Content-Length HTTP header is specified for the request or if out-of-process hosting is enabled, the exception is not observed.

Stack Trace for exception

Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware:Error: An unhandled exception has occurred while executing the request.

Microsoft.AspNetCore.Connections.ConnectionResetException: The client has disconnected ---> System.IO.EndOfStreamException: Attempted to read past the end of the stream.
   --- End of inner exception stack trace ---
   at Microsoft.AspNetCore.Server.IIS.Core.IO.AsyncIOOperation.GetResult(Int16 token)
   at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.ReadBody()
   at System.IO.Pipelines.PipeCompletion.ThrowLatchedException()
   at System.IO.Pipelines.Pipe.GetReadResult(ReadResult& result)
   at System.IO.Pipelines.Pipe.GetReadAsyncResult()
   at System.IO.Pipelines.Pipe.DefaultPipeReader.GetResult(Int16 token)
   at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.ReadAsync(Memory`1 memory, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.IIS.Core.HttpRequestStream.ReadAsyncInternal(Memory`1 buffer, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.WebUtilities.FileBufferingReadStream.ReadAsync(Byte[] buffer, Int32 offset, Int32 count, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.WebUtilities.StreamHelperExtensions.DrainAsync(Stream stream, ArrayPool`1 bytePool, Nullable`1 limit, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Mvc.Formatters.JsonInputFormatter.ReadRequestBodyAsync(InputFormatterContext context, Encoding encoding)
   at Microsoft.AspNetCore.Mvc.ModelBinding.Binders.BodyModelBinder.BindModelAsync(ModelBindingContext bindingContext)
   at Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder.BindModelAsync(ActionContext actionContext, IModelBinder modelBinder, IValueProvider valueProvider, ParameterDescriptor parameter, ModelMetadata metadata, Object value)
   at Microsoft.AspNetCore.Mvc.Internal.ControllerBinderDelegateProvider.<>c__DisplayClass0_0.<<CreateBinderDelegate>g__Bind|0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.InvokeInnerFilterAsync()
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeNextResourceFilter()
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Rethrow(ResourceExecutedContext context)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeFilterPipelineAsync()
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeAsync()
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.Invoke(HttpContext httpContext)
   at Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware.Invoke(HttpContext httpContext)
   at Microsoft.AspNetCore.Diagnostics.StatusCodePagesMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.Invoke(HttpContext context)

Stack trace when status code pages fails

Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware:Error: An exception was thrown attempting to execute the error handler.

System.ArgumentException: An item with the same key has already been added. Key: Allow
   at System.Collections.Generic.Dictionary`2.TryInsert(TKey key, TValue value, InsertionBehavior behavior)
   at System.Collections.Generic.Dictionary`2.Add(TKey key, TValue value)
   at Microsoft.AspNetCore.HttpSys.Internal.HeaderCollection.Add(String key, StringValues value)
   at Microsoft.AspNetCore.Routing.Matching.HttpMethodMatcherPolicy.<>c__DisplayClass12_0.<CreateRejectionEndpoint>b__0(HttpContext context)
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.Invoke(HttpContext httpContext)
   at Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware.Invoke(HttpContext httpContext)
   at Microsoft.AspNetCore.Builder.StatusCodePagesExtensions.<>c__DisplayClass6_0.<<UseStatusCodePagesWithReExecute>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNetCore.Diagnostics.StatusCodePagesMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.Invoke(HttpContext context)
Exception thrown: 'Microsoft.AspNetCore.Connections.ConnectionResetException' in System.Private.CoreLib.dll

Microsoft.AspNetCore.Server.IIS.Core.IISHttpServer:Error: Connection ID "18086456109425491975", Request ID "80002fc9-0001-fb00-b63f-84710c7967bb": An unhandled exception was thrown by the application.

To Reproduce

A repro application with instructions can be found here: https://github.com/martincostello/AspNetCoreReproFor6415

Expected behavior

The application correctly responds to the HTTP POST request.

[martincostello]

Have opened #6416 to fix the duplicate key exception.

[pakrym]

I'll take a look on Monday.

[martincostello]

Having a bit a dig into the code myself in Visual Studio with the repro, it looks like the code is reaching this point with a hr value of -2147024858 (HResult 0x80070026) and a bytes value of 0.

https://github.com/aspnet/AspNetCore/blob/3477daf3c4f530dff80f197e0642cb39a26fb07b/src/Servers/IIS/IIS/src/Core/IO/AsyncIOOperation.cs#L108

I guess that points towards the unmanaged part of the code?

[martincostello]

Managed and native call stack is:

>   Microsoft.AspNetCore.Server.IIS.dll!Microsoft.AspNetCore.Server.IIS.Core.IO.AsyncIOOperation.Complete(int hr, int bytes) Line 108   C#
    Microsoft.AspNetCore.Server.IIS.dll!Microsoft.AspNetCore.Server.IIS.Core.IO.AsyncIOEngine.NotifyCompletion(int hr, int bytes) Line 112  C#
    Microsoft.AspNetCore.Server.IIS.dll!Microsoft.AspNetCore.Server.IIS.Core.IISHttpServer.OnAsyncCompletion(System.IntPtr pvManagedHttpContext, int hr, int bytes) Line 225    C#
    [Native to Managed Transition]  
    aspnetcorev2_inprocess.dll!00007ffb8bbfac54()   Unknown
    aspnetcorev2_inprocess.dll!00007ffb8bbf166e()   Unknown
    aspnetcorev2.dll!00007ffbbdbcd9b5() Unknown
    iiscore.dll!00007ffbc80e20dd()  Unknown
    iiscore.dll!00007ffbc80e13f7()  Unknown
    iiscore.dll!00007ffbc80cea14()  Unknown
    iiscore.dll!00007ffbc80e2dbd()  Unknown
    iiscore.dll!00007ffbc80d3789()  Unknown
    iiscore.dll!00007ffbc80d3e3d()  Unknown
    w3dt.dll!00007ffbda3f59aa() Unknown
    w3dt.dll!00007ffbda3f64d0() Unknown
    w3dt.dll!00007ffbda3f4e42() Unknown
    w3tp.dll!00007ffbda482bbe() Unknown
    w3tp.dll!00007ffbda481819() Unknown
    kernel32.dll!BaseThreadInitThunk
()  Unknown
    ntdll.dll!RtlUserThreadStart
()  Unknown

[JamesNK]

Additionally, if the UseStatusCodePages() exception handler is used, the exception handler fails with an ArgumentException due to a duplicate key.

This is an issue in the new routing HTTP method matcher when an errored request is re-executed. Thanks @martincostello for the PR fix - https://github.com/aspnet/AspNetCore/pull/6416

If this issue is blocking you then you can use the older routing system in 2.2 by disabling endpoint routing in Startup.cs:

services.UseMvc(options => options.EnableEndpointRouting = false);

// @rynowak

[martincostello]

I only stumbled across the duplicate key exception while trying to write the repro for the connection disconnected exception, but that's useful to know. 👍

[martincostello]

@JamesNK Unrelated to the duplicate key bug, we've just had to disable endpoint routing in an application using status code pages as it was returning 405s to a client application instead of 404s.

Is there something specific required as part of the migration from 2.1 to 2.2 we might have missed that's causing that, or is that a _different_ bug?

Originally we'd disabled endpoint routing because of #4468, but today we refactored the code to not be dependent on the original 2.1 behaviour, so re-enabled endpoint routing.

[pakrym]

I guess that points towards the unmanaged part of the code?

Yes, ConnectionResetException is always caused by IIS signalling about premature request body end.

[pakrym]

There are some traces of the similar issues around (https://blogs.msdn.microsoft.com/napegadie_kones_msft_blog/2016/01/26/502-web-server-received-an-invalid-response-while-acting-as-a-gateway-or-proxy-server/) and it seems to be connected to trying to read request body multiple times.

[pakrym]

I can easily repro the error by starting the client, stopping it and then restarting again (which is semi-expected). But not by just running the client continuously

> dotnet run
Host URL           : http://localhost:50692
Buffer request body: False
........................................................................................................................................................................................................................................................................................................................................................
448722 requests made successfully in 00:06:02.4055324.

[martincostello]

Interesting - I was able to consistently repro it within 1-2 minutes as long as it wasn't buffered.

[pakrym]

It is still a bit strange that request is aborted only after client is restarted so I'll keep looking into this.

[martincostello]

I did notice when I could repro it that once it errored, restarting the client without touching the server would make the first request of the second execution fail immediately. Opening additional instances would _sometimes_ fail immediately, and other times would continue to happily make requests again.

Maybe some sort of shared state to do with connections or something is getting corrupted?

[pakrym]

I think it's much simpler, ERROR_HANDLE_EOF is a "successfull" error code notifying end of request body.

Other https.sys based servers seem to handle it as such (https://github.com/tjanczuk/httpsys/blob/master/src/httpsys.cc#L828)

[martincostello]

Oh, so it's just as simple as a change to if (hr != NativeMethods.HR_OK && hr != ERROR_HANDLE_EOF) here?

[pakrym]

Sorta, AsyncContinuation.Complete is shared between multiple operation kinds (Read/Write/Flush). And I would prefer handling ERROR_HANDLE_EOF only for reads.

[pakrym]

The only thing that keeps me suspicious is that I'm not able to find any code handling ERROR_HANDLE_EOF in System.Web referencesources.

[JamesNK]

@JamesNK Unrelated to the duplicate key bug, we've just had to disable endpoint routing in an application using status code pages as it was returning 405s to a client application instead of 404s.

Changing to a 405 response is intentional. It is the correct response when the HTTP method is not supported - https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/405

[martincostello]

But these are just simple HTTP GETs (our application routes haven’t been changed for quite some time), so the methods being used are the same as ones that previously worked fine.

[ahmelsayed]

@pakrym I may be doing things wrong, but we have an issue where sometimes doing

string requestBody = await new StreamReader(req.Body).ReadToEndAsync();

on a request with chunk encoding

throws this exception

 Microsoft.AspNetCore.Connections.ConnectionResetException : The client has disconnected 
 System.IO.EndOfStreamException : Attempted to read past the end of the stream. 
   End of inner exception
   at Microsoft.AspNetCore.Server.IIS.Core.IO.AsyncIOOperation.GetResult(Int16 token)
   at async Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.ReadBody()
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.IO.Pipelines.PipeCompletion.ThrowLatchedException()
   at System.IO.Pipelines.Pipe.GetReadResult(ReadResult& result)
   at System.IO.Pipelines.Pipe.GetReadAsyncResult()
   at System.IO.Pipelines.Pipe.DefaultPipeReader.GetResult(Int16 token)
   at async Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.ReadAsync(Memory`1 memory,CancellationToken cancellationToken)
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at async Microsoft.AspNetCore.Server.IIS.Core.HttpRequestStream.ReadAsyncInternal(Memory`1 buffer,CancellationToken cancellationToken)
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at async System.IO.StreamReader.ReadBufferAsync()
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at async System.IO.StreamReader.ReadToEndAsyncInternal()
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()

I tried building https://github.com/aspnet/AspNetCore/pull/6483 and replacing aspnetcorev2_inprocess.dll in C:\Program Files (x86)\dotnet\shared\Microsoft.AspNetCore.App\2.2.1\ but now all requests that are chunk encoded throw the same exception.

All these requests that cause the exception (before and after replacing aspnetcorev2_inprocess.dll) always resulted in 200 responses as soon as the exception is thrown. I'm not sure if I'm doing something wrong here.

[pakrym]

Try replacing Microsoft.AspNetCore.Server.IIS.dll too.

[ahmelsayed]

yep, that was it. Thanks @pakrym!!

[pakrym]

Ported to 2.2

[martincostello]

Regarding the 405 responses, these are still being served instead of 404s (and then hitting the bug fixed by #6416) when endpoint routing is enabled. The clients are unchanged and the code change is purely enabling endpoint routing. _Something_ somewhere is changing the behaviour in MVC so that a 405 is being served instead of running our custom error handler that produces a 404.

The only thing from our logs (other than the errors themselves) that seems suspicious is that our logs have an empty value for the HTTP method in our structured logging when we log the ArgumentException for the duplicate key. Could it be that the method is being lost by the routing somewhere, which then means it fails to match to a route and then thinks it's a 405?

[vankampenp]

I think this is related, see the log below. Strangely enough, I get this error intermittently, but always on the same POST method. That method is simply updating something in the database.
This was not occuring on 2.1, but started with 2.2 (I am using in process hosting).

I have now implemented @JamesNK suggestion to use the older routing system:

  services.AddMvc(options =>   { options.EnableEndpointRouting = false;   })

(I think it should be AddMvc iso UseMvc)
I will wait a week to see if this has been solved by this

error = Microsoft.AspNetCore.Connections.ConnectionResetException: The client has disconnected ---> System.Runtime.InteropServices.COMException: De opgegeven netwerknaam is niet langer beschikbaar. (Exception from HRESULT: 0x80070040)
   --- End of inner exception stack trace ---
   at Microsoft.AspNetCore.Server.IIS.Core.IO.AsyncIOOperation.GetResult(Int16 token)
   at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.ReadBody()
   at System.IO.Pipelines.PipeCompletion.ThrowLatchedException()
   at System.IO.Pipelines.Pipe.GetReadResult(ReadResult& result)
   at System.IO.Pipelines.Pipe.ReadAsync(CancellationToken token)
   at System.IO.Pipelines.Pipe.DefaultPipeReader.ReadAsync(CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.ReadAsync(Memory`1 memory, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.IIS.Core.HttpRequestStream.ReadAsyncInternal(Memory`1 buffer, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.WebUtilities.FileBufferingReadStream.ReadAsync(Byte[] buffer, Int32 offset, Int32 count, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.WebUtilities.StreamHelperExtensions.DrainAsync(Stream stream, ArrayPool`1 bytePool, Nullable`1 limit, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Mvc.Formatters.JsonInputFormatter.ReadRequestBodyAsync(InputFormatterContext context, Encoding encoding)
   at Microsoft.AspNetCore.Mvc.ModelBinding.Binders.BodyModelBinder.BindModelAsync(ModelBindingContext bindingContext)
   at Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder.BindModelAsync(ActionContext actionContext, IModelBinder modelBinder, IValueProvider valueProvider, ParameterDescriptor parameter, ModelMetadata metadata, Object value)
   at Microsoft.AspNetCore.Mvc.Internal.ControllerBinderDelegateProvider.<>c__DisplayClass0_0.<<CreateBinderDelegate>g__Bind|0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.InvokeInnerFilterAsync()
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeNextResourceFilter()
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Rethrow(ResourceExecutedContext context)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeFilterPipelineAsync()
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeAsync()
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.Invoke(HttpContext httpContext)
   at Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware.Invoke(HttpContext httpContext)
   at Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware.Invoke(HttpContext context)
   at WebMarkupMin.AspNetCore2.WebMarkupMinMiddleware.Invoke(HttpContext context)
   at DTOWEB.Startup.<>c.<<Configure>b__6_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.Invoke(HttpContext context)|

[pakrym]

@vankampenp It doesn't seem to be related. 0x80070040 is very different error code. Is request body large? Is it possible client goes away (or page is refreshed) while request is being sent?

[vankampenp]

@pakrym The request body is small, it takes about 200ms from the client, and about 100ms server side. It is not logical for the client to go away in that time and so often. Simultaneously a second ajax call to the server is made that is much longer, up to a few seconds.
The Dutch part in the error says: The provided network name is no longer available.

[vankampenp]

2019-04-12 22:27:00.0743|ERROR|Error Page Path=/questionsSaveAnswer, error = Microsoft.AspNetCore.Connections.ConnectionResetException: De externe host heeft een verbinding verbroken ---> System.Net.Sockets.SocketException: De externe host heeft een verbinding verbroken
at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketAwaitableEventArgs.g__ThrowSocketException|7_0(SocketError e)
at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketAwaitableEventArgs.GetResult()
at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketConnection.ProcessReceives()
at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketConnection.DoReceive()
--- End of inner exception stack trace ---
at System.IO.Pipelines.PipeCompletion.ThrowLatchedException()
at System.IO.Pipelines.Pipe.GetReadResult(ReadResult& result)
at System.IO.Pipelines.Pipe.ReadAsync(CancellationToken token)
at System.IO.Pipelines.Pipe.DefaultPipeReader.ReadAsync(CancellationToken cancellationToken)
at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1MessageBody.PumpAsync()
at System.IO.Pipelines.PipeCompletion.ThrowLatchedException()
at System.IO.Pipelines.Pipe.GetReadResult(ReadResult& result)
at System.IO.Pipelines.Pipe.ReadAsync(CancellationToken token)
at System.IO.Pipelines.Pipe.DefaultPipeReader.ReadAsync(CancellationToken cancellationToken)
at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.MessageBody.StartTimingReadAsync(CancellationToken cancellationToken)
at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.MessageBody.ReadAsync(Memory1 buffer, CancellationToken cancellationToken) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpRequestStream.ReadAsyncInternal(Memory1 buffer, CancellationToken cancellationToken)
at Microsoft.AspNetCore.WebUtilities.FileBufferingReadStream.ReadAsync(Byte[] buffer, Int32 offset, Int32 count, CancellationToken cancellationToken)
at Microsoft.AspNetCore.WebUtilities.StreamHelperExtensions.DrainAsync(Stream stream, ArrayPool1 bytePool, Nullable1 limit, CancellationToken cancellationToken)
at Microsoft.AspNetCore.Mvc.Formatters.JsonInputFormatter.ReadRequestBodyAsync(InputFormatterContext context, Encoding encoding)
at Microsoft.AspNetCore.Mvc.ModelBinding.Binders.BodyModelBinder.BindModelAsync(ModelBindingContext bindingContext)
at Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder.BindModelAsync(ActionContext actionContext, IModelBinder modelBinder, IValueProvider valueProvider, ParameterDescriptor parameter, ModelMetadata metadata, Object value)
at Microsoft.AspNetCore.Mvc.Internal.ControllerBinderDelegateProvider.<>c__DisplayClass0_0.<g__Bind|0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.InvokeInnerFilterAsync()
at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeNextResourceFilter()
at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Rethrow(ResourceExecutedContext context)
at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeFilterPipelineAsync()
at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeAsync()
at Microsoft.AspNetCore.Builder.RouterMiddleware.Invoke(HttpContext httpContext)
at Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware.Invoke(HttpContext context)
at WebMarkupMin.AspNetCore2.WebMarkupMinMiddleware.Invoke(HttpContext context)
at DTOWEB.Startup.<>c.<b__6_1>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at Joonasw.AspNetCore.SecurityHeaders.Csp.CspMiddleware.Invoke(HttpContext context)
at Joonasw.AspNetCore.SecurityHeaders.Hsts.HstsMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.Invoke(HttpContext context)|

[rodion-m]

It doesn't seem to be related. 0x80070040 is very different error code. Is request body large? Is it possible client goes away (or page is refreshed) while request is being sent?

Hi @pakrym ! This is actually our issue that we met just now with a large body (client has a timeout of 5.000 ms, obviously it was not enough). Is there any way to prevent this server exception? It's not good that it's throwing.
Here is a stack trace (.net core 2.2.5):

System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
  Module "Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketAwaitableEventArgs", in <GetResult>g__ThrowSocketException|7_0
  Module "Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketAwaitableEventArgs", in GetResult
  Module "Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketConnection", in ProcessReceives
  Module "System.Runtime.ExceptionServices.ExceptionDispatchInfo", in Throw
  Module "System.Runtime.CompilerServices.TaskAwaiter", in HandleNonSuccessAndDebuggerNotification
  Module "Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketConnection", in DoReceive

Microsoft.AspNetCore.Connections.ConnectionResetException: An existing connection was forcibly closed by the remote host
  Module "System.Runtime.ExceptionServices.ExceptionDispatchInfo", in Throw
  Module "System.IO.Pipelines.PipeCompletion", in ThrowLatchedException
  Module "System.IO.Pipelines.Pipe", in GetReadResult
  Module "System.IO.Pipelines.Pipe", in GetReadAsyncResult
  Module "System.IO.Pipelines.Pipe+DefaultPipeReader", in GetResult
  Module "System.Runtime.CompilerServices.ValueTaskAwaiter`1", in GetResult
  Module "Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1MessageBody", in PumpAsync
  Module "System.Runtime.ExceptionServices.ExceptionDispatchInfo", in Throw
  Module "System.IO.Pipelines.PipeCompletion", in ThrowLatchedException
  Module "System.IO.Pipelines.Pipe", in GetReadResult
  Module "System.IO.Pipelines.Pipe", in GetReadAsyncResult
  Module "System.IO.Pipelines.Pipe+DefaultPipeReader", in GetResult
  Module "System.Runtime.CompilerServices.ValueTaskAwaiter`1", in GetResult
  Module "Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.MessageBody", in ReadAsync
  Module "System.Runtime.ExceptionServices.ExceptionDispatchInfo", in Throw
  Module "System.Runtime.CompilerServices.TaskAwaiter", in HandleNonSuccessAndDebuggerNotification
  Module "System.Runtime.CompilerServices.ValueTaskAwaiter`1", in GetResult
  Module "Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpRequestStream", in ReadAsyncInternal
  Module "System.Runtime.ExceptionServices.ExceptionDispatchInfo", in Throw
  Module "System.Runtime.CompilerServices.TaskAwaiter", in HandleNonSuccessAndDebuggerNotification
  Module "System.Runtime.CompilerServices.TaskAwaiter`1", in GetResult
  Module "Microsoft.AspNetCore.WebUtilities.FileBufferingReadStream", in ReadAsync
  Module "System.Runtime.ExceptionServices.ExceptionDispatchInfo", in Throw
  Module "System.Runtime.CompilerServices.TaskAwaiter", in HandleNonSuccessAndDebuggerNotification
  Module "System.Runtime.CompilerServices.TaskAwaiter`1", in GetResult
  Module "Microsoft.AspNetCore.WebUtilities.StreamHelperExtensions", in DrainAsync
  Module "System.Runtime.ExceptionServices.ExceptionDispatchInfo", in Throw
  Module "System.Runtime.CompilerServices.TaskAwaiter", in HandleNonSuccessAndDebuggerNotification
  Module "Microsoft.AspNetCore.Mvc.Formatters.JsonInputFormatter", in ReadRequestBodyAsync
  Module "System.Runtime.ExceptionServices.ExceptionDispatchInfo", in Throw
  Module "System.Runtime.CompilerServices.TaskAwaiter", in HandleNonSuccessAndDebuggerNotification
  Module "System.Runtime.CompilerServices.TaskAwaiter`1", in GetResult
  Module "Microsoft.AspNetCore.Mvc.ModelBinding.Binders.BodyModelBinder", in BindModelAsync
  Module "System.Runtime.ExceptionServices.ExceptionDispatchInfo", in Throw
  Module "System.Runtime.CompilerServices.TaskAwaiter", in HandleNonSuccessAndDebuggerNotification
  Module "Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder", in BindModelAsync
  Module "System.Runtime.ExceptionServices.ExceptionDispatchInfo", in Throw
  Module "System.Runtime.CompilerServices.TaskAwaiter", in HandleNonSuccessAndDebuggerNotification
  Module "System.Runtime.CompilerServices.TaskAwaiter`1", in GetResult
  Module "Microsoft.AspNetCore.Mvc.Internal.ControllerBinderDelegateProvider+<>c__DisplayClass0_0+<<CreateBinderDelegate>g__Bind|0>d", in MoveNext
  Module "System.Runtime.ExceptionServices.ExceptionDispatchInfo", in Throw
  Module "System.Runtime.CompilerServices.TaskAwaiter", in HandleNonSuccessAndDebuggerNotification
  Module "Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker", in InvokeInnerFilterAsync
  Module "System.Runtime.ExceptionServices.ExceptionDispatchInfo", in Throw
  Module "System.Runtime.CompilerServices.TaskAwaiter", in HandleNonSuccessAndDebuggerNotification
  Module "Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker", in InvokeFilterPipelineAsync
  Module "System.Runtime.ExceptionServices.ExceptionDispatchInfo", in Throw
  Module "System.Runtime.CompilerServices.TaskAwaiter", in HandleNonSuccessAndDebuggerNotification
  Module "Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker", in InvokeAsync
  Module "System.Runtime.ExceptionServices.ExceptionDispatchInfo", in Throw
  Module "System.Runtime.CompilerServices.TaskAwaiter", in HandleNonSuccessAndDebuggerNotification
  Module "Microsoft.AspNetCore.Routing.EndpointMiddleware", in Invoke
  Module "System.Runtime.ExceptionServices.ExceptionDispatchInfo", in Throw
  Module "System.Runtime.CompilerServices.TaskAwaiter", in HandleNonSuccessAndDebuggerNotification
  Module "Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware", in Invoke
  Module "System.Runtime.ExceptionServices.ExceptionDispatchInfo", in Throw
  Module "System.Runtime.CompilerServices.TaskAwaiter", in HandleNonSuccessAndDebuggerNotification
  Module "Microsoft.AspNetCore.ResponseCompression.ResponseCompressionMiddleware", in Invoke
  Module "System.Runtime.ExceptionServices.ExceptionDispatchInfo", in Throw
  Module "System.Runtime.CompilerServices.TaskAwaiter", in HandleNonSuccessAndDebuggerNotification
  Module "Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware", in Invoke
  Module "System.Runtime.ExceptionServices.ExceptionDispatchInfo", in Throw
  Module "System.Runtime.CompilerServices.TaskAwaiter", in HandleNonSuccessAndDebuggerNotification
  File "C:\Projects\Goodwins\Goodwins.Server\Extensions\UseSerilogContext.cs", line 30, col 6, in MoveNext
    Void MoveNext()
  Module "System.Runtime.ExceptionServices.ExceptionDispatchInfo", in Throw
  Module "System.Runtime.CompilerServices.TaskAwaiter", in HandleNonSuccessAndDebuggerNotification
  Module "Microsoft.AspNetCore.Authentication.AuthenticationMiddleware", in Invoke
  Module "System.Runtime.ExceptionServices.ExceptionDispatchInfo", in Throw
  Module "System.Runtime.CompilerServices.TaskAwaiter", in HandleNonSuccessAndDebuggerNotification
  Module "Microsoft.AspNetCore.Diagnostics.StatusCodePagesMiddleware", in Invoke
  Module "System.Runtime.ExceptionServices.ExceptionDispatchInfo", in Throw
  Module "System.Runtime.CompilerServices.TaskAwaiter", in HandleNonSuccessAndDebuggerNotification
  Module "Microsoft.AspNetCore.Server.IISIntegration.IISMiddleware", in Invoke
  Module "System.Runtime.ExceptionServices.ExceptionDispatchInfo", in Throw
  Module "Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol+<ProcessRequests>d__185`1", in MoveNext