Detailed error iis

By default, the IIS server is set to show detailed errors for local requests only, whereas it displays a custom error page for remote requests. This is done for security reasons, since detailed errors could reveal potentially detailed technical information about the web server and website.

The detailed errors also reveal HTTP substatus codes, which are helpful in debugging complex issues. The bad guys out there could use this information to conduct attacks on a web server or website. That is why the IIS server only shows a custom error page for remote requests by default.

Why are detailed errors important?

As discussed above, detailed errors are important when you want to debug a problem in a website hosted on a server running IIS. The custom error page shows an error message that is usually ambiguous. Let’s have a look at the two screenshots below:

The above screenshot shows a typical 403 – Forbidden: Access is denied error using the custom error page displayed by IIS. It is not very helpful for website administrators. Now, let’s have a look at the following screenshot:

This screenshot shows the same error with detailed error mode enabled. Now, it shows plenty of useful information that an administrator can use to identify the cause and fix the problem.

Enabling detailed errors using the IIS manager

To enable detailed errors:

1. Open the IIS manager by pressing WinKey+R, typing inetmgr, and pressing Enter.
2. Expand the Sites node and select the website for which you want to enable detailed errors.
3. Under the IIS section in the Features View, double-click Error Pages (see the following screenshot).

1. In the Actions pane on the right, click Edit Feature Settings.
   

1. In Error Responses, you will see three options:
   1. Custom error pages
   2. Detailed errors
   3. Detailed errors for local requests and custom error pages for remote requests (default)
2. Now select either the second or third option and click OK.

Since you can directly access the web server using remote desktop, selecting the third option is best. Now, you can open the web browser on the server itself and try to load the problematic webpage to see a detailed error page containing more technical information. By doing this, you’re not enabling the bad guys out there to view the detailed information, since the detailed error is only displayed for local requests.

Enabling detailed errors using the web.config file

There are situations in which you cannot use the IIS manager to enable detailed errors. For example, if your website is hosted on a shared hosting site, you won’t have access to the IIS manager. In such scenarios, you could enable detailed errors using the web.config file, which is usually located in the root directory of the website. Just add the following line inside the <system.webServer> tag:

<httpErrors errorMode="Detailed" />

Remember that by adding this line to the web.config file, you are forcing IIS to throw the detailed errors for local or remote requests.

Subscribe to 4sysops newsletter!

Once you identify the root cause of the problem, it is always recommended to disable detailed errors to prevent your website from revealing sensitive information.

How to Use HTTP Detailed Errors in IIS 7.0

Introduction

Every Web-Site Administrator or Web Developer has seen «404 — File not found», «401 — Unauthorized» or «500 — Server Error» messages in his browser. This article helps you understand how and why IIS generates these errors and how they can be configured.

Many might think that generating error messages does not seem to justify a full article. But there is more to errors than meets the eye. Error messages are a sensitive topic, because every error reveals more about your web-site than you might want revealed. The more information someone can gather about your site, the likelier it is that you will be hacked. A search for «google hacking» or «cross-site scripting» reveals a wealth of information on this topic.

However, error messages are also a valuable tool to troubleshoot problems. Developers and Web-Site Administrators require as much detail as possible when an error occurs. Ideally the error message gives recommendations on how to fix the problem. Here is how IIS addresses these fundamentally opposed goals.

Errors, What Errors?

This article talks about HTTP errors as specified in the HTTP RFC (RFC 2616 — section 6.1.1). An HTTP error is always expressed by sending a response with a status code greater than 400 back to the requesting client.

Client Errors

Status codes between 400 and 500 specify an error that the client made, e.g. bad syntax or a request to a resource that doesn’t exist. You can try this by requesting a bogus URL from the web-site of your choice, for example: http:// /this_resource_does_not_exist. You get a «404 — File not found» error.

Server Errors

Status codes starting with 500 are errors caused by the server. The most common causes for 500 errors on IIS systems are:

• An ASP or ASPX page that contains a syntax error
• The web server configuration or the application configuration cannot be read or is invalid
• The site is stopped

