EPiServer Error Handling (broken in R2 & IIS7)

As you might have noticed EPiServer has its own Error Handling that has the following features.

  • It shows a localized error message.
  • It can hide the Exception details and stack trace – if you do not have the permission needed
  • It can send an email with a message from the user and also include the exception details and call stack in the mail

GlobalErrorHandling setting works like customErrors mode

You control EPiServer Error Handling with three settings in web.config.

Off Let ASP.NET handle the error as specified by <customErrors mode="">
RemoteOnly Show EPiServer Error handler for remote access but use ASP.NET default behavior for local calls. Combine this setting with <customErrors mode="RemoteOnly">
On Always show

Make sure <system.net><mailSettings> is setup for sending mail and then just set globalErrorMail to an email address and EPiServer will start sending nice error reports to you.

Optionally set ErrorMailHandler if you want to replace the default sending of the mail in "~/Util/SendErrorReport.aspx". This can be useful if you want to add extra processing to prevent noise (many message for same error) or log to a database instead.

NOTE: GlobalErrorHandling in EPiServer CMS 5 R2 (No SP)

The behavior of GlobalErrorHandling setting is broken in EPiServer CMS 5 R2 because some refactoring to optimize the code accidently inverted it.

Workaround: Set it to Off in R2! (Will be fixed in R2 SP1)

IIS7 and Error Handling – new property TrySkipIisCustomErrors

As you might have noticed custom error handling works differently in IIS7. There is a new tag system.webserver/httpErrors in your applicationHost.config or web.config.

ASP.NET hands over control to IIS if the status code is over 400 and both the standard APS.NET yellow screen of death or a custom error page you generated in code can be replaced later in the pipeline with IIS7 custom errors.

The new property Response.TrySkipIisCustomErrors must be set to true if you want your content to be shown after you change Response.StatusCode. ASP.NET does this for its yellow screen of death in compatibility mode. You also need the existingResponse-attribute to be set to auto.

Workaround: Set existingResponse-attribute to PassThrough.