The customErrors element of the web.config file is the last line of defense against an unhandled error. If you have other error handlers in place, like the Application_Error of Page_Error subs, these will get called first. Provided they don't do a Response.Redirect or a Server.ClearError, you should be brought to the page(s) defined in the web.config. In the web.config file, you can handle specific error codes (500, 404, etc), or you can use one page to handle all errors. This is a major difference between this method and the others (although you can emulate this by doing various Response.Redirects using the other methods). Open up your web.config file. The customErrors section uses this format:

<customErrors defaultRedirect="url" mode="On|Off|RemoteOnly">
   <error statusCode="statuscode" redirect="url"/>
</customErrors>

Here is some important information about the "mode" attribute:

"On" specifies that custom errors are enabled. If no defaultRedirect is specified, users see a generic error.

"Off" specifies that custom errors are disabled. This allows display of detailed errors.

"RemoteOnly" specifies that custom errors are shown only to remote clients, and ASP.NET errors are shown to the local host. This is the default.

By default, the section looks like this when you create a Web application.

<customErrors mode="RemoteOnly" />

This will show a generic page to users. To redirect it to one of your own pages, you would change it to this:

<customErrors mode="On" defaultRedirect="error.aspx" />

Now all errors that occur will be brought to the error.aspx page. 

To handle specific errors, and redirect to the error page for everything else you can specify the error code you want specially handled like so:

<customErrors mode="On" defaultRedirect="error.aspx">
    <error statusCode="500" redirect="error500.aspx?code=500"/>
    <error statusCode="404" redirect="filenotfound.aspx"/>
    <error statusCode="403" redirect="authorizationfailed.aspx"/>
</customErrors> 

There is a problem here with this solution. Once the redirect is done, your error information is no longer available on the redirected page. This is because IIS (via the .net framework) performs a plain old GET request to the error page and does not do a "Server.Transfer" like the built-in IIS error handling does.

The only information available to you at this time is the URL that caused this error to be raised. This is located on the querystring as "aspxerrorpath": http://localhost/ErrorHandling/error500.aspx?aspxerrorpath=/ErrorHandling/WebForm1.aspx. The only places this information is available is the two methods described above.

Another important part of all deployments.