When you are creating ASP or ASP.NET pages, it's likely you have seen an error like the following when you requested a page in your browser:


Figure 1 - An HTTP 500 Error as Displayed in Internet Explorer with Friendly Errors Turned On

It's also possible to get error messages like this one:


Figure 2 - An Error Message You May See when Detailed Error Messages is Disabled in IIS

I think you'll agree with me that these error messages are not very descriptive. All they tell you is that something went wrong, but it is impossible to find out what went wrong.

Good Morning, I am your Friendly HTTP Error Message for the Day

The error message from the first screen shot is what the designers of Internet Explorer call a “Friendly HTTP Error Message”. For the majority of users, this is true. This error message tells them that something went wrong, and it offers them a link back to the homepage of the site. There is no need to bother ordinary visitors with technical gobbledygook.
But for you as a developer, this message is useless. Fortunately, it's easy to get more detailed information about the error: simply turn off the Friendly HTTP Error Message feature.

To turn that feature off, open the Internet Options dialog (choose Tools | Internet Options... in Internet Explorer) and switch to the Advanced tab. You'll find the Show friendly HTTP error messages setting under the Browsing category. Make sure the item is unchecked.


Figure 3 - The Advanced Tab of the Internet Explorer Options Dialog

With the option turned off, you'll get a much more descriptive error message instead, like the next one, for example:


Figure 4 - The Full Error Message is Much More Useful.

From this error message, it's easy to see what went wrong; apparently, I forgot to create or upload the include file Adovbs.inc.

If you still don't see a detailed error message with the option in Internet Explorer turned off, but get an error like the one on the second screen shot instead, you should make changes to IIS as well. IIS offers you the option to either send detailed error messages to the client or to send a short custom message instead in case of an error. On a development server, the detailed error message is what you are really interested in. But on a production server, you don't want to send this information to the client; all you want to tell your visitor is that something went wrong. To make the change in IIS, follow these steps:

1. Start the Internet Information Services management console, which you'll find the under Administrative Tools which in turn you'll find either directly on the Start Menu, or in the Windows Control Panel.
   
   
   Figure 5 - The IIS Management Console
   
   
2. Expand the tree in the left hand pane until you see Default Web Site. If you're configuring another Web site, or a Virtual Directory / Application, locate that one instead. This article assumes you're configuring the Default Web Site, so make sure you adjust any steps to match your situation if necessary.
   
   
3. Right-click the Default Web Site in the tree at the left and choose Properties.
   
   
4. Open the Home Directory tab (or Directory tab in case of a Virtual Directory) then click the Configuration button.
   
   
5. On the Application Configuration dialog, switch to the Debugging tab and you'll see the following screen appear:
   
   
   Figure 6 - The Application Configuration Dialog with Detailed ASP Error Messages Turned On
   
   
6. On your development machine, make sure that Send detailed ASP error messages to client is turned on. As soon as you put your site in production, switch to the other option and, if you prefer, provide a custom error message.

With both these options set to provide detailed error messages, debugging your ASP pages is now a lot easier. Instead of a general "Ooops, we screwed up" message, you are now able to see the cause of the error, so it's much easier to fix your problem.

Just don't forget to change the setting in IIS to Send text error message to client when you put your site in production. Your client is really not interested in the raw details of your errors.

Related Articles

On a production site, you could decide to send the user to a custom error page when an error occurs. That allows you to catch the error, send an e-mail to the Web master and explain to your user in plain English what went wrong. Check out the following articles for more information about this subject:

• Enabling ASP Error Processing
• ASPError Object
• Using the built-in ASPError object