Azure-docs: Tracking of handled exceptions in ASP.NET Core

[breyed]

This page discusses setting up handled exception tracking in just about every scenario except ASP.NET Core. For ASP.NET Core, how do you cause Application Insights to track handled exceptions or (if you're doing explicit tracking) to not track handled exceptions?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: a23bc2a8-afa6-5269-ed97-cb6a52cfbb5a
• Version Independent ID: 374c5fac-a1a0-8d65-5a68-bd338bea7937
• Content: Diagnose failures and exceptions in web apps with Azure Application Insights
• Content Source: articles/azure-monitor/app/asp-net-exceptions.md
• Service: application-insights
• GitHub Login: @mrbullwinkle
• Microsoft Alias: mbullwin

[kobulloc-MSFT]

@breyed Thank you for the feedback! We are investigating this and will get back to you shortly.

[kobulloc-MSFT]

@breyed You can use the C# example to report exceptions explicitly:

https://docs.microsoft.com/en-us/azure/azure-monitor/app/asp-net-exceptions#reporting-exceptions-explicitly

In my example here, I've created an ASP.NET Core web application, and used the following code in my Index.cshtml.cs file:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.RazorPages;
using Microsoft.ApplicationInsights;

namespace kobulloc_Docs_AppIns_NETCore.Pages
{
    public class IndexModel : PageModel
    {
        public void OnGet()
        {
            var telemetry = new TelemetryClient();
            int number1 = 5;
            int number2 = 0;

            try
            {
                Console.WriteLine(number1 / number2);
            }
            catch (DivideByZeroException testException)
            {
                var properties = new Dictionary<string, string>
                { {"Game", "Robotron"}};

                var measurements = new Dictionary<string, double>
                { {"Users", 42.00}};

                telemetry.TrackException(testException, properties, measurements);
            }
        }
    }
}

After publishing, I see the following in the Custom Properties and Custom Measurements of my End-to-end transactions (Failures). As you can see, both the game and number of users are shown with the exception:

I believe this answers your question so we are going to close this issue as resolved but if you have any more questions about the documentation, please tag me in your reply and we will be happy to continue the conversation.

[breyed]

This makes explicit reporting clear, but implicit reporting is still confusing. The MVC section talks about unhandled exceptions in MVC 5+. Does MVC 5+ include .NET Core? What about exceptions handled by middleware to show an exception handler page?

For a ASP.NET Core site that I maintain, I see handled exceptions in Application Insights if a 500 error results. However, I also see the handled exception for a 200 OK if HttpClient request fails but is successfully retired via the Polly library. We want to be notified promptly for the first type of exception, but the second is just a metric to monitor. Having clear documentation about how the SDK implicitly reports handled exceptions would make it easier to find a way to identify the most important exceptions.

[kobulloc-MSFT]

@breyed Availability and Metric alerts would be useful in the scenario that you are describing.

As far as the documentation issues are concerned, I'm going to assign this to the document author so they can update the documentation accordingly.

[cijothomas]

@breyed @kobulloc-MSFT The correct way to track any additional telemetry is as per this doc (FAQ 1):
https://docs.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core-no-visualstudio#frequently-asked-questions
The main difference is, for asp.net core apps - Don't create new TelemetryClient(). Always get it from DI.

@breyed The latest beta version of the SDK enabled automatic capture of Warning or above ILogger based logs. If an exception is passed to ILogger.Log, then Application Insights will report it as an exception. Since all of the asp.net core components send iLogger logs, this essentially means you'll see application insights exceptions for every unhandled exceptions. This is true even if you use exception handler page as per this page: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/error-handling

If you want, you can disable/fine tune the logs using instructions from this link.
https://docs.microsoft.com/en-us/azure/azure-monitor/app/ilogger#control-logging-level

Let us know if this helps.

@mrbullwinkle Lets add a section to the exception handling doc about asp.net core. We can sync offline about the content.

The asp.net core doc also should add a section about 'Exception handling'.
https://docs.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core-no-visualstudio

[breyed]

@cijothomas To clarify, by "unhandled exception", you mean an exception handled by the server, correct?

To further clarify, here are the main 4 scenarios for exception handling and their behavior as I understand it:

• Handled by app: No reporting. (Though somehow they are reported if the app uses Polly to handle and retry - still unexplained.)
• Handled by server: Passed to ILogger and then reported by App Insights.
• Handled by TPL: Ignored as an unobserved exception. Not reported by App Insights.
• Unhandled: Reported directly by App Insights.

It would be helpful to clearly document these scenarios and App Insight's behavior. Also, I think that reporting unobserved exceptions by default would be a good thing.

[cijothomas]

@breyed Yes i meant those handled by the server.
Unobserved exceptions are tracked in Asp.Net. Not yet for Asp.Net Core.

Will make sure docs cover these.

[kobulloc-MSFT]

@breyed We are going to close this thread as resolved but if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.

[breyed]

Don't you normally keep issues open until they are closed with a corresponding commit or PR?

[mrbullwinkle]

@kobulloc-MSFT do you mind reopening this one? @breyed apologies for the confusion we had a massive PR updating this doc that was in review when your question came in, we didn't want to hold up the PR so the updated version of the doc was pushed live, but the latest version does not have the changes you requested. Those will be coming soon. We can definitely leave this open as a doc enhancement until we have addressed it.

[esbenbach]

Any updates on this - its still seems lacking in the breyed pointed out.

[cijothomas]

Agree this is important and missing.

The easy workaround is to use ilogger to log exceptions, and apply filtering to control which ones are required to be tracked. Its not ideal, but that should help most customers.

[audunsolemdal]

A bit confused - could someone help me clear this up

Azure diagnostic logs in blob storage (via ILogger), throws exceptions and logs some of my app's operations as "Error". A Failed request is registered in app insights, yet no exception is recorded.

Usign telemetry.Trackexception(ex) explicitly works.

Am I understanding correctly that this is by design to not log "known" exceptions as exceptions..? If someone could provide reproducable code, throwing exceptions and doesn't use telemetry.Trackexception(ex) I'd be grateful.