When deploying applications or services to IIS one can sometimes run into errors that haven’t been foreseen during development. Of course, with appropriate logging you can quickly identify the source of the problem, but when your site lacks this functionality you’d love to see the same detailed exception information as you see while you’re developing the application.
The Yellow Screen of Death that accompanies such an error mentions:
Server Error in '/' Application. Runtime Error Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine. Details: To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "Off". <!-- Web.Config Configuration File --> <configuration> <system.web> <customErrors mode="Off"/> </system.web> </configuration>
As mentioned by the error page, because of security concerns this configuration will only affect errors seen when accessing the server through a local address. This approach may not work on a testing or production environment, for example when the site that is in error lives behind a host name and requests are routed over the internet.
You can however change the way IIS treats error pages. If you want to enable displaying detailed errors for all visitors, even remote ones, there’s only one option you have to change. Open IIS Management Console, go to the site in question and under ‘IIS’ click ‘Error Pages’. In the ‘Actions’ column, you can now click ‘Edit Feature Settings…’, which will show this screen:
When you select ‘Detailed errors’, IIS will display the detailed error page for all failed requests, even remote ones. Please note that this setting should be switched back after discovering and solving the error you were looking for, since detailed errors can emit sensitive information about the inner workings of your application which can be abused by attackers.