It is important to note that browsers like IE often replace errors returned from a web server with their own errors. This makes troubleshooting harder. In IE you can turn this feature off. Go to the «Tools» menu, select «Internet Options», click the «Advanced» tab and find the «Show friendly HTTP error messages» check box and uncheck it. To see the raw response, use HTTP tools like WFETCH in the IIS 6.0 Resource Kit (see «Related Links»).

HTTP Errors in IIS

There are two things that can happen when the httpError module (custerr.dll) encounters an error:

• A custom error is generated
• A detailed error is generated

Custom errors are error pages that the regular users of your web-site see. They contain a brief error description of why the error happened, but nothing else. Here is the custom error generated when you request a resource that does not exist, for example: http:// /this_resource_does_not_exist

Detailed errors are intended for local administrators and developers. They are supposed to provide information that helps to immediately fix the problem. Here is an example of the same request, but now returning a Detailed Error:

This is dangerous, because Detailed Errors contain information about the inner workings of your web-site. Only trusted personnel should see a Detailed Error. The only way to ensures this is to only generate a detailed error if the request comes from the local machine. As soon as the request is not local, a custom error is generated. Look at the following flow diagram:

Data Flow

First: Error check

The httpError module receives a notification if a response is about to be sent (RQ_SEND_RESPONSE notification). The httpError module checks the status code of this response and immediately returns if the status code is not greater than 400.

Second: Custom Error or Detailed Error

The next check is determined by the request origin (is the request a local or remote request) and the setting of the errorMode property. The errorMode property is set to DetailedLocalOnly, which means that Custom Errors are generated for every remote request. If errorMode is set to «Custom», then all error responses will become Custom Error. If errorMode is set to «Detailed» all error responses will become Detailed Errors. The following table clarifies this behavior:

If the httpError module determines that a Custom Error must be generated, it looks into its configuration to see if it can find a matching error. If a match is found, it sends the static file, redirects the request or executes the URL specified. If no match can be found, IIS send a basic one-line message containing the status code. The next section explains the Custom Error configuration in detail.

If custerr.dll determines that a Detailed Error must be generated, another check is needed. IIS does not touch the response if a module overrode the entity of the response with its own error description. It might contain valuable information. ASP.NET is a good example. The entity of an ASP.NET error response might contain the exception stack and its own error description. A Detailed Error is only generated if the entity body of the response is empty.

Configuration

Here is the IIS custom error section obtained on a clean install:

You see that if the status code of a response is 401, IIS will return a file named 401.htm.

Sub-Status Codes

Many HTTP errors have a sub-status. The IIS default Custom Errors configuration does not differentiate based sub-status codes. It sends the same Custom Error page if you enter the wrong credentials (401.1), or if you get access denied based on invalid rights to access a file (401.3). You can see the different sub-status codes in the log files or via Detailed Errors. Here is a list of the different 404 sub-status codes that IIS produces:

You can configure the httpErrors section to show a Custom Error for particular sub-status codes. If you add the following line to the httpErrors configuration section, IIS returns 404_3.htm if a file with a file extension is requested that is not included in the IIS MimeMap ( configuration section).

Here is how to make the example work:

1. Add the entry above to your httpErrors configuration section.
2. Create a file named 404_3.htm in your c:inetpubcusterren-us directory.
3. Create a file named test.yyy in you c:inetpubwwwroot directory.
4. Now request http://localhost/test.yyy .

The file extension .yyy is not part of the IIS MimeMap and the static file handler will not serve it.

New in IIS: Language-specific Custom Errors

Each more recent browser includes the language of the client as a request header. Here is an example of how this header might look:

The syntax and registry of accepted languages is specified in RFC1766.

When generating an error, IIS takes this header into account when it looks for the custom error file it returns. It generates the path for the custom error using the following logic:

prefixLanguageFilePath configuration setting (for example c:inetpubcusterr )+
Accept-Language header sent by the client (for example en-us) +
Path configuration setting (for example 404.htm)

