Introduction
Nowadays there are all sorts of ways to catch errors in your Active Server Pages. When writing the code you can use fancy tools like Visual InterDev’s Server Side Debugging or use the good old method of writing your variables out to the browser in HTML. However, once your code goes into production how do you find the errors? A better question to ask first is, “Does my production code have errors?” (ya right).

Production Code
All code contains bugs. It does not matter what language you are using to write your code: Active Server Pages, C, PASCAL, or Visual Basic. It doesn’t matter how big a company you (take Microsoft for example) are or how experienced a programmer you are. Once you accept this fact, you can start hunting the bugs down, making sure the biggest and the baddest ones are not prevalent.

Checking For Bugs
One way to find out if you production machine has Active Server page bugs is to use Performance Monitor. All you have to do it turn the Performance Monitor on, add the “Request Failed Total” counter. The “Request Failed Total” counter counts the number of Active Server page errors since the last time the server was started. Here is how to Add the “Request Failed Total” counter:

  1. Start the Performance Monitor by clicking on Start | Programs | Administrative Tools | Performance Monitor.
  2. From the Tool Menu click on Edit | Add To Chart.
  3. From in the Object drop down list choose Active Server Pages.
  4. Once you have changed the Object drop down, choose Requests Failed Total from the Counter list.
  5. Click on the Add button. Immediately a line should appear on the Performance Monitor Chart.

Now lets check to see if you have had any errors, click on the Requests Failed Total line in the list at the bottom of the performance monitor. Read the Max Field directly above the counter list. If it is greater then zero then you have had an error in your Active Server Pages since you started the server. If the field is zero, either there are no errors or the IIS service has not been running for very long (rebooting your machine will reset the counter). If this is the case, let the service run for 24 hours and come back to it.

Subdividing the Bugs
If the Requests Failed Total line shows that you have Active Server Pages errors you might want to divide those errors in categories. There are three other counters in Performance Monitor that report subcategories of the Requests Failed Total counter. They are Errors During Script Runtime, Errors From ASP Preprocessor, and Errors From Script Compilers. Here is how to get them into the performance monitor window:

  1. Start the Performance Monitor by clicking on Start | Programs | Administrative Tools | Performance Monitor.
  2. From the Tool Menu click on Edit | Add To Chart.
  3. From in the Object drop down list choose Active Server Pages.
  4. Once you have changed the Object drop down, choose Errors During Script Runtime, Errors From ASP Preprocessor, or Errors From Script Compilers from the Counter list.
  5. Click on the Add button. Immediately a line should appear on the Performance Monitor Chart.
  6. You can either close the Add To Chart Dialog by clicking OK or add another counter.

Logging Bugs
Internet Information Server version 4.0 allows you to log Active Server Pages bugs to your IIS log files. To do this, you need to turn on extended logging like this:

  1. Open Internet Service Manager.
  2. Highlight the web site that you wish to monitor.
  3. Right click and choose Properties from the drop down menu.
  4. Click on the Web Site Tab.
  5. At the bottom choose W3C Extended Log File Format from the Active Log Format drop down list.

By default URL Query is included in the extended logging, but while you are changing the properties to Extended logging you should also check to make sure that the URL Query extended property to your extended log. URL Query puts the error messages from your Active Server Pages in your log files. Here is how to check/add the URL Query property

  1. Make sure that the Internet Service Manager is open and the Web Site tab is selected.
  2. Click on the on the Properties Button in the Enable Logging Section.
  3. Choose the Extended Properties.
    Note
    The Extended Properties tab will not be visible if the W3C Extended Log File Format active log format is not selected.
  4. Check the URI Query checkbox (top right-hand side).
  5. Selected OK to close the Extended Logging Properties property sheet.
  6. Selected OK to close the Web Site Properties property sheet.

You have now configured IIS to log the Active Server Pages bugs into the log file. All you have to do is find the bugs in the log file and correct them.

