In my last post, I commented on how ASP.NET health monitoring doesn't output stack traces for inner exceptions, which can be problematic due to its heavy reliance on reflection. I spent the morning doing some further spelunking with reflector, and my first solution was to implement a custom WebEvent that overrides ToString() to format itself with all of the data I care about. I then overrode the Error event via global.asax and raised my custom event, instead of letting ASP.NET raise its default event. This worked reasonably well with the SimpleMailWebEventProvider, but didn't seem to change anything at all with the event log provider.

What I found is that the two providers were using entirely different means to format the events! The email provider calls ToString(bool, bool) on the event to ask it to format itself. But the EventLogWebEventProvider does its own formatting of individual fields of the event. Indeed, its ProcessEvent method has a big list of checks:

if (eventRaised is WebBaseErrorEvent)
    AddErrorStuff();
if (eventRaised is WebAuthenticationSuccessAuditEvent)
    AddLogonStuff();

So it seemed like a better approach would be to write my own provider. I left the event log provider alone, and I wrote a custom email provider to display errors in a more useful way. This also allowed me to drop some fields from the event report that aren't useful for us. And I was able to construct a much more concise and useful subject line (the subject line that SimpleMailWebEventProvider uses is rather clunky since it assumes it might be spitting out a whole bunch of buffered events in one go).

Not only does my provider include the stack traces for all of the exceptions in the chain, but in the subject line, I display the type of error that is at the root of the problem. So if I am formatting a TargetInvocationException, I drill into its InnerException chain until I find a different exception type, and display that exception type instead.

Oh, one other benefit of building the custom provider instead of using a custom WebEvent was that I was then able to remove the Error handler from global.asax. All I had to do was replace the SimpleMailWebEventProvider with my own provider, and I got the behavior I wanted. Now my email notifications include detailed stack traces.

I'll post the code for this provider once it's run for a little while in production and I'm satisfied that it works reasonably well.