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

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.

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,..... !!!

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.

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.

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)