Examining the Log File
The log file is an ASCII text file that contains an entry for every request to the server. Each request to the server is on a separate line. You can read the file with Notepad if it is not to big, or with Visual InterDev if the file is very large.

Note
You should always view a log file that is not in use by the server. Read the previous day’s log file, or the current log file with the server turned off. Reading a log file that the server is writing to might cause errors with the server, or the server might not write to the log file correctly.

Once you have the log file open you will want to look for lines like the one below. Example 1

00:25:08 157.56.93.174 HEAD /submit.asp |33|80004005|[Microsoft][ODBC_Driver_Manager]_Data_source_name_not_found_and_no_default_driver_specified 200

Notice that Example 1 tells you that the DSN for ODBC is not set up correctly for submit.asp. Here is another example of an error in the log file: Example 2

15:28:04 206.129.49.2 - GET /default.asp |1|ASP_0126|Include_file_not_found 200

Example 2 informs you that a file was not found that default.asp includes. In both these cases if you view the page through the browser the errors will appear and you can get more information.

Examining the log files is a good way to tell where the errors are on your production machine. However, notice that in the examples there is no keyword that you can use as a search string that will catch both errors. This means that you either need to know the error that you are searching for, or that you need to examine the log file by hand.

Examining the log files by hand can be a tedious process especially if your log files are very long like they would be on a production server. The next section deals with addressing this by sending the URI Error information to the Event Viewer.

Logging Errors to the Event Viewer
IIS 4.0 has the ability to log URI Errors to the Event Viewer. However it is an undocumented and unsupported feature. In IIS 5.0 (coming out with NT 5.0 ) this will be a documented and supported feature.

The Event Viewer can only contain a limited number of errors before it becomes full. If you are having a lot of errors on your production site you might not want to send all the errors to the Event Viewer. Once the Event Viewer becomes full, IIS will stop serving up pages and your web site will be down. One way to avoid this is to tell the Event Viewer that it can erase the events if needed. This is not the default setting for the Event viewer and we recommend that you change these settings when you set up your NT machine. Here is how to tell the Event Viewer to erase events if need:

  1. Start the Event Viewer by clicking on Start | Programs | Administrative Tools | Event Viewer.
  2. Click on Log from the menu bar and then Log Settings.... The Event Log Settings dialog will appear.
  3. Select Application from the Change Log Settings for drop down list.
  4. In the Event Log Wrapping section, click on Overwrite Logs as Needed radio button.
  5. Select System from the Change Log Settings for drop down list.
  6. In the Event Log Wrapping section, click on Overwrite Logs as Needed radio button.
  7. Click on OK.

To tell the Internet Information Server to log the URI errors to the Event Viewer you need to add a registry key. Create ErrorsToNtLog with a value of 1 in this location: 


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\ASP\Parameters

In order for this to take effect you will need to stop the IIS Admin Service then restart the World Wide Web Publishing Service. It might just be easier to reboot your machine but here are the instructions for stopping and restarting the IIS Admin Service:

  1. Open the Control Panel by clicking on Run | Settings | Control Panel.
  2. Double Click on Services.
  3. Scroll down in the Service List View until you see IIS Admin Service.
  4. Highlight the IIS Admin Service and press the Stop button.
  5. Press Ok when you are queried to stop the services dependent on the IIS Admin Service.
  6. Once all the services are stopped scroll to the bottom and select the World Wide Web Publishing Service so that it is highlighted.
  7. Press the Start button.
  8. Wait until the service is started them close the Services dialog by pressing Close.
  9. Exit from Control Panel.

Once you have followed these steps (or rebooted your machine) then IIS will be logging to the Event Log.

Figure 1 : Active Server Page Error in the Event Log

Summary
Errors are inevitable, however with proper procedures you can track and correct them causing your visitors the least amount of trouble. You check the number of errors you are getting using the Performance Monitor, track the errors in your error log and report them to the Event Viewer with the Internet Information Server.

By Wayne Berry