Classic ASP on IIS 8.5: Setting the Configuration to See ASP Error Messages

Classic ASP is still a very good option to develop or prototype simple Web applications with. Sometimes you’ll need to transition a classic ASP application from an older Web server to a more modern one. Basically, the ASP is still good, but the server is out of date and needs to be replaced.

When you upgrade your server, for example going from IIS 6 to IIS 8.5 (Windows 2012), you’ll quickly see that you need to make server configuration changes in order for your application to run like it should. See a previous article on my blog for instructions on how to enable Classic ASP on your new Web server (since it is not enabled by default).

Another issue you may encounter is that your migrated application doesn’t work and you have no idea why because the error messages are hidden. This is good for everyday use of your application by regular users, but it’s not so good if you are trying to debug issues with your application setup on the new Web Server. In this blog post I will explain how to set your system so that you can see the detailed error messages that your classic ASP application is throwing. Of course, once you are done and the application is running well, you should consider re-enabling settings so that regular users aren’t shown detailed application error messages.In a new setup of IIS 8.5 on Windows 2012, detailed classic ASP error messages are hidden by default. This is a great security feature except to have enabled but is a real pain if you are trying to figure out why your newly transferred application is not running.

You can tell that IIS is hiding the real error from you if you see an error such as:

An error occurred on the server when processing the URL. Please contact the system administrator. 
If you are the system administrator please click here to find out more about this error.

This message above is the default IIS error set to show that’s actually updatable by you (the system administrator). I’ll explain how to disable this message and instead show the real error below, but first you need to set up your browser to show detailed errors reported by the Web server.

First things First: Allowing Detailed Errors to Show in Internet Explorer

If do not even see the above error message and instead see an even more obscured “user-friendly” error message, then you’ll first need to disable the option in Internet Explorer to “Show friendly HTTP error messages” You can disable this (in IE 11) by unchecking the checkbox with that title under:

1. Tools
2. Internet Options
3. Click the Advanced Tab
4. Scroll down a bit under the “Browsing” section until you see the option to “Show friendly HTTP error messages“. Make sure this option is unchecked
5. Apply your changes

Allow IIS to Serve Detailed Error Messages to You

Now that you have properly configured your browser to show detailed error message, try viewing the problem page on your new site again. It’s very likely that when you browse to your new ASP site you will see the IIS-provided generic error message that I showed earlier. This is actually really good for everyday use, and you should re-enable it when you have your application running properly, but for now you need to disable it to see why your application isn’t working. To do so:

1. Log onto your Web server as an Administrator and open IIS
2. Left click once on your Web site.
3. In the options panel under the IIS heading, double click the ASP option (that has the mouse-over text: configure properties for ASP applications)
4. In the options window that pops up:
5. Expand the Debugging Properties option
6. Here you’ll now see the default Script Error message that IIS was serving to your browser.
7. Right below the script error message is a True/False toggle to “Send error messages to Browser“
8. Set that Toggle to False
9. Finally make sure to click the Apply button to save your changes. Remembering to click to save sounds simple, but other sections in IIS do not require you to click to save, so this is a gotcha to keep in mind.

At this point you should be able to point your browser to your newly migrated Web site and you should see the detailed error that was previously hidden.

Still Not Seeing the Detailed Error Message?

It can be that you may still be blocked from seeing a proper error, even after going through the steps described above. In this case you may also need to enable Client and/or Server side debugging. These two options can also be found in the ASP Debugging Properties box that I described in the previous section. They are above the True/False toggle to Send Errors to Browser. Make sure you toggle these options to True one at a time and check which one was responsible for hiding the errors being sent by the application.

For example I’ve seen an application that should have been showing “Access Denied” errors, but because the ASP option to “Enable Client-side Debugging” was set to False, the application would show a 500 level error page instead of the custom application error page that the developers had coded in their application and that was being directed to in the global.asa file.

Once I set the Client-Side Debugging toggle to true, the server would show the proper ASP error page as it was intended. Since this is often the intended behavior in classic ASP applications, you should consider in your specific case if you should leave this setting in place even after you have finished setting up the application on your new server.

By the way, I was able to set the option “Send Errors to Browser” to False so the application would not give away too much information when a real error happened… just the “Enable Client-side Debugging” option needed to be set to True in order to see the custom ASP error page.