Ensure stacktrace is always present for `ValueTask.FromException` in Networking libs

[jogibear9988]

UPD 2025-07-17 by @CarnaViire

There are cases where we don't assign a stacktrace to an exception when using ValueTask.FromException, i.e. instead of

return ValueTask.FromException(ExceptionDispatchInfo.SetCurrentStackTrace(new SomeException()));

we do just

return ValueTask.FromException(new SomeException());

In general, ExceptionDispatchInfo.SetCurrentStackTrace usage seems inconsistent across Networking libs -- with both ways (assigning and not assigning a stacktrace) sometimes even present within a single file (see #117652 (comment)).

We should make this consistent, and always include the stacktrace (the missing stacktrace makes debugging harder -- the original report below is a good example).

---

Original report by @jogibear9988

Description

I've the following code:

    public async Task SendAsync(byte[] message, WebSocketMessageType messageType, CancellationToken ct)
    {
        try
        {
            if (webSocket.State == WebSocketState.Open)
            {
                await webSocket.SendAsync(new ArraySegment<byte>(message, 0, message.Length), messageType, true, ct);
            }
        }
        catch (Exception ex)
        {
            logger.Error("SendAsync()", ex);
        }
    }

where websocket is an object of System.Net.WebSockets.WebSocket

Now I got 100reds of Messages like this in my log:

    SendAsync() - WebSocketException The remote party closed the WebSocket connection without completing the close handshake.
       at async Task MCC.HttpWebsocketServer.WebsocketConnection.SendAsync(byte[] message, WebSocketMessageType messageType, CancellationToken ct) in C:/BuildAgent/work/fd2044180b81ae6e/MCC.V1.0/6Utilities/MCC.HttpWebsocketServer/WebsocketConnection.cs:line 46Void Throw()
    ObjectDisposedException Cannot write to the response body, the response has completed.
    Object name: 'HttpResponseStream'.    at void Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpResponsePipeWriter.ValidateState(CancellationToken cancellationToken)+ThrowObjectDisposedException()
       at ValueTask System.Net.WebSockets.ManagedWebSocket.SendFrameLockAcquiredNonCancelableAsync(MessageOpcode opcode, bool endOfMessage, bool disableCompression, ReadOnlyMemory<byte> payloadBuffer)

How could that happen? Who is triggering the Send, why do I not see it in my StackTrace?

Reproduction Steps

.

Expected behavior

.

Actual behavior

.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[wfurt]

That seems like environmental problem with your peer. Perhaps get packet captures ... ideally without TLS. Any other suggestions @CarnaViire?

And the ObjectDisposedException is also suspicions. It may be hard to debug without reasonable repro.

[jogibear9988]

Think I'm an Idiot...
Cause I compiled "release", maybe cause of that my caller is missing from the Stacktrace?

[CarnaViire]

@jogibear9988 Hi, thanks for reaching out.
This looks more like a question than a bug report. For us to help you effectively, could you please clarify:

1. What are you trying to achieve?
2. What’s the expected vs. actual behavior?
3. Can you provide a minimal, runnable example that reproduces the issue?

Also, since the stack trace involves ASP.NET Core, you might get better help from their team if this isn’t a .NET runtime issue.

Please update with more details so we can assist further. Thanks!

[jogibear9988]

I think it is solved, i found a timer wich could trigger the send even if closed.

My problem was, why is the timer not in the stacktrace, but could it be cause of release build?

[CarnaViire]

Ah, I get it now. No, it's not the release build --

The stacktrace is missing because the WebSocketException is not thrown but wrapped into a ValueTask.FromException -- and by default the stacktrace is not assigned:

runtime/src/libraries/System.Net.WebSockets/src/System/Net/WebSockets/ManagedWebSocket.cs

Lines 534 to 537 in a436284

	return ValueTask.FromException(
	exc is OperationCanceledException ? exc :
	_state == WebSocketState.Aborted ? CreateOperationCanceledException(exc) :
	new WebSocketException(WebSocketError.ConnectionClosedPrematurely, exc));

For comparison, QuicStream includes the stacktrace via ExceptionDispatchInfo, e.g.:

runtime/src/libraries/System.Net.Quic/src/System/Net/Quic/QuicStream.cs

Line 364 in a436284

return ValueTask.FromException(ExceptionDispatchInfo.SetCurrentStackTrace(new ObjectDisposedException(nameof(QuicStream))));

WebSockets seem rather deliberate in not including the stacktrace (See Code search results: FromException path:src/libraries/System.Net.WebSockets*) -- @stephentoub I wonder if there was a specific reason behind it?

But in general, we don't seem to be consistent across the System.Net.* codebase... some libs use ExceptionDispatchInfo and some don't, and I can even find both ways within a single file (Http2Stream.cs) 😅

runtime/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/Http2Stream.cs

Line 1611 in dec0c3f

return ValueTask.FromException<int>(ExceptionDispatchInfo.SetCurrentStackTrace(new ObjectDisposedException(nameof(Http2ReadStream))));

runtime/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/Http2Stream.cs

Line 1646 in a436284

return ValueTask.FromException(new ObjectDisposedException(nameof(Http2WriteStream)));

[CarnaViire]

Triage: as discussed offline, we should make this consistent, and always include the stacktrace (the missing stacktrace makes debugging harder -- the original report here is a good example).

We will use this issue as a tracking item for addressing all the missing stacktrace cases across Networking libraries.

Not critical for 10.0, putting it to 11.0.