IIS logs 500.19 if a client drops connection while loading the website

HTTP status and sub-status codes provide valuable information about the issues users come across. One of the code pairs is 500.19 which means “Configuration data is invalid“. However, IIS may show this pair incorrectly if a user drops connection before the browser loads the website completely.

The error message from the Failed Request Tracing log is below. Please note that this error appears during the execution of the Dynamic Compression module.

HttpStatus: 500

HttpReason: Internal Server Error

HttpSubStatus: 19

ErrorCode: An operation was attempted on a non existent network connection (0x800704cd)

Steps to reproduce this issue:

• The client goes to the URL
• The page starts loading
• The client drops the connection before the page is fully loaded (disconnects the wireless or turn off the device)

For a scenario in which 500.19 error appear because of an invalid configuration data, check this post out.

What happens if the user drops connection?

The expected behavior for IIS to log one of these code pairs: 200.0.995, 200.0.64, 206.0.995 or 206.0.64 (The last part of the codes is sc_win32_status. It is 64 or 995 in these pairs). However, in this case, IIS logs 500.19.64. clearly:

2019-01-17 02:06:34 W3SVC535435 web32 192.168.1.150 GET /address/ - 80 - 200.10.110.10 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:29.0) +Gecko/20120101+Firefox/29.0 - domain.com 500 19 64 678298 200 411

In the record above, the size of the data loaded is 678298 bytes. The page size is about 1 MB. It means that the user dropped the connection after the browser loaded about 70% of the data.

In addition to IIS logs, it is a good idea to check HTTPERR logs as well. IIS saves logs for the activities happened in kernel-mode. In this case, HTTPERR file shows “Connection_Dropped”. However, this could be misleading because if there is a record in IIS logs, HTTPERR should have a record for that request. Pay extra attention to see if the timestamp matches the date/time of the issue. Read the next section for details.

2019-01-17 06:48:55 15.45.65.25 36971 192.168.1.150 443 HTTP/1.1 POST /index.html - 400 51 Connection_Dropped hsn-core+ASP.NET+Core

“Zombie” connections

I would like to open a parenthesis before going forward with the issue details and the solution. There is a very similar scenario to the issue I mentioned above (The client drops connection while page is loading). Microsoft well documented this scenario.

When a client drops the connection before getting the full response, this connection is called a “zombie connection”. IIS (more specifically, HTTP.SYS) doesn’t drop these connections right away. It waits for the timeout value (120 seconds by default). If the response is still not completed, It drops the connection. In this case, It is expected to see a 500 error along with the 64 code in sc_win32_status column.

The Http.sys driver adds the “zombie connection” to a list. Because the original connection object is still available, the original connection object information can be included in the logging information when the request is completed. If the response is completed before the time-out value that is used by the Http.sys driver is reached, no information is logged in the Httperr.log file. Instead, the status code is logged in the IIS log. For example, an “HTTP 200-OK” status code is logged in the IIS log when the request succeeds.

Microsoft Support

Solution for the incorrect 500.19 logs

It is a bug in the Dynamic Compression module. This module throws 500 error for any failure. I am hoping that a patch is developed to address this issue soon.

If the incorrect logs are causing serious issues, you can disable Dynamic Compression so that IIS logs accurate error codes. However, please note that disabling Dynamic Compression increases the bandwidth usage and response times.

If you are receiving “Internal Server Error” in your WordPress blog, here is the solution.