If the browser sends a request for an non-existing resource and the «Accept-Language» header has the value of «en-us,» the file that gets returned will be c:inetpubcusterren-us404.htm .

For example, if you are from Germany, you want your error messages in German. To do this, you must install the Windows Vista Language Pack for German. This creates the c:inetpubcusterrde-DE directory with custom error files in it. Now if the browser sends the «Accept-Language» header with the value of «de-DE, the file that gets returned will be c:inetpubcusterrde-DE404.htm .

IIS will always fall back to the system language if the directory «de-DE» does not exist.

Internet Explorer allows you to configure the Accept-Language header. Go to «Tools» — «Internet Option», select the «General» tab and click the «Languages» button.

Custom Error Options

In the above examples, IIS sends the contents of the file as the custom error response. IIS has two other ways to respond to an error: by executing an URL or by redirecting the request.

ExecuteUrl

If you want to do more in your custom error, e.g. sending an e-mail or logging the error to a database, you can execute an url. This allows you to execute dynamic content like an ASP.NET page. The example below replaces the 404 custom error. Now IIS executes /404.aspx whenever a 404 error occurs.

Security Considerations

A word of caution: For architectural reasons, IIS can only execute the URL if it is located in the same Application Pool. Use the redirect feature to execute a Custom Error in a different Application Pool.

IIS can also return a 302 Redirect to the browser when a particular error occurs. Redirect is good if you have a server farm. For instance, you can redirect all your errors to a central location that you closely monitor.

There is risk however: responseMode=»File» (which is the default) allows you to specify every file on the disk. This will not work if you are very security conscious.

A workable scenario might include only allowing the delegation of the errorMode setting. This enables a developer to receive Detailed Errors for his application even if he is using a remote client. All that is necessary is to set errorMode=»Detailed». Here is how to configure this scenario:

Allow the delegation of the httpErrors section:

Second, go to the section in applicationHost.config and change it so that only errorMode is delegated:

Summary

Custom and Detailed Errors are powerful IIS features. They help you to troubleshoot problems without compromising the security of your IIS Server. Many configuration options help you to custom tailor your users’ experience. Most importantly: experimenting with it is fun.

Источник

HTTP Errors

Overview

The element allows you to configure custom error messages for your Web site or application. Custom error messages let you provide a friendly or a more informative response by serving a file, returning another resource, or redirecting to a URL when visitors to your site cannot access the content they requested. For example, you might want to customize each of the error message pages for your Web site to have the same look and feel as the rest of your site.

The element contains a collection of elements, each of which defines an error message that IIS uses to respond to specific HTTP errors. You can add custom error messages to IIS by adding an element to the element in the Web.config file for your site, application, or URL. Each element uses the responseMode attribute to specify whether IIS serves static content, dynamic content, or redirects to a separate URL in response to an error.

You can use the element to remove a specific error message from the collection of error messages your site or application inherits from a higher level in the IIS configuration hierarchy. Also, you can use the element to remove all HTTP error messages from the collection of HTTP error messages that your site or application inherits.

The element also contains attributes that configure IIS 7 to process requests that cause errors. The existingResponse attribute defines what IIS 7 does to an existing response when the server returns an HTTP error status code. The defaultPath attribute defines the path to a customer error page if you choose specify File for the responseMode attribute in an element.

The detailedMoreInformationLink attribute specifies a link to more information about a particular error.

The element also can contain an errorMode attribute that you can use to control the level of detail that IIS returns to a browser when an HTTP error occurs. You can set the errorMode attribute to DetailedLocalOnly, which is the default setting, or you can set it to Custom or Detailed. If you specify DetailedLocalOnly, or if you do not specify an errorMode value, IIS returns detailed error information only to the browser on the local server and a custom error message to a browser on an external computer. If you set the errorMode value to Custom, IIS returns only custom error messages to all requesting browsers. If you set the errorMode value to Detailed, IIS returns detailed error information to all requesting browsers. The default DetailedLocalOnly value allows you to troubleshoot HTTP errors on the local server while not exposing sensitive information to external browsers.

