I'm trying to track down a very weird bug with IIS 7.5 on Windows 7. First, here's some context.

I have a very simple ASP.NET web app with the following code:

<?xml version="1.0" encoding="utf-8" ?>
        <customErrors mode="Off"/>

<%@ Page Language="C#" Inherits="_Default" CodeFile="default.aspx.cs" %>
    <h1><asp:literal runat="server" id="litHeading1" /></h1>

    <form runat="server">
        <asp:TextBox id="tbInput" runat="server" />
        <asp:Button id="btnSubmit" Text="Submit" runat="server" />


public partial class _Default : System.Web.UI.Page
    protected void Page_Load(object sender, EventArgs e)

        if( IsPostBack ) {
            litHeading1.Text = "Posted!  Hi, " + tbInput.Text;
        } else {
            litHeading1.Text = "Get";

I also have a very simple Python script to hit this page and post to it:

import requests as reqm

url = 'http://localhost/testapp4.0/default.aspx'

post_payload = {
    # post values don't seem to matter, having them or not having them
    # doesn't seem to affect the problem
    '__EVENTVALIDATION': r"/wEWAwLT5c/kDALpouS8DQLCi9reA+DdtetcF6QuZcTZOdNPIJzwWkvX+ITpSzlbXCsWVizl",
    'tbInput': 'fred',
    'btnSubmit': 'Submit',

def doit():
    req = reqm.post(url, data=post_payload)

# if it doesn't show up in one run, bump value to 
# 500 or so
for x in range(1):

So, whats the problem?

The problem is that IIS is dropping the connection frequently, but only when the POST action is performed. If change the script to use the GET action, I don't see any issues.

Example IIS log file:

2012-11-28 00:48:57 ::1 POST /testapp4.0/default.aspx - 80 - ::1 python-requests/0.14.0+CPython/2.7.2+Windows/7 400 0 64 6767

Example IIS trace file:


Example IIS HTTP.err from Python requests:

2012-11-28 00:44:16 ::1%0 53528 ::1%0 80 HTTP/1.1 POST /testapp4.0/default.aspx - 1 Timer_EntityBody Classic+.NET+AppPool

2012-11-28 01:16:03 ::1%0 53928 ::1%0 80 HTTP/1.1 POST /testapp4.0/default.aspx - 1 Timer_EntityBody .NET+4.0

Ditto but from a failing PHP request:

2012-11-28 01:19:33 ::1%0 53942 ::1%0 80 - POST /testapp4.0/default.aspx - - Timer_HeaderWait -

Iterations I have made on various things to try and isolate

I have seen the problem show up regardless of what I tried:

  • ASP.NET 2.0 vs 4.0
  • Multiple Windows 7 Pro machines, one a VM one a laptop
  • localhost traffic vs going over a network
  • Classic & Integrated modes
  • Python 2.7, 3.3, PHP 5.4 client scripts (running from Windows & Linux)
  • IIS Express
  • Putting a 1 second delay between requests in the script loops
  • Varied the parameters I'm POSTing. Everything from completely accurate viewstate, etc. to "foo=bar"
  • Turned off Windows firewall

Intermittent nature

  • For the longest time, the Python scripts would always error out on the first request. Then, once in a great while, they would start working and mostly stay working. If I then put the script in a tight loop, the server quickly hangs again.
  • Initially, the PHP script was always working on the first request, but it consistently fails when in a tight loop as well.


  • Using a Windows 2003 server (IIS 6), 500 requests in a row without problem
  • when I can tell the script has hung, but hasn't errored out yet, and I kill the script, the next few requests will usually work.
    • if I let it time out instead of killing it, and try to run the script again, it will usually hang again on the immediately next request.

Rate limiting?

I'm wondering if this might be some kind of rate-limiting issue in IIS 7.5 on Windows 7. I read it has certain limitations since its not running on a server OS. However, that doesn't explain why I still see the problem when I'm running very infrequent requests.

Why is it a problem?

I'm trying to run functional tests against a WebForms .NET app. As you can imagine, frequently dropped connections are playing havoc on my testing!

I've spent days troubleshooting this and would be very grateful for some help!


WOW!, just did another google search and came across a guy who mentioned AVG. A light went off and I completely disabled my AVG and the problem disappeared. Further testing showed the problm is with the LinkScanner functionality.

I had considered AVG early on, but since I don't have the internet security version, I assumed it would not have an impact. I very much regret that assumption!

  • I feel your pain. I just recently had a totally different problem and went far down the road to fix it only to uncover that the solution would not work on the target system. It was a problem with an unchecked assumption. Takeaway: checking your assumption is probably cheaper than going further right away. – Oliver Aug 30 '13 at 11:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.