HTTP Errors Test

Some errors that occur in IIS are automatically handled by the HTTP API instead of being passed back to IIS for handling. This behavior occurs because the frequency of such errors might otherwise flood an event log or an application handler. The errors captured by the HTTP API are logged in httperr.log files that are by default created in the %SystemRoot%\System32\LogFiles\HTTPERR folder on the IIS host. These log files provide a wealth of information on the following:

  • Responses to clients: The HTTP API sends an error response to a client, for example, a 400 error that is caused by a parse error in the last received request. After the HTTP API sends the error response, it closes the connection.
  • CConnection time-outs: The HTTP API times out a connection. If a request is pending when the connection times out, the request is used to provide more information about the connection in the error log.
  • Orphaned requests: A user-mode process stops unexpectedly while there are still queued requests that are routed to that process. The HTTP API logs the orphaned requests in the error log.

Moreover, specific error types are also designated by Reason Phrase strings that always appear as the last field of each error line in the log file.

By periodically parsing these log files and reading the errors/reasons captured by the same, administrators can significantly shorten troubleshooting cycles and rapidly resolve problems. This is where the HTTP Errors test helps. This test, at configured intervals, parses the HTTP error log file, reads the reason phrases logged therein, and reports the number of errors that occurred due to each reason. Detailed diagnostics provided by the test also shed more light on the nature of these errors. This way, the test simplifies problem identification, analysis, and resolution.

Target of the test : An IIS web server

Agent deploying the test : An internal agent;

Outputs of the test : One set of results for the IIS web server monitored

Configurable parameters for the test
  1. TEST PERIOD - How often should the test be executed
  2. Host - The host for which the test is to be configured
  3. Port - the port to which the specified host listens
  4. log file path – The httperr.log files are by default created in the %SystemRoot%\System32\LogFiles\HTTPERR folder on the target server. Since this test, by defaut, looks for the httperr.log files in the aforesaid directory only, the log file path parameter is set to none by default. However, if you have configured these log files to be created in a different directory in your environment, then you will have to explicitly specify the full path to these log files in the log file path text box. For instance, your path specification can be: C:\LogFiles\HttpErrors
  5. DD Frequency - Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD Frequency
  6. To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.

    The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

    • The eG manager license should allow the detailed diagnosis capability
    • Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.
Measurements made by the test
Measurement Description Measurement Unit Interpretation

Application offline:

Indicates the number of errors logged in the log file with AppOffline as the Reason Phrase.

Number

If the Reason Phrase is AppOffline, it implies that a service unavailable error occurred (an HTTP error 503). The service is not available because application errors caused the application to be taken offline.

The detailed diagnosis of this measure reveals the complete details of errors with AppOffline as the Reason Phrase. Such details include, the date and time of the error, the IP address and port of the affected client, the IP address and port of the affected server, the version of the protocol being used, the verb state that the last request that is parsed passes, the URL requested and any query that is associated with it, the protocol status of the response to the request, the reason phrase, and the request queue name. From these details, you can instantly figure out when the error occurred, the client and server affected by the error, the request in response to which the error occurred, and the reason for the error.

Busy application pool processes:

Indicates the number of errors logged in the log file with AppPoolTimer as the Reason Phrase.

Number

If the Reason Phrase is AppPoolTimer, it implies that a service unavailable error occurred (an HTTP error 503), because the application pool process was too busy to handle the request.

The detailed diagnosis of this measure reveals the complete details of errors with AppPoolTimer as the Reason Phrase. Such details include, the date and time of the error, the IP address and port of the affected client, the IP address and port of the affected server, the version of the protocol being used, the verb state that the last request that is parsed passes, the URL requested and any query that is associated with it, the protocol status of the response to the request, the reason phrase, and the request queue name. From these details, you can instantly figure out when the error occurred, the client and server affected by the error, the request in response to which the error occurred, and the reason for the error.

Application shutdown:

Indicates the number of errors logged in the log file with AppShutdown as the Reason Phrase.

Number

If the Reason Phrase is AppShutdown, it implies that a service unavailable error occurred (an HTTP error 503), because application shut down automatically in response to administrator policy.