By default, IIS serves error messages defined in files stored in the %SystemRoot%HelpIisHelpCommon folder. You can create a custom error message for users and configure IIS to return this page whenever it encounters a specific HTTP error on your site.

Compatibility

Setup

The element is included in the default installation of IIS 7.

How To

How to add a custom error page

Open Internet Information Services (IIS) Manager:

If you are using Windows Server 2012 or Windows Server 2012 R2:

• On the taskbar, click Server Manager, click Tools, and then click Internet Information Services (IIS) Manager.

If you are using Windows 8 or Windows 8.1:

• Hold down the Windows key, press the letter X, and then click Control Panel.
• Click Administrative Tools, and then double-click Internet Information Services (IIS) Manager.

If you are using Windows Server 2008 or Windows Server 2008 R2:

• On the taskbar, click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.

If you are using Windows Vista or Windows 7:

• On the taskbar, click Start, and then click Control Panel.
• Double-click Administrative Tools, and then double-click Internet Information Services (IIS) Manager.

In the Connections pane, expand the server name, expand Sites, and then navigate to the Web site or application that you want to configure custom error pages for.

In the Home pane, double-click Error Pages.

In the Actions pane, click Add.

In the Add Custom Error Page dialog box, under Status code, type the number of the HTTP status code for which you want to create a custom error message.

In the Response Action section, do one of the following:

• Select Insert content from static file into the error response to serve static content, for example, an .html file, for the custom error.
• Select Execute a URL on this site to serve dynamic content, for example, an .asp file for the custom error.
• Select Respond with a 302 redirect to redirect client browsers to a different URL that contains the custom error file.

In the File path text box, type the path of the custom error page if you chose Insert content from static file into the error response or the URL of the custom error page if you use either the Execute a URL on this site or Respond with a 302 redirect, and then click OK.

If you select Execute a URL on this site, the path must be a relative path. If you select Respond with a 302 redirect, the URL must be an absolute URL.

Configuration

You can configure the element at the server level in the ApplicationHost.config file and at the site and application level in the appropriate Web.config file.

Attributes

When set to true, absolute paths are allowed for custom error pages when the section is delegated. When set to false, only paths that are relative to the site root are allowed.

The default value is false . defaultPath Optional string attribute.

Specifies the default path of the custom error page. The type of path is determined by the defaultResponseMode attribute. If you choose File, the file path is returned. If you choose either the ExecuteURL or Redirect path type, the URL of the custom error page is returned. defaultResponseMode Optional enum attribute.

Specifies how custom error content is returned.

The defaultResponseMode attribute can be one of the following possible values; the default is File .

detailedMoreInformationLink Optional string attribute.

Specifies a link, shown at the bottom of the page, to a page with more detailed information about a particular error. You can use this property to point end users to a custom location for error information. The status, sub-status, HRESULT and message ID are sent as part of the query string.

The default value is https://go.microsoft.com/fwlink/?LinkID=62293 . errorMode Optional enum attribute.

Specifies whether HTTP errors are enabled.

The errorMode attribute can be one of the following values; the default is DetailedLocalOnly .

existingResponse Optional enum attribute.

Specifies what happens to an existing response when the HTTP status code is an error, i.e. response codes >= 400.

The existingResponse attribute can be one of the following values; the default is Auto .

Child Elements

Adds an HTTP error to the collection of HTTP errors. remove Optional element.

Removes a reference to an HTTP error from the HTTP error collection. clear Optional element.

Removes all references to HTTP errors from the HTTP error collection.

Configuration Sample

The following configuration example, when included in the Web.config file for a Web site or application, uses the errorMode attribute to only allow detailed error messages to appear on the local computer. It also uses the defaultResponseMode attribute to set the response mode for the site or application. The sample then removes the inherited error message for the 500 status code. Next, it sets the prefixLanguageFilePath attribute to the directory where IIS should search of a new custom error page, and sets the path attribute to 500.htm, the file that contains the custom error message.

Sample Code

