lowleveldesign.org

In this post I’m going to show you the way ASP.NET (MVC) handles exceptions that occur in web applications. We will also examine different places where we can hook our own loggers. Our application will be a very basic ASP.NET MVC project with one controller and one view:

using System;
using System.Web;
using System.Web.Mvc;

[HandleError]
public class HomeController : Controller
{
    //
    // GET: /Home/
    public ActionResult Index()
    {
        return View();
    }
    
    public ActionResult Exception() {
        throw new Exception("test exception");
    }
}

@{
    ViewBag.Title = "test title";
}

<h2>Index page</h2>

<a href="@Url.Action("Exception")">throw exception</a>

Let’s attach windbg to the IIS Express server hosting our sample application, configure it to stop on all first chance CLR exceptions and break when HandleError filter is called:

0:030> sxe clr
0:027> !Name2EE System.Web.Mvc.dll System.Web.Mvc.HandleErrorAttribute.OnException
Module:      645c1000
Assembly:    System.Web.Mvc.dll
Token:       060009a3
MethodDesc:  645f13d4
Name:        System.Web.Mvc.HandleErrorAttribute.OnException(System.Web.Mvc.ExceptionContext)
JITTED Code Address: 646c94e4
0:027> bp 646c94e4
*** WARNING: Unable to verify checksum for C:\Windows\assembly\NativeImages_v4.0.30319_32\System.Web.Mvc\1a2d7693f4ae1edffeb277679caefefe\System.Web.Mvc.ni.dll

ASP.NET MVC (HandleError)

After clicking the throw exception link windbg should notify us of the exception that was thrown. We may verify that it’s our exception and press go. We should now stop at our breakpoint. A quick look at the stack and we can find that the HandleError filter is called by ControllerActionInvoker:

0:027> !pe
Exception object: 03e03a68
Exception type:   System.Exception
Message:          test exception
InnerException:   <none>
StackTrace (generated):
<none>
StackTraceString: <none>
HResult: 80131500
0:027> g
Breakpoint 0 hit
0:027> !DumpStack
OS Thread Id: 0x16b0 (27)
Current frame: (MethodDesc 645f13d4 +0 System.Web.Mvc.HandleErrorAttribute.OnException(System.Web.Mvc.ExceptionContext))
ChildEBP RetAddr  Caller, Callee
1058ec68 646ab72e (MethodDesc 645eb840 +0x6e System.Web.Mvc.ControllerActionInvoker.InvokeExceptionFilters(System.Web.Mvc.ControllerContext, System.Collections.Generic.IList`1<System.Web.Mvc.IExceptionFilter>, System.Exception)), calling clr!VSD_FixupAsmStub
1058ec94 646aae06 (MethodDesc 645eb7e8 +0x13a System.Web.Mvc.ControllerActionInvoker.InvokeAction(System.Web.Mvc.ControllerContext, System.String))
1058ecc0 646aac1c (MethodDesc 645eb7f8 +0xb4 System.Web.Mvc.ControllerActionInvoker.InvokeActionMethodFilter(System.Web.Mvc.IActionFilter, System.Web.Mvc.ActionExecutingContext, System.Func`1<System.Web.Mvc.ActionExecutedContext>)), calling clr!IL_Rethrow
1058ed84 646ab3b5 (MethodDesc 645eb744 +0x61 System.Web.Mvc.ControllerActionInvoker..ctor()), calling clr!JIT_WriteBarrierEAX
1058ed98 646b10ab (MethodDesc 645ecb44 +0x6b System.Web.Mvc.Controller.ExecuteCore()), calling 03859182
1058edc0 646ab9fc (MethodDesc 645eb97c +0x5c System.Web.Mvc.ControllerBase.Execute(System.Web.Routing.RequestContext))
1058ede8 646abc6b (MethodDesc 645eb9b0 +0xb System.Web.Mvc.ControllerBase.System.Web.Mvc.IController.Execute(System.Web.Routing.RequestContext))
...

As we can read from the stack trace, InvokeExceptionFilter is called from the InvokeAction method. Here is the decompiled code to check how the handling is defined:

FilterInfo filters = this.GetFilters(controllerContext, actionDescriptor);
try
{
  AuthorizationContext authorizationContext = this.InvokeAuthorizationFilters(controllerContext, filters.AuthorizationFilters, actionDescriptor);
  if (authorizationContext.Result != null)
  {
    this.InvokeActionResult(controllerContext, authorizationContext.Result);
  }
  else
  {
    if (controllerContext.Controller.ValidateRequest)
    {
      ControllerActionInvoker.ValidateRequest(controllerContext);
    }
    IDictionary parameterValues = this.GetParameterValues(controllerContext, actionDescriptor);
    ActionExecutedContext actionExecutedContext = this.InvokeActionMethodWithFilters(controllerContext, filters.ActionFilters, actionDescriptor, parameterValues);
    this.InvokeActionResultWithFilters(controllerContext, filters.ResultFilters, actionExecutedContext.Result);
  }
}
catch (ThreadAbortException)
{
  throw;
}
catch (Exception exception)
{
  ExceptionContext exceptionContext = this.InvokeExceptionFilters(controllerContext, filters.ExceptionFilters, exception);
  if (!exceptionContext.ExceptionHandled)
  {
    throw;
  }
  this.InvokeActionResult(controllerContext, exceptionContext.Result);
}
return true;

The default HandleErrorAttribute swallows exceptions inherit from the exception type specified in its constructor (by default it’s System.Exception so all exceptions are included). After setting the exceptionContext.ExceptionHandled to true, the ControllerActionInvoker happily continues using ActionResult provided by the HandleErrorAttribute (by default it’s an action of rendering the Error.cshtml view). This also means that no other ASP.NET components are notified about the problem that occured. You may ask what other components am I talking about? We can find out by examining the stack. .NET exception handling is based on SEH (Structure Exception Handling). I won’t go too deep into this matter as it’s quite complicated and differs among architectures (x64, x86), but what’s important for us is that by checking the stack from top to bottom we are able to identify all exception handles (catch blocks) waiting for exceptions that happen “above them”. Imagine that our HandleErrorAttribute hasn’t caught the exception. In that case the framework starts looking for another catch block which will be able to handle the exception. We can emulate this behavior using !EHInfo command from the SOS extension on all method descriptors found in the stack trace presented at the beginning of this post (I “dotted” methods that do not have any catch clauses defined):

0:027> !EHInfo 645eb7e8
MethodDesc:   645eb7e8
Method Name:  System.Web.Mvc.ControllerActionInvoker.InvokeAction(System.Web.Mvc.ControllerContext, System.String)
Class:        645dd248
MethodTable:  646f1b1c
mdToken:      06000269
Module:       645c1000
IsJitted:     yes
CodeAddr:     646aaccc
Transparency: Transparent

EHHandler 0: TYPED 
Clause:  [646aad4b, 646aadeb] [7f, 11f]
Handler: [646aadeb, 646aadf0] [11f, 124]

EHHandler 1: TYPED 
Clause:  [646aad4b, 646aadeb] [7f, 11f]
Handler: [646aadf0, 646aae44] [124, 178]
...
0:027> !EHInfo 6511b544
MethodDesc:   6511b544
Method Name:  System.Web.HttpApplication+CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
Class:        65102264
MethodTable:  6533f124
mdToken:      06002441
Module:       650e1000
IsJitted:     yes
CodeAddr:     652bdc10
Transparency: Safe critical

EHHandler 0: TYPED 
Clause:  [652bde25, 652bde3f] [215, 22f]
Handler: [652bdd07, 652bdd3e] [f7, 12e]

EHHandler 1: FINALLY 
Clause:  [652bde3f, 652bde74] [22f, 264]
Handler: [652bdd3e, 652bdd5c] [12e, 14c]

EHHandler 2: FINALLY 
Clause:  [652bdd5c, 652bdd7b] [14c, 16b]
Handler: [652bdd7b, 652bde14] [16b, 204]
...
0:027> !EHInfo 65113f2c
MethodDesc:   65113f2c
Method Name:  System.Web.HttpApplication.ExecuteStep(IExecutionStep, Boolean ByRef)
Class:        65100b00
MethodTable:  6533721c
mdToken:      060023e0
Module:       650e1000
IsJitted:     yes
CodeAddr:     65298a50
Transparency: Safe critical

