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 InterDevs 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).
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 doesnt 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.
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:
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.
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:
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:
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
The Extended Properties tab will not be visible if the W3C Extended Log File Format active log format is not selected.
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.
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.
You should always view a log file that is not in use by the server. Read the previous days 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 126.96.36.199 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:
15:28:04 188.8.131.52 - 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.
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:
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:
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:
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
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