Exception Logging

For new web applications, ELMAH is the first package I recommend that developers install. When NuGet was first released, every NuGet talk I gave (and nearly every other presentation about NuGet) had a demonstration that installed the ELMAH package. ELMAH is an acronym for Error Logging Module and Handler. It logs all unhandled exceptions in your application and saves them. It also provides a UI to list the errors in the log and display them in a nice format, maintaining the details you would see in the dreaded Yellow Screen of Death.

To keep things simple, most demos of ELMAH show installing the main elmah package. This package contains a bit of configuration to make ELMAH work using an in-memory database and depends on the elhmah.corelibrary package.

This works great for a demo, but it doesn't work for a real site since the exception log is stored in memory, which doesn't persist if the application is restarted. Fortunately, ELMAH includes packages for most of the major database vendors as well as one that stores items in XML files.

Since the NuGet Gallery uses SQL Server as its database, we installed the elmah.sqlserver package. This package requires a bit of manual configuration. When you install this package into your own project, it adds a script named Elmah.SqlServer.sql in the App_Readme folder of the target project. You'll need to run that script against your SQL Server database in order to create the tables and stored procedures that ELMAH needs.

In the case of NuGet Gallery, we've long since deleted that folder, so you'll find the script in the packageselmah.sqlserver.1.2contentApp_Readme directory relative to the solution root.

By default, ELMAH is only accessible from the local host. This is an important security precaution because anyone who has access to your ELMAH logs can effectively hijack the session for any of your users. See the following blog post for details: www.troyhunt.com/2012/01/aspnet-session-hijacking-with-google.html.

Accessing the exception log remotely is probably one of the reasons you wanted ELMAH in the first place! Not to worry — it just requires a simple bit of configuration. First, secure access to elmah.axd to the users or roles that should have access.

The web.config for NuGet Gallery has an example of this. We restricted access to users who are members of the Admins role.

<location path="elmah.axd">
  <system.web>
    <httpHandlers>
      <add verb="POST,GET,HEAD" path="elmah.axd" 
        type="Elmah.ErrorLogPageFactory, Elmah" />
    </httpHandlers>
    <authorization>
      <allow roles="Admins" />
      <deny users="*" />
    </authorization>
  </system.web>
  <system.webServer>
    <handlers>
      <add name="Elmah" path="elmah.axd" verb="POST,GET,HEAD"
        type="Elmah.ErrorLogPageFactory, Elmah" preCondition="integratedMode" />
    </handlers>
  </system.webServer>
</location>

Once you've properly secured access to elmah.axd, change the security element's allowRemoteAccess attribute to true to enable remote access.

<security allowRemoteAccess="true">

Now you can visit /elmah.axd in your site to see logged unhandled exceptions. If you still can't access elmah.axd, make sure you added your user to the Admins role using the Dynamic Data database admin UI, as described in the previous section.