EHHandler 0: FINALLY 
Clause:  [65298a8d, 65298aab] [3d, 5b]
Handler: [65298aab, 65298acb] [5b, 7b]

EHHandler 1: TYPED 
Clause:  [65298a73, 65298b08] [23, b8]
Handler: [65298b08, 65298b8e] [b8, 13e]

EHHandler 2: TYPED 
Clause:  [65298a73, 65298b08] [23, b8]
Handler: [65298b8e, 65298b98] [13e, 148]

EHHandler 3: TYPED 
Clause:  [65298a73, 65298b98] [23, 148]
Handler: [65298b98, 65298c39] [148, 1e9]
... 
0:027> !EHInfo 6510de78
MethodDesc:   6510de78
Method Name:  System.Web.HttpRuntime.ProcessRequestNotificationPrivate(System.Web.Hosting.IIS7WorkerRequest, System.Web.HttpContext)
Class:        650ff9d8
MethodTable:  6533220c
mdToken:      0600294b
Module:       650e1000
IsJitted:     yes
CodeAddr:     65294d70
Transparency: Safe critical

EHHandler 0: TYPED 
Clause:  [65294e45, 65294e52] [d5, e2]
Handler: [65294e52, 65294e74] [e2, 104]

EHHandler 1: TYPED 
Clause:  [65294d95, 65294f9d] [25, 22d]
Handler: [65294f9d, 65294ff5] [22d, 285]
...
0:027> !EHInfo 6510fac8
MethodDesc:   6510fac8
Method Name:  System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr, IntPtr, IntPtr, Int32)
Class:        650e15d0
MethodTable:  65332ca8
mdToken:      06002169
Module:       650e1000
IsJitted:     yes
CodeAddr:     6529aaa0
Transparency: Safe critical

EHHandler 0: TYPED 
Clause:  [6529aab4, 6529aac1] [14, 21]
Handler: [6529aac1, 6529aad8] [21, 38]

ASP.NET (http modules, customerrors)

We’ve already checked the first method from the above list. Now it’s time for: System.Web.HttpApplication+CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute(). This method posts a request to the handler and rethrows the exception if any occurs. Next on the list is System.Web.HttpApplication.ExecuteStep(IExecutionStep, Boolean ByRef). After decompiling we can see that it handles any exception gracefully, sending it as a result to the caller:

internal Exception ExecuteStep(HttpApplication.IExecutionStep step, ref bool completedSynchronously)
{
    Exception result = null;
  ...
  try
  {
    ...
    step.Execute();
    ...
  }
  catch (Exception ex)
  {
    result = ex;
    ...
  }
  catch
  {
  }
  ....
  return result;
}

Now, the caller which happens to be System.Web.HttpApplication+PipelineStepManager.ResumeSteps(System.Exception)

internal override void ResumeSteps(Exception error)
{
  ...
  while (true)
  {
    if (syncContext.Error != null)
    {
      error = syncContext.Error;
      syncContext.ClearError();
    }
    if (error != null)
    {
      this._application.RecordError(error);
      error = null;
    }
    if (!this._validateInputCalled || !this._validatePathCalled)
    {
      error = this.ValidateHelper(context);
      if (error != null)
      {
        continue;
      }
    }
    if (syncContext.PendingCompletion(this._resumeStepsWaitCallback))
    {
      break;
    }
    ...
    error = this._application.ExecuteStep(nextEvent, ref flag4);
    ...
  }
  ...
}

checks if an error occured while processing the request (any of the executed steps returns something different than null). If so, the PipelineStepManager records it and notifies all error event handlers (this._application.RecordError(error)), including http modules which subscribed to this type of events (httpContext.Error += new EventHandler(httpModule_Error)). If event handlers do not clear the error information in Http context (httpContext.Server.ClearError()), the error will be eventually handled by HttpRuntime (more exactly System.Web.HttpContext.ReportRuntimeErrorIfExists(System.Web.RequestNotificationStatus ByRef)). HttpRuntime creates an ASP.NET Health Monitoring event (by default it logs the exception to the Application event log) and prepares a Yellow Screen Of Death, taking into consideration customErrors settings from the web.config file.

I hope after having read this post you have a better understanding of the exception flow in ASP.NET and, next time if Elmah does not report any exceptions in ASP.NET MVC application you will know where to look for the fault 🙂