2

In our WPF application, we do register an event handler for unobserved task exception:

TaskScheduler.UnobservedTaskException += OnUnobservedTaskException;

with the following method:

private static void OnUnobservedTaskException(object sender, UnobservedTaskExceptionEventArgs exceptionEventArgs)
{
    _logger.Error(exceptionEventArgs.Exception, Properties.Resources.TaskExceptionsWereNotObserved);
    exceptionEventArgs.SetObserved();
}

I do get the full stack trace:

System.AggregateException: A Task's exception(s) were not observed either by Waiting on the Task or accessing its Exception property. As a result, the unobserved exception was rethrown by the finalizer thread. (The I/O operation has been aborted because of either a thread exit or an application request.)
     ---> System.Net.Sockets.SocketException (995): The I/O operation has been aborted because of either a thread exit or an application request.
       at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource<System.Net.Sockets.SocketReceiveFromResult>.GetResult(Int16 token)
       at System.Threading.Tasks.ValueTask`1.ValueTaskSourceAsTask.<>c.<.cctor>b__4_0(Object state)
       --- End of inner exception stack trace ---

But nothing seems to be in our code.

My question:

Is there a way to add more debug information to know where this was triggered? Because I'm not even sure the exception happens in our code or in an external library.

Peter Csala
  • 17,736
  • 16
  • 35
  • 75
J4N
  • 19,480
  • 39
  • 187
  • 340
  • 1
    You can find more information in the inner exceptions of the `AggregateException`. See here: https://stackoverflow.com/a/44378474/689923 – Mo B. Aug 28 '23 at 07:50
  • @MoB. Hi thanks, but I can already see the innerException is a `SocketException`, but that doesn't help me to understand where this exception is triggered from? – J4N Aug 28 '23 at 10:47
  • How can you see that the inner exception is a `SocketException`? The stack trace does not show the inner exceptions. – Mo B. Aug 28 '23 at 10:51
  • @MoB. Yes it does, check the stacktrace I provided in the question: `System.Net.Sockets.SocketException (995): The I/O operation has been aborted because of either a thread exit or an application request.` . Also, since it's some code that is probably improperly written, I can just put a breakpoint and have all the information from the exception, but the stacktrace of the `SocketException` doesn't show any line in my own code. – J4N Aug 28 '23 at 11:03
  • The error has several pointers. It's a network operation, in either an action or background operation. The application didn't await the operation (due to `async void` perhaps) so when the controller or service was eventually garbage collected, the network request was also cancelled. There's no stack because by the time the operation is cancelled, there are no parent tasks or calls any more. – Panagiotis Kanavos Aug 28 '23 at 11:58
  • Is the application a web app perhaps? Did you try to execute start a long-running job with `Task.Run` in an action? Requests are served by separate threads and have their own scope. Once the request completes, all objects the runtime knows about get garbage-collected. The runtime *does* warn registered background jobs through a CancellationToken, to give them a chance to gracefully cancel – Panagiotis Kanavos Aug 28 '23 at 12:02
  • @PanagiotisKanavos No, it's a WPF app. It starts a lot of Task.Run, but through an helper class that wraps all the `Action` execution, and this wrapper does catch everything. That's why I think the Task and the linked exception is in one of our library, but since the solution is roughly 3 million line of codes and we have a lot of dependency, it's a bit hard to find which one fails. On the other side, we also use async/await and do not have a way to check async call that are not awaited. – J4N Aug 28 '23 at 13:12

0 Answers0