Runtime: Exception thrown: 'System.AggregateException' in System.Private.CoreLib.dll

[sujayvsarma]

No clue what this is about.

Setup:

• ASP.NET Core 3.0 (.NET Core version: 3.1.100-preview3-014645)
• MVC application

This is logged to the output window:
Exception thrown: 'System.AggregateException' in System.Private.CoreLib.dll

It would be good to know where this is coming from and why?

[Gnbrkm41]

Try setting Exception settings menu - Break when thrown - check "System.AggregationException" in VS. It is a very generic exception that just means "more than one exceptions happened"; without any messages / stack trace / inner exceptions / reproducible code, it is impossible to diagnose what the cause of it is.

[huoyaoyuan]

Asynchronous code are heavily used in ASP.Net, and async wrapper will implicitly wrap exceptions from worker thread into AggregateException.

To get break at the real throw point, it's better to set VS to break when _any managed exception is thrown_.

[sujayvsarma]

To get break at the real throw point, it's better to set VS to break when any managed exception is thrown.

That makes it almost impossible to debug in some situations. Most of my work involves finding and fixing bugs created by other people. If I have your suggested setting ON,..... !!!

[sujayvsarma]

Anyway, I managed to find, isolate and resolve that exception. Turned out they had declared an int variable in normal space and were incrementing it inside a Parallel.ForEach -- without any locks etc. Once that was taken care of [in this case by removing the counter because it wasn't used], the exception was gone.

[sujayvsarma]

I would still like to ask that the logging in the Output/Debug window provide more information than just 'System.AggregateException' in System.Private.CoreLib.dll, because that message provides no help what-so-ever, especially if you don't have a debugger attached.

[Gnbrkm41]

I wonder if that's more of a VS thing? Also I disagree with that because that message also gets printed for handled exceptions as well, which most of the time means you expected that exception to be thrown and it has been handled appropriately (i.e. you don't care about the message/stack trace etc). Logging extra details in that could quickly become overwhelming for what already is found to be okay.

[sujayvsarma]

This is where there is a serious disconnect between what the .NET team thinks people should be doing to diagnose issues or troubleshoot issues and what the people that build tools for debugging/troubleshooting are actually implementing.

@Gnbrkm41 : How exactly would you diagnose this exception if it happened with you and the code lay within a Parallel loop and the exception was being logged on say.. an Azure Service ? There is absolutely NOTHING to tell you (in that blunder of a message) what the exception is or why it happened.

[stephentoub]

I would still like to ask that the logging in the Output/Debug window provide more information

I don't think that logging is being initiated by anything in this repo. You will need to find where it's coming from (try breaking on console writes or something similar) in order to request more detailed output. It's possible it's also something configurable by exposed APIs you're using. You mention you're using ASP.NET, which has a configurable logging system.

[Gnbrkm41]

Those "exception thrown" logs do exist on Console apps without any special handling, so it probably isn't something specific to ASP.NET.

[stephentoub]

Those "exception thrown" logs do exist on Console apps without any special handling

Can you share an example? If an exception goes unhandled enough to print it out, the app is also going to crash, but this discussion suggests the app isn't crashing. Such printing from the runtime also prints the stack trace, and uses a different format.

[Gnbrkm41]

From what I see, it shows Exception thrown: '[Full name of the exception]' in [Assembly file name] for any exceptions thrown, both handled and unhandled; If the exception is unhandled, it also shows An unhandled exception of type '[Full name of the exception]' occurred in [Assembly file name]\r\n[Exception message]

[stephentoub]

This is logged to the output window

Ah, that looks like it's VS' logging for 1st-chance exceptions, meaning it's logging when an exception is thrown even if it's caught and handled.

[stephentoub]

From what I see, it shows

Right, I thought we were talking about console output. This is referring to debugging output from VS.

[Gnbrkm41]

I see. I wasn't quite sure if the runtime had a role in that. Thanks for clarifying.

If that's the case, Visual Studio Developer Community is probably the place to go for suggesting improvements / new features to Visual Studio itself. (In this case requesting more details to be written like stack trace for first-chance exceptions)

[sujayvsarma]

Are you saying that, THAT aggregate exception (& message) is being thrown/shown from Visual Studio and not from the .NET layer?

[sujayvsarma]

If an exception goes unhandled enough to print it out, the app is also going to crash, but this discussion suggests the app isn't crashing. Such printing from the runtime also prints the stack trace, and uses a different format.

The app was not crashing in this case. The code that was causing the exception (an [int] count++; inside a Parallel.ForEach() was simply causing that particular parallel thread to exit -- possibly the AggregateException was wrapping a thread abort or something here.

The problem is, Visual Studio 2019's tooling for debugging parallel threads suck! (its freeze/thaw of threads don't work anymore). So this took quite some doing to unravel.

Anyway, thank you.

[Gnbrkm41]

Are you saying that, THAT aggregate exception (& message) is being thrown/shown from Visual Studio and not from the .NET layer?

No, AggregateException is being thrown from your .NET app, but the one writing that the exception was thrown is Visual Studio.

[stephentoub]

Are you saying that, THAT aggregate exception (& message) is being thrown/shown from Visual Studio and not from the .NET layer?

No, I'm saying something in the app was throwing an AggregateException and VS was logging that it was thrown.

[sujayvsarma]

Ah. I can guarantee that nothing in the app's own code was doing a throw new Exception type of throwing. That entire code block has no exception-throwing (or catching) logic, other than what .NET's own code [or some form of other codegen EXTERNAL to the app] may have been throwing.

PS: If the app was throwing the AggregateException, why on earth would I file this issue to ask you to log more information about it? LOL.

[stephentoub]

I'm not sure what you're trying to argue.

[sujayvsarma]

I'm not sure what you're trying to argue.

Your previous statement "something in the app was throwing an AggregateException". Nothing like that. If something was doing it, it was either in the .NET code base, or caused by a codegen done during compile or something like that. Nothing written by the app's developer(s).

[stephentoub]

Lots of framework methods throw exceptions when they're misused. Such exceptions are the fault of the app code even if they are thrown by the library code (to indicate misuse).

[sujayvsarma]

I feel either you or I are from a different planet. You never seem to get the point am trying to make. I would rather not communicate with you in future.

Thank you for your time.

• Sent from mobile. Pardon typos.