The following examples adds a new file for all status code 404 errors with a substatus of 5, which IIS returns for «URL Sequence Denied» errors. In these examples, the prefix path is set to «%SystemDrive%inetpubcusterr», and the file name is specified as «404.5.htm».

Источник

TLDR:First determine where in the pipeline you’re getting the error from (scroll looking for screenshots of something that resembles your error), make changes to get something new, repeat.

First determine what error message you are actually seeing.

If you are seeing the file located here…

%SystemDrive%inetpubcusterr<LANGUAGE-TAG>500.htm

…which generally looks like this:

**…then you know you are seeing the currently configured error page in IIS ** and you do NOT need to change the ASP.net customErrors setting, asp error detail setting, or «show friendly http errors» browser setting.

You may want to look at the above referenced path instead of trusting my screenshot just in case somebody changed it.

«Yes, I see the above described error…»

In this case, you are seeing the setting of <httpErrors> or in IIS Manager it’s Error Pages —> Edit Feature Settings. The default for this is errorMode=DetailedLocalOnly at the server node level (as opposed to the site level) which means that while you will see this configured error page while remote, you should be able to log on locally to the server and see the full error which should look something like this:

You should have everything that you need at that point to fix the current error.

«But I don’t see the detailed error even browsing on the server»

That leaves a couple of possibilities.

1. The browser you are using on the server is configured to use a proxy
   in its connection settings so it is not being seen as «local».
2. You’re not actually browsing to the site you think you are browsing to — this commonly happens when there’s a load balancer involved. Do a ping check to see if dns gives you an IP on the server or somewhere else.
3. Your site’s httpErrors settings is set for «Custom» only. Change it to «DetailedLocalOnly». However, if you have a configuration error, this may not work since the site level httpErrors is also a configuration item. In that case proceed to #4
4. The default for httpErrors for all sites is set for «Custom». In this case you need to click on the top level server node in IIS Manager (and not a particular site) and change the httpErrors settings there to DetailedLocalOnly. If this is an internal server and you’re not worried about divulging sensitive information, you could also set it to «Detailed» which will allow you to see the error from clients other than the server.
5. You’re missing a module on the server like UrlRewrite (this one bites me a lot, and it often gives the generic message regardless of the httpErrors settings).

«Logging on to the server is not an option for me»

Change your site’s httpErrors to «Detailed» so you can see it remotely. But if it doesn’t work your error might already be a config error, see #3 immediately above. So you might be stuck with #4 or #5 and you’re going to need somebody from your server team.

«I’m not seeing the error page described above. I’m seeing something different»

If you see this…

…and you expect to see something like this…

…then you need to change «Send errors to browser» to true in IIS Manager, under Site —> IIS —> ASP —> Debugging Properties

If you see this…

or this…

…you need to disable friendly errors in your browser or use fiddler’s webview to look at the actual response vs what your browser chooses to show you.

If you see this…

…then custom errors is working but you don’t have a custom error page (of course at this point were talking about .net and not classic asp). You need to change your customErrors tag in your web.config to RemoteOnly to view on the server, or Off to view remotely.

If you see something that is styled like your site, then custom errors is likely On or RemoteOnly and it’s displaying the custom page (Views->Shared->Error.cshtml in MVC for example). That said, it is unlikely but possible that somebody changed the pages in IIS for httpErrors so see the first section on that.

Detailed error reporting is one of the popular error debugging features in the IIS web server. By default, the IIS web server error messages are disabled from being sent to users in order to prevent exposing more information outside the server.

In order to enable detailed error messages for debugging/development purposes, then need to make some adjustments in the IIS web server settings.

See the following instructions for enabling detailed error reporting for the IIS web server on Windows OS

1. Open the IIS web server manager console from your server.

   You may open IIS Manager from the Administrative Tools program group, or you can run the following command from Windows run prompt.

   inetmgr
   

   

2. From the site list, click on the domain that needs to enable detailed error messages. and then double click Error Pages in the Feature view.

   

3. Click on the Edit feature setting from the right side Actions menu.

   

