Turning off IIS8 Custom Errors for Classic ASP - Potenial bug in IIS?

Question

I think I have found a bug regarding in the IIS Error Pages system.

Note: - I am not using .NET Error Pages - this is set to Off

The problem:

When a custom error page is setup for the 500.100 (Classic ASP) response code, IIS always sends a custom error page even when errorMode is set to Detailed. The only way to get IIS to send the error is to explicitely remove the entry in the web.config.

EG:

<remove statusCode="500" subStatusCode="100"/>
 or
<clear/>

Note - the following does not work (which works for all other codes):

<remove statusCode="500" subStatusCode="-1"/>

My scenario:

• IIS 8 (I am unaware if the issue exists in older versions of IIS)
• Website running .NET 2.0 - Classic pipeline
• Feature Delegation on Error Pages set to read only
• Error page setup in IIS as follows (due to the feature delegation above, these entries are not in the web.config):
  • 404 - /path/to/404.htm - ExecuteURL
  • 500 - /path/to/500.htm - ExecuteURL
  • 500.100 - /path/to/500.htm - ExecuteUrl

Turning off Custom Errors:

In order to turn off the custom errors, all I need to do is:

• Load IIS
• Load Error Pages
• Click Edit Feature Settings
• Select Detailed Errors

This works successfully for all codes except Classic ASP 500 errors (status code 500.100).

The only way I can get the proper Classic ASP error is to setup the following (which requires me to change the feature delegation to Read/Write):

<system.webServer>
    <httpErrors errorMode="Detailed">

        <clear/>  
        OR    
        <remove statusCode="500" subStatusCode="100"/>

    </httpErrors>    
</system.webServer>

Summary

It seems that if a 500.100 custom error page is setup, then setting Detailed Errors to true does not work for Classic ASP 500 errors.

Is this a bug or am I missing something?

Answer 1

Its a known bug that we also get and are working around it by removing the 500 error and instead linking to our custom page from the "when you can find anything else to send 'em" part of the configuration.

(I can't remenber off hand what its called)

Answer 2

Try to modify your web.config in this way (it worked for me with IIS 7.5).

Replace the line

<httpErrors errorMode="Detailed">

with

<httpErrors existingResponse="PassThrough" errorMode="Detailed">

This is because by default IIS7 intercepts HTTP status codes such as 4xx and 5xx generated by applications further up the pipeline.