Home arrow ASP arrow Page 3 - Replacing the Error 500 ASP Page

Replacing the Error 500 ASP Page

This article looks at how error information is stored and obtained in ASP 3.0 - the ASPError object, this information is then used in the creation of a new, better error page.

Author Info:
By: Wrox Team
Rating: 5 stars5 stars5 stars5 stars5 stars / 91
January 20, 2003
  1. · Replacing the Error 500 ASP Page
  2. · The ASPError Object
  3. · Editing the ASP Error Page
  4. · Extending the Functionality
  5. · E-Mailing Errors
  6. · SourceSafe Integration
  7. · Conclusion

print this article

Replacing the Error 500 ASP Page - Editing the ASP Error Page
(Page 3 of 7 )

Although the introduction of this ASPError object doesn't provide any real improvement to error-trapping, it does mean that the error page that is displayed can display more detailed information and have much richer functionality. If you compare the error pages produced by IIS5 to the ones from IIS4, the benefits are clear.

The page used in IIS5 defaults to the file 500-100.asp in the %SystemRoot%\Help\iisHelp\common folder. This file displays not only the file name and description of the error, but also the line number and column (if it could be calculated) of the error. As an aside, if an error occurs in this 500-100.asp page, then the message displayed will be in the format of that provided by IIS4.

Between IIS5's error page and the one provided for ASP.NET, there is an ever greater difference - the appearance of the latter is cleaner with the page looking noticeably different from other error pages (such as a 404 - file not found error), and a decent sized fragment of the source code is shown, with the offending line highlighted.

The first task of this article is to recreate this new error page for classic ASP.
Doing this will provide three major benefits:
  1. A standardized appearance for all error pages
  2. A page that contains more information than the default 500-100.asp page
  3. A more structured page that can have functionality extended simply
The third point is the most pertinent - if the standard 500-100.asp file is opened in an editor, it can be seen that the code is rather unstructured, with lots of context switches, and quite an obtuse use of HTML.

By making this file more proceduralized with a better process-flow, not only can the appearance of the errors be changed more readily, but also support for displaying errors for developers, and a less technical page for remote users is far easier to implement.

Editing the Error 500-100 Page

The Custom Errors IIS settings
The Custom Errors IIS settings

Rather than edit the existing 500-100.asp file, a new file to be used for processing errors can be created in any location accessible through IIS's virtual file-system for the web-site. This can be achieved by going into the IIS management console then viewing the properties of the server, application, or virtual-directory that is to have the error page changed.

On the Properties window, the relevant setting is found on the Custom Errors tab, towards the bottom of the list under the HTTP Error"500;100" entry. If this item is selected, and the Edit Properties button is selected, then the URL can be changed to point to a different ASP (or HTML) file.

Error Mapping Properties Dialog
Error Mapping Properties Dialog

For the remainder of this article, the following URLs are assumed:
  • /iisHelp/common/Net 500-100.asp for the recreation of the ASP.NET error pages
  • /iisHelp/common/New 500-100.asp for the creation of the final error page that contains the code editor.

Recreating the ASP.NET Error Page

The ASP.NET error page
The ASP.NET error page

The image above is a sample screenshot of an error page generated by ASP.NET. As can be seen, it is much easier to see what the error is than in traditional pages - much of the superfluous text that used to be on error pages is now gone, and the source code that caused the error is presented in a far more noticeable and readable fashion.
To produce a similar page in ASP the separate pieces of information that are required are:
  • The application name
  • The type of error
  • Two error messages
  • Source Code for the error
  • The location of the error (Source File, Line Number, and Column Number)
  • Platform version information
The application name is the first thing that needs to be obtained. This can be formed by a little string manipulation on a couple of the ServerVariable s. The ones that we are interested in are INSTANCE_META_PATH and APPL_MD_PATH. The former of these will return a value such as "/LM/W3SVC/1", and the latter "/LM/W3SVC/1/Root/Projects".

From this, we can see that removing the leading characters given in INSTANCE_META_PATH from the APPL_MD_PATH along with the string "/Root/" will give us an application name such as "Projects".

