Using Web.Config customErrors for ASP.NET |

CheapASPNETHostingReview.com | Best and cheap ASSP.NET Hosting. The ASP.NET framework provides built-in settings to control how to respond when an application error occurs. This functionality is part of the Web.Config customErrors section.

Configuration Options for Web.Config <customErrors>

Like most web.config settings, customErrors can be configured within the Machine.config, root web.config or your application web.config file. Usually, it is set per application.

CustomErrors supports the following modes:

On – If defaultRedirect is specified, they will see that content. Otherwise the default error screen with fewer details.
Off – Detailed error details will be shown to the user. (the “yellow screen of death screen”)
RemoteOnly – Default value. Detailed errors only are shown to local users. Remote users receive custom error screens or fewer details.

Example configuration:

<configuration>
  <system.web>
    <customErrors defaultRedirect="YourErrorPage.aspx"
                  mode="RemoteOnly">
      <error statusCode="500"
             redirect="InternalErrorPage.aspx"/>
    </customErrors>
  </system.web>
</configuration>

<system.web>

<customErrors defaultRedirect="YourErrorPage.aspx"

mode="RemoteOnly">

<error statusCode="500"

redirect="InternalErrorPage.aspx"/>

</customErrors>

</system.web>

</configuration>

How to View Full ASP.NET Error Details, Disabling Custom Errors

If your application is throwing errors, but you cannot see the full error message, you can disable customErrors.

To do this, you will want to set customErrors mode to “Off” as shown below. Be careful though as this could expose sensitive information shown in error messages as well as detailed stack traces.

<configuration>
  <system.web>
    <customErrors mode="Off"/>
  </system.web>
</configuration>

<system.web>

</system.web>

</configuration>

Other Ways to View ASP.NET Exceptions

There are other ways to track, find, and view application errors besides the ASP.NET yellow screen of death. Ideally, your application should be logging all of your errors to a log file and error monitoring service. You can also check Windows Event Viewer, and you may be able to see your exceptions. Although, be warned that exceptions are rate limited to Event Viewer and it does not record all of them.

How to Log All Application Errors

Depending on your type of application, there are potentially multiple ways to do this. If your application has a Global.asax file, you can subscribe to unhandled exceptions as shown below:

public class WebApiApplication : System.Web.HttpApplication
{
	log4net.ILog log = log4net.LogManager.GetLogger(typeof(WebApiApplication));

	public override void Init()
	{
		base.Init();
		this.Error += WebApiApplication_Error;  
	}

	void WebApiApplication_Error(object sender, EventArgs e)
	{
		var ex = Server.GetLastError();		
		log.Error(ex);            
	}
}

public class WebApiApplication : System.Web.HttpApplication

{

log4net.ILog log = log4net.LogManager.GetLogger(typeof(WebApiApplication));

public override void Init()

{

base.Init();

this.Error += WebApiApplication_Error;

}

void WebApiApplication_Error(object sender, EventArgs e)

{

var ex = Server.GetLastError();

log.Error(ex);

}

How to View All Application Exceptions With Retrace

Retrace provides code-level performance monitoring for your application. Part of that includes collecting all application exceptions. Retrace can collect unhandled exceptions, exceptions explicitly logged to it, or every single exception ever is thrown (first chance exceptions).

To make the most of your application errors, you should use an error monitoring service, like Retrace. Benefits of an error monitoring service:

Real-time alerts – know immediately when a new error happens
Centralized repository – one place your team can access everything
Error rates – quickly identify large spikes in error rates
Improve productivity – find root cause of problems much faster