Sometimes custom HTTP messages don't work. Especially with ASP.NET.
Let me step back and give a real life example. We have a nice looking application that has custom error pages (404, 500) defined. Defined twice, since the ones in web.config only apply to file types ASP.NET knows about, so they also have to be set up in IIS in case we get a link to default.asxp. Fine.
And the exec's like it.
Then, out of the blue, UGLY RED LETTER ERROR MESSAGE:
|Server Application Unavailable
The web application you are attempting to access on this web server is currently unavailable. Please hit the "Refresh" button in your web browser to retry your request.
Administrator Note: An error message detailing the cause of this specific request failure can be found in the application event log of the web server. Please review this log entry to discover what caused this error to occur.
Now, sure, this tells us to head on over to the event log and fix the problem. It also makes our website look looks slightly worse than if it had been hit by Code Red:
HELLO! Welcome to http://www.worm.com!
And the exec's don't like it.
So I have an "Issue" - make sure we never get that error message again. It's tempting to misinterpret that request as "Fix the root causes that would cause that error message to be displayed", but the actual request is "I don't care what goes wrong on the servers, COM objects, permissions, etc., make sure that no one will ever see those ugly red letters again.
Step 1) Reproduce the error. One easy way to do this is edit machine.config and change the processModel/password to "DoNotAutoGenerate".
Step 2) Find out who's creating that ugly message and intercept it.
I'm on Step 2.
I'm pretty confident that this isn't coming from aspnet_wp.exe (or anywhere else in the ASP.NET / .NET world, for that matter) since this error usually occurs when the ASP.NET worker process chokes. Moving back a bit, I figured I'd catch it at the IIS level with a custom 500, but that didn't work.
So, getting a bit crazier, how about an ISAPI filter? Did you know .NET bows out when it comes to ISAPI filters (at least in managed c#)? You can do HTTP Handlers and HTTP Modules, but both depend on aspnet_wp.dll, which is already dead at this point.
For context, I'd rather be thrown up on than mix it up with C++ again. Then again I've got a 9 month old so getting thrown up on is no big thing. But, I'd rather not mess with a C++ ISAPI filter if either:
1) Someone's already done this sorta thing
2) It's doomed to fail
Having looked further into exactly who is generating this message, I'm less confident that the ISAPI filter can work. Going through c:\WINDOWS\system32\inetsrv (w3svc.dll, inetinfo.dll, etc.) with ResHacker showed these files contain error message strings with html tags in them, and opening them with a text editor showed quite a few more (string constants, not resources). This leads me to believe IIS hits an error in a child process, barfs up an ugly "red letter error", and writes it directly out to the poor end user's browser.
So my hunch is that these error message are a byproduct of IIS, and there's no way to guarantee they'll never be shown. Can any smart folks give me some guidance here?
 ISAPI filters are also a potential performance problem, since all the traffic on the server goes through them.