How to analyze such an exception stack trace? 🤔

[mu88]

Hello,

I'm running dotnet-monitor as a sidecar container for my ASP.NET Core app - everything uses .NET 10.

When calling http://localhost:52323/exceptions?uid=<<UID of my process>>, the following output is returned:

First chance exception at 2026-02-01T09:53:38.7826673Z
System.IO.IOException: Unable to read data from the transport connection: Operation canceled.
 ---> System.Net.Sockets.SocketException: Operation canceled
   --- End of inner exception stack trace ---
   at System.Net.Sockets.Socket+AwaitableSocketAsyncEventArgs.ThrowException(SocketError,CancellationToken)
   at System.Net.Sockets.Socket+AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource<System.Int32>.GetResult(Int16)
   at System.Net.Http.HttpConnection+<<CheckUsabilityOnScavenge>g__ReadAheadWithZeroByteReadAsync|39_0>d.MoveNext
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1+TResult,System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1+TStateMachine].ExecutionContextCallback(Object)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext,ContextCallback,Object)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1+TResult,System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1+TStateMachine].MoveNext(Thread)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1+TResult,System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1+TStateMachine].MoveNext
   at System.Threading.ThreadPoolWorkQueue.Dispatch
   at System.Threading.PortableThreadPool+WorkerThread.WorkerDoWork(PortableThreadPool,Boolean&)
   at System.Threading.PortableThreadPool+WorkerThread.WorkerThreadStart
   at System.Threading.Thread.StartCallback

First chance exception at 2026-02-01T09:53:59.0709352Z
System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'System.Net.Sockets.NetworkStream'.
   at System.Net.Sockets.NetworkStream.ReadAsync(Memory`1[Byte],CancellationToken)
   at System.Net.Http.HttpConnection+<<CheckUsabilityOnScavenge>g__ReadAheadWithZeroByteReadAsync|39_0>d.MoveNext
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1+TResult,System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1+TStateMachine].ExecutionContextCallback(Object)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext,ContextCallback,Object)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1+TResult,System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1+TStateMachine].MoveNext(Thread)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1+TResult,System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1+TStateMachine].MoveNext
   at System.Net.Sockets.SocketAsyncEngine.System.Threading.IThreadPoolWorkItem.Execute
   at System.Threading.ThreadPoolWorkQueue.Dispatch
   at System.Threading.PortableThreadPool+WorkerThread.WorkerDoWork(PortableThreadPool,Boolean&)
   at System.Threading.PortableThreadPool+WorkerThread.WorkerThreadStart
   at System.Threading.Thread.StartCallback

What makes me wonder is that there are no stack frames of my application, i.e., at the moment I have no clue where to start the analysis of where these exceptions are coming from 🤔

Can you help me analyze this issue? Is there any tweak so that dotnet-monitor grabs more information?

Thank you very much 🙂

[wiktork]

These exceptions are most likely thrown by the infrastructure and likely don't reflect an application error (e.g. a client disconnection). You could use exception configuraton to filter exceptions you're not interested in.

[mu88]

Thank you for your reply 🙂 how can I confirm this "most likely"? And why does the infrastructure throw errors if there's nothing wrong?

[wiktork]

We don't have exception triggers currently (#1335 and #875), so it might be challenging to collect additional information with dotnet-monitor. Tools like https://github.com/microsoft/ProcDump-for-Linux might be helpful though.

In general, .NET uses exceptions for async cancellation. OperationCancelledException occur quite often and are usually not an error.

[mu88]

Okay, correct me if I'm wrong, but if I understand you correctly, you're saying there are two types of exceptions: one has to take care of and exceptions that you can ignore, right? The thing is, for me as an app developer, I cannot distinguish between those two types when looking at the metrics counter dotnet.exceptions - it just gets incremented, no matter if it is an exception that I have to ignore or not.