The detailed diagnosis of this measure reveals the complete details of errors with AppShutdown as the Reason Phrase. Such details include, the date and time of the error, the IP address and port of the affected client, the IP address and port of the affected server, the version of the protocol being used, the verb state that the last request that is parsed passes, the URL requested and any query that is associated with it, the protocol status of the response to the request, the reason phrase, and the request queue name. From these details, you can instantly figure out when the error occurred, the client and server affected by the error, the request in response to which the error occurred, and the reason for the error.

Bad requests:

Indicates the number of errors logged in the log file with BadRequest as the Reason Phrase.

Number

If the Reason Phrase is BadRequest, it implies that a parse error occurred while processing a request.

The detailed diagnosis of this measure reveals the complete details of errors with BadRequest as the Reason Phrase. Such details include, the date and time of the error, the IP address and port of the affected client, the IP address and port of the affected server, the version of the protocol being used, the verb state that the last request that is parsed passes, the URL requested and any query that is associated with it, the protocol status of the response to the request, the reason phrase, and the request queue name. From these details, you can instantly figure out when the error occurred, the client and server affected by the error, the request in response to which the error occurred, and the reason for the error.

Connections reset by client:

Indicates the number of errors logged in the log file with Client_Reset as the Reason Phrase.

Number

If the Reason Phrase is Client_Reset, it implies that the connection between the client and the server was closed before the request could be assigned to a worker process. The most common cause of this behavior is that the client prematurely closes its connection to the server.

The detailed diagnosis of this measure reveals the complete details of errors with Client_Reset as the Reason Phrase. Such details include, the date and time of the error, the IP address and port of the affected client, the IP address and port of the affected server, the version of the protocol being used, the verb state that the last request that is parsed passes, the URL requested and any query that is associated with it, the protocol status of the response to the request, the reason phrase, and the request queue name. From these details, you can instantly figure out when the error occurred, the client and server affected by the error, the request in response to which the error occurred, and the reason for the error.

Connections abandoned by application pool:

Indicates the number of errors logged in the log file with Connection_Abandoned_By_AppPool as the Reason Phrase.

Number

If the Reason Phrase is Connection_Abandoned_By_AppPool, it implies that a worker process from the application pool has quit unexpectedly or orphaned a pending request by closing its handle.

The detailed diagnosis of this measure reveals the complete details of errors with Connection_Abandoned_By_AppPool as the Reason Phrase. Such details include, the date and time of the error, the IP address and port of the affected client, the IP address and port of the affected server, the version of the protocol being used, the verb state that the last request that is parsed passes, the URL requested and any query that is associated with it, the protocol status of the response to the request, the reason phrase, and the request queue name. From these details, you can instantly figure out when the error occurred, the client and server affected by the error, the request in response to which the error occurred, and the reason for the error.

Connections abandoned by request queue:

Indicates the number of errors logged in the log file with Connection_Abandoned_By_ReqQueue as the Reason Phrase.

Number

If the Reason Phrase is Connection_Abandoned_By_ReqQueue, it implies that a worker process from the application pool has quit unexpectedly or orphaned a pending request by closing its handle. This is specific to Windows Vista and later versions and to Windows Server 2008 and later versions.

The detailed diagnosis of this measure reveals the complete details of errors with Connection_Abandoned_By_ReqQueue as the Reason Phrase. Such details include, the date and time of the error, the IP address and port of the affected client, the IP address and port of the affected server, the version of the protocol being used, the verb state that the last request that is parsed passes, the URL requested and any query that is associated with it, the protocol status of the response to the request, the reason phrase, and the request queue name. From these details, you can instantly figure out when the error occurred, the client and server affected by the error, the request in response to which the error occurred, and the reason for the error.

Connections dropped:

Indicates the number of errors logged in the log file with Connection_Dropped as the Reason Phrase.

Number

If the Reason Phrase is Connection_Dropped, it implies that the connection between the client and the server was closed before the server could send its final response packet. The most common cause of this behavior is that the client prematurely closes its connection to the server.

The detailed diagnosis of this measure reveals the complete details of errors with Connection_Dropped as the Reason Phrase. Such details include, the date and time of the error, the IP address and port of the affected client, the IP address and port of the affected server, the version of the protocol being used, the verb state that the last request that is parsed passes, the URL requested and any query that is associated with it, the protocol status of the response to the request, the reason phrase, and the request queue name. From these details, you can instantly figure out when the error occurred, the client and server affected by the error, the request in response to which the error occurred, and the reason for the error.

Connections limit has reached:

