Using ELMAH in Windows Azure Web Sites

It’s pretty easy to track down an exception in an on-premise ASP.NET application. Just run the application under a debugger and examine the exception when the debugger breaks into your code. It can get quite a bit trickier when your application is running in Windows Azure Web Sites because you don’t have access to the server. In other words, you can attach a debugger like Visual Studio and find out what’s going on.

In many cases you can use Detailed Error Pages, Failed Request Tracing, and the events.xml file that is located in the LogFiles folder to track down an exception, but not always. I was recently working with a customer who had deployed an MVC application to Windows Azure Web Sites. The site worked fine locally, but once he deployed it to Azure, he started seeing this.

There obviously appears to be an exception going on in the code. Naturally my first idea was to enable Detailed Error Pages and FTP into the LogFiles folder to find out what was going on, and that’s exactly what I did. However, all we were able to determine from that is that a “500 – Internal Server Error” had occurred and it was in the System.Web.Mvc.MvcHandler. That really didn’t tell me anything I didn’t know already. Another approach was needed, so we configured ELMAH and it gave us just what we needed.

What is ELMAH?

I’ve often seen ELMAH described as an exception logging module. While that’s true, it’s a bit like calling a Harley a bicycle. ELMAH is a complete exception handling solution for ASP.NET developers, and it has some extraordinary capabilities. Scott Hanselman does a good job of outlining what ELMAH can do in his blog post on it. In my situation, I used ELMAH to find out the exception (and all inner exceptions) that was blowing up my customer’s MVC application.

Configuring ELMAH

If you’re using Visual Studio, adding ELMAH to your project couldn’t be easier. The NuGet Package Manager will install everything for you. You’ll just need to add one entry to make it all work in Windows Azure Web Sites. (Technically, you may want to add a few more configuration settings, but we’ll get into that more later on.)

After opening your project in Visual Studio, right-click on your ASP.NET project and select Manage NuGet Packages.

This will launch the Manage NuGet Packages dialog. If you’ve never used NuGet before, you’re in for a treat! There’s a ton of great stuff offered here, but we’re interested only in ELMAH right now, so I did a search for ELMAH in NuGet. Here’s what it turned up.

For my application, I need ELMAH (the first entry) and Elmah.Mvc. Installing those into my application is simple; I just click on each one and click Install. Within a few seconds, the package is installed into my app and I’m ready to make a minor change to get things working with Windows Azure Web Sites.

Setting Up for Remote Access

By default, exceptions that are handled by ELMAH are stored in-memory and are visible using the elmah.axd handler. Let’s just go with that for now. ELMAH will block access to elmah.axd if I browse to it remotely. I can fix that by changing the allowRemoteAccess setting to true. Installing the ELMAH package adds this setting to the bottom of the web.config file in the <elmah> section, but it will currently be set to false. After changing it, it looks like this:

 <security allowRemoteAccess="true" />
  

I can deploy my application to Windows Azure Web sites at this point and ELMAH will handle the exception and let me easily get details on it using the elmah.axd handler.

(Thanks to reader, James, for recommending a change to this section to make ELMAH more secure by default.)

The Final Result

After reproducing the error, I then browse to elmah.axd. What I see after doing that is this.

Now we’re getting somewhere, but wait! There’s more. If you click on Details, you can get a ton of information about your exception. You’ll see that not only do I get a full stack trace, but I also get a lot of information about the request that caused the exception, including all of my HTTP headers and more. Pretty cool stuff!

Don’t Stop Here

You can do much more with ELMAH than I’ve shown you here, so I encourage you to play around with it. Hopefully this will help you track down some of those hard to deal with exceptions that you might be seeing in your code.

Comments

• Anonymous
  October 06, 2013
  Hi there! Thanks for the write up! However, you would be much better off installing the ELMAH package instead of ELMAH.Core Library. This package gets you up and running quicker, and makes sure that you are secure. I know you've put your word of warning in there, but they often get ignored. See here for why this can be dangerous: www.troyhunt.com/.../aspnet-session-hijacking-with-google.html Regards, James

• Anonymous
  October 06, 2013
  Thanks, James! I appreciate the pointer. I have updated the post appropriately.

• Anonymous
  November 27, 2013
  It's still not even close to secure. You should link directly to www.troyhunt.com/.../aspnet-session-hijacking-with-google.html Also, this article has very little to do with Azure, you've just explained how to use Elmah on a remote server.

• Anonymous
  June 15, 2014
  Well, one thing is not clear to me.  Suppose your app runs in two or more worker roles behind a load balancer, ELMAH will be writing data into xml files spread across multiple instances.  Now you will need to remotely connect to multiple instances manually to check exception messages (some here some there).  ELMAH would be pretty much useless without having a way to connect the output to Azure Blobs so that ELMAH output from different instances can be collected at one place.