Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Certain IIS7/7.5 500.19 configuration errors only render on a browser running on the local server.

This appears to happen regardless of whether I set <httpErrors errorMode="Detailed" existingResponse="PassThrough" /> in the system.webServer section of a site's web.config file (or even globally for that matter).

For example, I had a developer who reported that he was just getting the generic IIS7 500 error page:

enter image description here

This was happening even though he had the following configured in his web.config:

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

If I browse to the site on the server itself I see (some sensitive info redacted): enter image description here

Would the reason for this be that if the web.config has errors it therefore can't be parsed. Because it can't be parsed the local <httpErrors> setting doesn't get read and thus causes IIS to revert to default settings (i.e. DetailedLocalOnly)?


@LazyOne - suggested setting the above config at the server level which I already tried. This resulted in just raw 500 errors:

enter image description here

share|improve this question
"Because it can't be parsed the local <httpErrors> setting doesn't get read and thus causes IIS to revert to default settings (i.e. DetailedLocalOnly)?" -- You can quickly test this theory by changing error response mode for the whole server (which is "detailed local and custom for remote" by default): IIS Manager | Error Pages | Edit Feature Settings... – LazyOne Jun 29 '11 at 15:16
@lazyone - see my update. – Kev Jun 29 '11 at 15:40
up vote 2 down vote accepted

Having poked around some more, I've worked out how to get 500.19 errors to appear remotely even if the site web.config is clobbered.

The trick is to set (globally) errorMode="Detailed" and existingResponse="Replace".

The existingResponse="Replace" setting is a bit counter intuitive but does make sense.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.