4. From the error responses list, check on the Detailed Error and then click OK to save the update the changes.

   

5. Once this is done, it will automatically add the following entries in the domain configuration file (web.conf).

   <configuration>
     <system.webserver>
       <httperrors errormode="Detailed">
     </httperrors></system.webserver>
   </configuration>
   

   

6. You can find the domain configuration file under the document root of the website. From the IIS, Right-click on the domain and choose Explore option to go to the document root of the website.

   

   Once this you can see more details of error message while accessing the domain or domain URL

   

   NOTE: Make sure to change the settings back once development/debugging is completed.

Related Tutorials

• Installing IIS web server on Windows Cloud Servers

• SSL Certificates with IIS web server on Windows Cloud Servers

This article will not explain how to enable detailed tracing. Check the See Also section for a step by step procedure to enable detailed tracing.

Without Custom Error Pages

Whilst the default error page is user-friendly, it’s administrator unfriendly. The error below is shown whenever something is wrong between the FIM Portal and the FIM Service.

The above error is accompanied by an entry in the Application Event log. The message is more or less the same: there’s something wrong.

In words the message is:

The Portal cannot connect to the middle tier using the web service interface. This failure prevents all portal scenarios from functioning correctly.
The cause may be due to a missing or invalid server url, a downed server, or an invalid server firewall configuration.
Ensure the portal configuration is present and points to the resource management service.

In order to have a better understanding as to what is wrong we can temporarily enable detailed error pages on the IIS side of the FIM Portal. For the following section we will edit several parts of the web.config of the FIM Portal that is typically located
in:

Important
Before you update the Web.config file, you should take a backup of the original file.

Enable Detailed Error Pages

In order to have a better understanding as to what is wrong we can temporarily enable custom error pages on the IIS side of the FIM Portal. Follow the following steps:

1. Enable the callstack (Set CallStack=»true»)

   <SafeMode
MaxControls="200"
CallStack="true"
DirectFileDependencies="10"
TotalFileDependencies="50"
AllowPageLevelTrace="false">


       <PageParserPaths>


       </PageParserPaths>


   </SafeMode>


2. Disable custom error pages (Set mode=»Off»)

   <customErrors
mode="Off"
/>


3. Comment the ILMError HTTP module

   <httpModules>


       <clear
/>

       <!--<add name="ILMError" type="Microsoft.IdentityManagement.WebUI.Controls.ErrorHandlingModule, Microsoft.IdentityManagement.WebUI.Controls,
Version=4.0.3561.2, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />-->

       ...


   </httpModules>


4. Perform an IISreset
5. Reproduce the issue. You should now get a more descriptive error in internet explorer. Below is an example where I accidentally provided the wrong URL for the FIM Service during the FIM Portal installation.

You should now get a clear hint about what is going wrong. In this particular example the resourceManagementClient section in the web.config was wrong. 

Disable Detailed Error Pages

In order to provide the user’s a userfriendly message we can disable custom error pages after resolving the issue. Follow the following steps:

1. Disable the callstack (Set CallStack=»true»)

   <SafeMode
MaxControls="200"
CallStack="false"
DirectFileDependencies="10"
TotalFileDependencies="50"
AllowPageLevelTrace="false">


       <PageParserPaths>


       </PageParserPaths>


   </SafeMode>

2. Enable custom error pages (Set mode=»On»)

   <customErrors
mode="On"
/>

3. Enable the ILMError HTTP module

   <httpModules>


       <clear
/>

       <add
name="ILMError"
type="Microsoft.IdentityManagement.WebUI.Controls.ErrorHandlingModule, Microsoft.IdentityManagement.WebUI.Controls, Version=4.0.3561.2, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
/>

       ...


   </httpModules>

4. Perform an IISreset

Related FIM Forum Posts

• Register user to complete self-service password reset

See also

• Troubleshooting FIM 2010 Roadmap
• How to Configure FIM Portal Tracing

Note
To provide feedback about this article, create a post on the FIM TechNet Forum.