IIS - Other - ASP Errors Inline vs. Whole Page

Until recently, when errors (like a VBscript "Variable is undefined" error) occured in the ASP code I was developing, the errors would appear inline in the page. In other words, any output the page had already generated would appear, followed by the error details. I don't remember doing anything to enable this -- it's just the way errors were reported.

Recently, IIS started displaying "The page cannot be displayed" messages. The details of the error are all there, but not the output that the page already generated before the line containing the error.

I haven't defined any custom error pages -- everything on the "Custom Errors" page is set to the default values.

The only change I can think of that I made recently was that I temporarily installed an SSL certificate for testing purposes, but I've since removed the certificate from the server, and this problem still happens.

The way the errors used to be displayed was helpful, because I could see some of the page's output in addition to the error details. I'd like to get it back to displaying errors in that way. Any suggestions on how to do that?

Thank you,

Jeri

Your best bet is to get your code to quit causing errors

There are iis settings in the application configuration area that may affect the level of detail that is returned on errors. Othwerise, I don't recall seeing a partial page in the browser prior to an asp server error. Maybe you've changed some of the flow in your asp coding?

Doug, thanks for your reply!

I agree, I'd be much better off without the errors!

Here's an example that demonstrates the error. I have an ASP page with the following:



I have two IIS servers (on 2 different computers), and I installed this ASP page onto both servers. When I view the page from one server, the browser says:



When I view the page from the other server, it says:



The second site used to behave the same way the first one does, but now it doesn't. I've tried comparing the IIS property pages for the two sites, but I don't see any differences. Something must be different -- I just don't see what it is.

Thanks,

Jeri

are you viewing both from the same browser? or are you viewing them from the server browser? if the latter, check to make sure you have turned off show friendly http error messages on your browser.

Yup, same browser, and "show friendly http error messages" is turned off. I'm pretty sure it's a web server configuration issue, not a browser issue.

Thanks!

Jeri

Did you compare the settings in the asp error handling settings between the two servers? That's the place I know of where the server admin can alter the way IIS responds to errors. And did you check for any custom error pages on one server but not the other?

Yup, I compared all the settings for the sites' virtual directory for both servers, and I also compared the settings at the Default Web Site level -- all seem to be the same. Ditto for custom error pages.

I'm now wondering whether there are any relevant settings that might be hiding in the registry or the metabase that aren't visible through the management console. If that seems likely, any suggestions on how to check that out?

Thank you!

Jeri

Are the IIS versions the same? I don't know where else to look, if there are registry or metabase settings I wouldn't know how to find them.

After much poking around, I finally found it.

I had been looking at the Custom Errors property pages for a particular virtual directory and for the top-level "Web Sites" entry in the IIS manager. I could have sworn that I had also looked at the page for the Default Web Site, but apparently not -- when I checked it just now, I saw that the Custom Error for IIS 500-100 was set to something else -- when I changed it back to the default, it went back to behaving the way I wanted.

So here's a lesson: there are three places where Custom Errors (and presumably other properties) could affect the behavior of a virtual directory:

- Property pages for "Web Sites"
- Property pages for "Default Web Site"
- Property pages for the virtual directory itself

(Of course, the other lesson is to check everything twice before posting a question!)

I don't know how the Default Web Site's Custom Errors wound up set to something other than the default, but I know I didn't do it! I suppose that when I installed a test SSL certificate, IIS could have changed the value for the Default Web site. I guess the only way to find out is to re-install the test certificate and see what happens, but at this point, I'm reluctant to break it again.

Doug, thank you for your help!

Jeri

I'm glad to hear you got it figured out.