By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

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?

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.

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

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.

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]

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.

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.

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.

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.