1

I have just installed Application insights into my .Net MVC web application. In the Web.config file it made several changes, one of which is

<httpModules>
...
<add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Web.ApplicationInsightsHttpModule, Microsoft.AI.Web" />
</httpModules>

Which seems fine to me. The problem is when the application throws an error we have custom page errors enable and normally the filterContext.ExceptionHandled = FALSE. However with this httpModules installed I am seeing it change to filterContext.ExceptionHandled = TRUE.

We utilise custom page errors via :

protected virtual void RegisterGlobalFilters(GlobalFilterCollection filters)
{
   filters.Add(new HandleErrorAttribute(), -10);
}


public class HandleErrorAttribute : FilterAttribute, IExceptionFilter
{
    public void OnException(ExceptionContext filterContext)
    {
        if (filterContext.ExceptionHandled)
            return;
    }
}

Can anyone give me a reason why Application insight may be changing the ExceptionHandled status?

Jaie
  • 89
  • 1
  • 9
  • So I debugged the issue a little further and can determine that Application Insights automatically adds the global filter "Microsoft.ApplicationInsights.ExceptionTracking.MvcExceptionFilter" when you add this module and this filter has order -1 which means it gets hit before my HandleErrorAttribute. What I'm still not sure about is why Application Inisghts is handling my error and how this could be configured so that the filter did not do this. – Jaie Jul 24 '18 at 03:23

2 Answers2

1

Looks like i was not the only person with this issue, which seems to be reports and being addressed by Microsoft here: https://github.com/Microsoft/ApplicationInsights-dotnet-server/issues/921

Jaie
  • 89
  • 1
  • 9
0

When an exception occurs, the order of the global filters executes in reverse order. This means that HandleErrorAttribute runs first.

As it's the first filter, then ExceptionHandled is false when it executes, causing it to set the view to Error and setting ExceptionHandled to true. So, then, when your own filter executes, that is why ExceptionHandled is already set to true.

Note that if custom errors were disabled, then ExceptionHandled would still be false, as HandleErrorAttribute wouldn't have done its stuff. In this case, ELMAH will log the error anyway, as it's unhandled, so the test in your class is to prevent duplicate logging of the error.

For more details, you could refer to this SO thread.

Joey Cai
  • 18,968
  • 1
  • 20
  • 30
  • Not sure that this is right for my scenario. When I comment out the Web.config line, the exception handled status is false, when I uncomment it the exception handled status is true. Also I forgot to include the order part we add the filter with order -10 – Jaie Jul 24 '18 at 02:34