Indicates the number of errors logged in the log file with ConnLimit as the Reason Phrase.

Number

If the Reason Phrase is ConnLimit, it implies that a a service unavailable error occurred (an HTTP error 503), because the site level connection limit has been reached or exceeded.

The detailed diagnosis of this measure reveals the complete details of errors with ConnLimit as the Reason Phrase. Such details include, the date and time of the error, the IP address and port of the affected client, the IP address and port of the affected server, the version of the protocol being used, the verb state that the last request that is parsed passes, the URL requested and any query that is associated with it, the protocol status of the response to the request, the reason phrase, and the request queue name. From these details, you can instantly figure out when the error occurred, the client and server affected by the error, the request in response to which the error occurred, and the reason for the error.

Connections refused:

Indicates the number of errors logged in the log file with Connections_Refused as the Reason Phrase.

Number

If the Reason Phrase is Connections_Refused, it implies that the kernel NonPagedPool memory has dropped below 20MB and http.sys has stopped receiving new connections.

The detailed diagnosis of this measure reveals the complete details of errors with Connections_Refused as the Reason Phrase. Such details include, the date and time of the error, the IP address and port of the affected client, the IP address and port of the affected server, the version of the protocol being used, the verb state that the last request that is parsed passes, the URL requested and any query that is associated with it, the protocol status of the response to the request, the reason phrase, and the request queue name. From these details, you can instantly figure out when the error occurred, the client and server affected by the error, the request in response to which the error occurred, and the reason for the error.

Internal errors:

Indicates the number of errors logged in the log file with Internal as the Reason Phrase.

Number

If the Reason Phrase is Internal, it implies that an internal server error occurred (an HTTP error 500).

The detailed diagnosis of this measure reveals the complete details of errors with Internal as the Reason Phrase. Such details include, the date and time of the error, the IP address and port of the affected client, the IP address and port of the affected server, the version of the protocol being used, the verb state that the last request that is parsed passes, the URL requested and any query that is associated with it, the protocol status of the response to the request, the reason phrase, and the request queue name. From these details, you can instantly figure out when the error occurred, the client and server affected by the error, the request in response to which the error occurred, and the reason for the error.

Application request limit reached:

Indicates the number of errors logged in the log file with QueueFull as the Reason Phrase.

Number

If the Reason Phrase is QueueFull, it implies that a service unavailable error occurred (an HTTP error 503), because the application request queue is full.

The detailed diagnosis of this measure reveals the complete details of errors with QueueFull as the Reason Phrase. Such details include, the date and time of the error, the IP address and port of the affected client, the IP address and port of the affected server, the version of the protocol being used, the verb state that the last request that is parsed passes, the URL requested and any query that is associated with it, the protocol status of the response to the request, the reason phrase, and the request queue name. From these details, you can instantly figure out when the error occurred, the client and server affected by the error, the request in response to which the error occurred, and the reason for the error.

Connections expired:

Indicates the number of errors logged in the log file with Connection_Dropped_List_Full as the Reason Phrase.

Number

If the Reason Phrase is Connection_Dropped_List_Full, it implies that the list of dropped connections between clients and the server is full. This is specific to Windows Vista and later versions and to Windows Server 2008 and later versions.

The detailed diagnosis of this measure reveals the complete details of errors with Connection_Dropped_List_Full as the Reason Phrase. Such details include, the date and time of the error, the IP address and port of the affected client, the IP address and port of the affected server, the version of the protocol being used, the verb state that the last request that is parsed passes, the URL requested and any query that is associated with it, the protocol status of the response to the request, the reason phrase, and the request queue name. From these details, you can instantly figure out when the error occurred, the client and server affected by the error, the request in response to which the error occurred, and the reason for the error.

URL processing errors:

Indicates the number of errors logged in the log file with URL as the Reason Phrase.

Number

If the Reason Phrase is URL, it implies that a parse error occurred while processing a URL.

The detailed diagnosis of this measure reveals the complete details of errors with URL as the Reason Phrase. Such details include, the date and time of the error, the IP address and port of the affected client, the IP address and port of the affected server, the version of the protocol being used, the verb state that the last request that is parsed passes, the URL requested and any query that is associated with it, the protocol status of the response to the request, the reason phrase, and the request queue name. From these details, you can instantly figure out when the error occurred, the client and server affected by the error, the request in response to which the error occurred, and the reason for the error.