Classic ASP error line 0 column -1

We run a busy website built on clas开发者_运维百科sic ASP (for all sorts of legacy reasons). During busy periods we're seeing an unexplained error and can't get to the bottom of it. It manifests by IIS 7 triggering our custom 500 error page.

On this page we gather as much detail about the error as we can, using both the ASPError object and the err object. What we emerge with is:

From the ASPError object:

ASPCode: 0

Category:

Source:

Page:

Description:

Line: 0

Column: -1

In the err object, err.Number, err.Source and err.Description are all empty.

I don't know whether to look further for IIS configuration issues, application pools etc. or whether this is a code-related problem.

Any ideas much appreciated!

You could create a simple separate ASP page that would trigger an error. For example :

<%
Option Explicit
a = 1
%>

Browse to the page and see what happens. If you still got no error informations it is probably IIS configuration. Otherwise you may have some really curious error, but nothing I've ever seen in the past.

A bit late on my reply, hopefully you have solved this by now and this will simply help someone else in our position later.

In IIS, open the site and then the Error Pages feature. Select "Edit Feature Settings..." from the right side and change to "Detailed errors". Refresh the page throwing the error and you should see the true error which is occurring.

I had 2 errors which could cause this: missing DB Provider and using Option Explicit with an undeclared variable.

Hope this helps someone!

In IIS7 and later, there's a bug whereby only the default error handler gets full error details - if you call Server.GetLastError() from a custom error page that's configured for a specific error code, everything comes back blank.

There is a workaround, though - if you set the site’s default error property (under IIS settings > Error Pages > Edit Feature Settings...) to your custom error page, IIS will invoke this page whenever an error is not handled by an explicitly configured status-code handler (so your 404, etc. handlers will still work) - but for some reason, handling the error this way means Server.GetLastError() still works properly

More details at https://dylanbeattie.net/2008/12/04/fun-with-servergetlasterror-in-classic.html