The only special case to consider is if the error occurs in the root of the site, in which case the application name would be "/". This can then be written to the page as part of the red page-title, followed by a horizontal rule ("<hr>").

The next three pieces of information are available directly from the ASPError object, and are given (in order) in the Category, Description, and ASPDescription properties of the ASPError object. The first of these is written out as a heading ("<h2>"), and the others as paragraphs of text being preceded by the titles "Description", and "Parser Error Message".

The next piece of information is the largest difference between ASP 3.0 and ASP.NET - the display of the block of source code containing the error. To achieve this, we must create an instance of the Scripting.FileSystemObject class, read in the source file as specified by mapping the ASPError.File property to a physical file location. Once this file is read in, a call can be made to the Split() function passing in a carriage-return/line-feed (vbCrLf) as a parameter, creating an array of the source-lines. A short For..Next loop can then be constructed to display the couple of lines around the error itself.

The following code-sample approximates that which needs to be written:

strContents = Split(objFSO.OpenTextFile(strFileName).ReadAll, vbCrLf)
lngMin = objError.Line - 2
lngMax = objError.Line
If lngMin < LBound(strContents) Then lngMin = LBound(strContents)
If lngMax > UBound(strContents) Then lngMax = UBound(strContents)

For lngCount = lngMin To lngMax
  Response.Write Server.HTMLEncode(strContents(lngCount)) & "

This code then simply needs the line containing the error highlighting in red, each line prefixing with the line number, and a small piece of HTML to produce the desired layout. One point to mention is that read-only file-access may have to be given to the default IIS user (IUSR_MachineName) to allow it to obtain the contents to the source file.

Also, if virus-killers such as Norton's AntiVirus 2002 are installed, then they may block access to files from ASP scripts - such options should be checked first as they can cause IIS to lock-up.

The next three pieces of information are displayed on a single line - the source-file containing the error, the line number, and the column number. If any of these pieces of information is not found in the ASPError object, then it is omitted from the page.

An example of this can be seen in the screenshots below - the column number could not be calculated for the given error, hence it is left out from the page. All three of these pieces of information come straight from the File, Line and Column properties, with the File being converted to a local path using a call to Server.MapPath().

The final piece of information is not particularly useful in ASP 3.0: displaying server version information. In .NET, this information is useful, as it informs the developer of the version of the .NET Runtime and ASP.NET being used, especially important when Betas of the runtime were being tested.

In the recreation of this, the information to be displayed is the SERVER_SOFTWARE and GATEWAY_INTERFACE. Both of these Server-Variables contain versioning information, but are of limited use in diagnosing potential problems.

The only other Server-Variable that contains version information is the HTTP_USER_AGENT. This contains information regarding the user's browser version. The knowledge of which browser is being used can help to solve problems with the posting of data and so on. For instance, Internet Explorer on the Mac performs multi-part posts (those containing files) in a different manner to IE on a PC.

Altering the page to display this information if it is necessary simply consists of editing one line of code, and for a Windows XP machine running the final release of .NET with SP1, and IE 6.0 would be something similar to:

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; .NET CLR 1.0.3705)

With all of this information put together into one ASP file, the page that is generated when an error occurs is shown in the screenshot below:

A recreation of the ASP.NET error page for ASP 3.0
A recreation of the ASP.NET error page for ASP 3.0

blog comments powered by Disqus

- Central Scoreboard with Flash and ASP
- Calorie Counter Using WAP and ASP
- Creating PGP-Encrypted E-Mails Using ASP
- Be My Guest in ASP
- Session Replacement in ASP
- Securing ASP Data Access Credentials Using t...
- The Not So Ordinary Address Book
- Adding and Displaying Data Easily via ASP an...
- Sending Email From a Form in ASP
- Adding Member Services in ASP
- Removing Unconfirmed Members
- Trapping HTTP 500.100 - Internal Server Error
- So Many Rows, So Little Time! - Case Study
- XDO: An XML Engine Class for Classic ASP
- Credit Card Fraud Prevention Using ASP and C...

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2017 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials