Pages appear to stop responding RRS feed

  • Question

  • User-413041239 posted

    We're running IIS7 on WS08.  I have experienced SEVERAL times when I'm accessing a page on this server where it will simply stop responding.  The load progress bar will show no progress at all, and after a minute or two, I finally stop it.  I can either refresh the browser (which usually immediately brings the page up), or go directly to the page or a different page on the same web site.  I have seen this happen on standard html pages as well as asp and asp.net (2.x) pages.  It happens most of the time on pages that I've just changed, but I've seen it happen on pages that I have not changed in quite a while.

    I have checked the event log when this happens, and there are no entries in there indicating any errors of any kind.

    I usually access this server across the network, so instead of a standard "www.mysite.com", I usually do a "http://myserver/myfolder/mypage.htm" sort of thing.  But, I believe I've seen this problem when accessing it both ways.

    We have some of the same apps running on a WS03 server perfectly.

    1) Any idea what is causing this?

    2) If there are no ideas,  are there any testing methods anyone can suggest to help me figure this out?


    Wednesday, March 4, 2009 11:21 AM

All replies

  • User511787461 posted

    Use failed request tracing - it should pinpoint where the request processing is getting stalled.

    Wednesday, March 4, 2009 1:03 PM
  • User-413041239 posted

    Thanks, I've just enabled that.  I've set it to log situations where it takes longer than 2 minutes to respond to a request.  I'll check the log when I run into it again (after waiting 2 minutes, of course), and see what I get.


    Wednesday, March 4, 2009 2:48 PM
  • User-413041239 posted

    OK.  I've "got one on the line".  I have Failed Request Tracing turned on, and I've set it to a time limit of 2 minutes.  Here's the problem.  2 minutes came and went.  It did not respond, nor did it fail.  However, after more than 5 minutes,it finally responded and displayed the screen as it should have. There were no errors or anything, just an incredibly long delay before it displayed the correct screen.  There is nothing in the Failed Request Log (I suppose, because it didn't fail).

    Any ideas how I can figure out why this thing took 5 minutes to respond when it should have taken only a second or two at the most?


    Tuesday, March 10, 2009 10:19 AM
  • User511787461 posted

    What does the time taken field in IIS log say - can you get failed request trace if you remove the "2 minutes" condition just add a condition for all status-codes "200-999".

    Tuesday, March 10, 2009 12:57 PM
  • User-413041239 posted

     Here is the first entry from the log that accesses the page that had a long delay:

    2009-03-10 14:22:03 GET /dlg/tsanat/HSMSConfPayment.aspx - 80 - Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+en-US;+rv: 200 0 0 1716

     Don't know how to read this log entry, but the number at the end (which could be the time??) can't be seconds, and I wouldn't think it would be mili-seconds either.  It was just a little over 5 minutes, and that doesn't match with this.

    Any ideas?



    Tuesday, March 10, 2009 1:21 PM
  • User1940267948 posted

    I have encountered the same issue and believe it is specific to recent versions of FireFox (3.0.6+) and IIS7-hosted websites. I posted the following on a FireFox board, but didn't garner much response:


    I believe there is some issue with the way FireFox and IIS7 interact with regard to connection handling. Failed request tracing is not much help in this situation as it only lists that the request has "NO_END" in the BEGIN_REQUEST stage of processing.

    The issue appears to be intermittent (at least for me) but it happens frequently enough to cause user problems and complaints. I have no idea where to go next to resolve this problem and hope that MS will help figure out what the root cause of this issue is.



    Tuesday, March 10, 2009 2:52 PM
  • User511787461 posted

    That is in milliseconds - so 1.7sec - can you collect a netmon trace when the problem happens.  Also, to be sure, you are running a server sku of IIS - the client skus (vista) have limits on number of concurrent connections so you may have requests getting queued while earlier requests are being processed.

    Tuesday, March 10, 2009 5:19 PM
  • User-413041239 posted

     I can tell you that the request took a lot longer than 1.7 seconds to process.  I timed it, and while I didn't get the exact second that it stopped, I know it was more than 5 minutes.  So, that being the case, maybe IIS responded but for some reason the browser didn't pick up on it?  It sounds a lot more like the fellow might be correct about it being an issue with IIS7 and Fire Fox (and maybe IE7?) not talking with each other?  This is an IIS7 issue, because this app works fine with IIS6.

    How do I run a "netmon trace"?

    What do you mean by "running a server sku of IIS"?

    As far as concurrent connections, I seriously doubt that I had very many people connected at the time.  I do run several web sites on the machine, but it's use mainly for development.  If I had to guess, there may have been 6 or 7 people connected at the most.Plus, I can be almost 100% sure that no one was accessing this particular application at the time, because this was a development folder that no one accesses but me (except rarely someone else would, but most likely not today).


    Tuesday, March 10, 2009 5:35 PM
  • User511787461 posted

    netmon download link

    I mean you are running on windows server 2008 and not vista.

    Tuesday, March 10, 2009 5:42 PM
  • User-413041239 posted

     OK. downloaded and installed.  I guess I'll wait for the next problem and then run netmon.

    Yes, I'm runing WS08, not Vista.


    Tuesday, March 10, 2009 7:48 PM
  • User511787461 posted

    Btw, to use netmon, you will need to browse from an external machine - netmon cannot capture traffic over localhost.

    Tuesday, March 10, 2009 7:57 PM
  • User-413041239 posted

     Will browsing from a different machine on the same network work?  I usually do http://mymachine/myapp/mypage.aspx (for instance).


    Tuesday, March 10, 2009 8:03 PM
  • User-413041239 posted

    OK.  Assuming that browsing to the server from another machine on the network is OK...

    I had it happen again. I then ran netmon and let it run for an entire 10 minutes.  It never did respond, and I got tired of waiting, so I hit the browser stop button to stop it.  However, I did save the captured netmon output.  What should I be looking for?

    Personally, I'm thinking that whatever the problem was that caused it had already occurred by the time I started netmon.Because by the time I notice that it's not responding, I'm thinking the problem has already occurred and it's already too late to start netmon.  At any rate, if there's something here that I should look for, let me know what it is.


    Wednesday, March 11, 2009 10:22 AM
  • User1940267948 posted

    Anil, if you are looking for an example you can see it by downloading FireFox and browsing to our corporate website: www.winebid.com. Click the Search button to get a listing of results. You'll notice that the page comes back very quickly. You can click next/prev links to navigate quickly between subsequent search result pages. However, if you stop on a particular page and wait over 60 seconds, and then click the prev or next link FireFox will hang as described. It doesn't happen all the time, but most of the time under these circumstances. The pages do eventually respond... but only after minutes of nothing but a spinning progress indicator.

    Because the problem (at least in our circumstance) happens only after some period of inactivity, it leads me to believe that it has to do with how IIS7/FireFox handle the connection. Could IIS7 be timing out a connection that FireFox thinks is still open for use? I know nothing of the inner workings of either so that is just a guess based on observations. The problem is clearly reproducable though, and does not happen with Internet Explorer or Safari... only FireFox and only recent builds.

    Thursday, March 12, 2009 10:33 AM
  • User511787461 posted

    Can you zip up the cap file and e-mail it to me at anil (dot) ruia (at) microsoft (dot) com?

    Thursday, March 12, 2009 1:18 PM
  • User-2064283741 posted

    There could be many issues why a page takes a long time to load. Network issues, firewall, route, etc misconfiguration, code, etc

    As anil suggests maybe a network trace is the only way to work out more of what is occurring


    I can reproduce your problem. Often it is like 10-30 seconds not minutes to display teh page in FF3.0.7

    However it only appears to be on the search/database stuff, the about us pages seem to be ok.

    You need to find a pattern where it is reproducable.

    What do the IIS logs say? Remember the time field is the time written to the logs when finished to get the start time it is time-timetaken.

    Could this be the code (javascript problems?) ? Could it be the database? Confirm the times for both these elements.

    What does the application trace routing reveal? Is it the first request that takes the time or sending the last one back or spread throughout the process. 

    Look at the release notes for firefox when you first had a problem http://www.mozilla-europe.org/en/firefox/3.0.6/releasenotes/ and https://bugzilla.mozilla.org/buglist.cgi?keywords_type=anywords&keywords=fixed1.9.0.6+verified1.9.0.6 anything relevant there?


    Thursday, March 12, 2009 2:22 PM
  • User-413041239 posted

    The delay's I'm experiencing last much more than 10-30 seconds.  I waited 5 minutes one time before it responded, and another time I waited 10 minutes before just hitting the stop button. The thing about this is when I stop it, I can usually hit the refresh button, click the link again, and it pops up in a split second.  So, it's not a coding issue, or a database problem. When this happens and I stop/refresh/click again, it pops up immediately.  And, there is practically no traffic on the server, so I know the server is not the issue either.

    The IIS logs don't help much. They only say that a page was accessed at a certain time, and as pointed out in a previous entry here, they showed a response time of 1.7 seconds, but that response did not show up in my browser that fast.  This server is used for development, and when I upload the same code to our WS03 live server, it works perfectly, and I experience no such delays.

    If I understand what you are asking about application tracing, you have to implement that when you're experiencing the problem, don't you (or before?). Thing is, as some one else already pointed out, this doesn't happen all the time.  In fact, I find that most of the time it works just fine.  However, if I let it sit for a little while, then try, sometimes I'll get the long delay, sometimes I will not.

    I checked the Fire Fox logs as you indicated, and didn't see anything obvious there.

    Personally, I believe this is an issue in IIS7 / WS08 as WS03 is working fine.   It could be a configuration issue, but I really don't know what sort of configuration changes to make.


    Thursday, March 12, 2009 2:44 PM
  • User-2064283741 posted

    BTW most of my above reply was aimed at ianderson. I see these as different issues not the same one.

    Often when I have seen similar issue you get a http 200 status and win32 error of 64. Which often means a network issue so check this.

    Yes, you will need to run traces before an issue occurs so it can catch the error. So you will need to do this for netmon too it will be useless without and note the times when the delay is occurring.

    These sorts of problems are often the most difficult to resolve (any version of IIS) as there are so many factors to consider and there is no 100% reproducable behaviour.

    But does it ever occur internally (ideal test is on the box itself)? or it is all external traffic.

    You need to check all the routing/firewall/etc stuff too. I have seen many times that they can cause issues like this.

    Also don't use different OS's for dev/staging and production it will just lead to more problems in the long run as you are not testing the site in the correct enviornment.

    Thursday, March 12, 2009 2:57 PM
  • User-413041239 posted

    My problem and ianderson's seemed to be the same issue to me, but not sure.  I thought that's why he chimed in.

    Problem is that I'd have to be running traces all the time as the problem is intermittent.  I think last time Anil tried to help me set up one of these traces, you have to set it up on a certain process.  I'll try to reproduce it by delaying on a page for a while, then clicking to see if there's something there causing the problem.

    I guess you could say it's occurring internally.  As stated earlier, I'm not going to http://www.whatever..., I'm going to http://myserver/mypath/myapp.aspx.  So, yes, I'm on an internal network.  This is going through the firewall, but I'm not sure what sort of issues to look for.  It would seem to me that if it were a firewall issue, then it would delay or fail all the time.

    The way things are going, I probably won't be developing on different OS's for long.  I think we are planning on purchasing a copy of WS03 and re-formatting this server to get rid of WS08.  I have several other problems too that only seem to be occurring in WS08 that are working fine in WS03.  Problem is that WS03 isn't going to be around forever, so I need to find out what the problem is and get it fixed now instead of just delaying it.


    Thursday, March 12, 2009 3:18 PM
  • User-2064283741 posted

    Firewall, etc can do a lot of things and it is not as simple to say it is either a delay or fail all the time.

    Look at that level to see if the requests are pushed through at that time on the firewall. Is it the first request that is the problem? The last? There is a lack of network information here before any sensible help can be applied. I have been looking at the example given of winebid.com and it only occurs when you have multiple pages in the search - then it seem no page will work for a time.

    What is the difference in the behaviour/code when you have only 1 page in the search? As there is a difference in the outcome for the client. Logically by the reasoning thus far it should fail then.

    The sweeping generalization that FF 3.0.6 is broken with IIS 7 seems premature at this stage. Is some code on some pages is causing this? Are application pools being restarted?

    It appears to be a combination of many things in certain cases. Could bad coding practices be to blame here and something that FF picks up that other browsers do not?

    Could it be network/firewall/router related?

    AFAIK there hasn't been any proper investigation into these causes and that is where I would look into first.

    Thursday, March 12, 2009 5:12 PM
  • User-413041239 posted

    There hasn't been any "proper investigation" because the problem is intermittent.  How do you track something like that?

    I suppose I could start a Netmon capture when I start work in the morning, and let it run all day until the problem happens.  Thing is that I've been on the server all day (today), and it's only happened twice.

    Where do you suggest I start a "proper investigation"?


    Thursday, March 12, 2009 5:24 PM
  • User-2064283741 posted

    Yeah that is one way to start.

    Get the exact time and run through your firewall logs at that time too. Check that with the databases logs, iis logs, the event viewer logs. Is anything happening at that time? App pool reset, anything like that.

    Like I said these are not easy problem to solve in fact some of the most difficult to solve.


    Thursday, March 12, 2009 5:30 PM
  • User-413041239 posted

     I was trying to find the firewall logs earlier, but couldn't seem to find it.  Where do I find the firewall logs (On the server, not the router.  I can deal with the router)?

    I think the rest of the the logs I've found before and last time I tried to track this down, there were no entries at all in the Windows logs (Application and System) for that time frame.  I checked the IIS logs as well, and it showed the page access, but reported a response time far less than it actually was.


    Thursday, March 12, 2009 5:36 PM
  • User-2064283741 posted

    Sorry I presumed you had a third party firewall. Windows firewall here:


    Thursday, March 12, 2009 7:10 PM
  • User-413041239 posted

    OK, I've reviewed that document, and right off the bat, it's not right.  It says to open the Windows Firewall, then click on the Advanced Tab.  When I open the windows firwall, there is no advanced tab.  But, I clicked on "Change Settings".  There is an Advanced Tab there, but there is nothing about Security Logging there.

    So, I go to the help file, and type in Security Logging.  Looking at the View Security Log help entry, it says to go to the Event Viewer, and click on Global Logs.  So, I go to the Event Viewer, but there is no Global Logs entry in there anywhere that I can find.

    However, in the Event viewer, under Windows Logs, there is a Security section.  That simply show who logs in/out, and a few other things.

    So, I "think" I've found the right place, but I'm not sure.  What should I be looking for here (if this is where I need to be)?


    Friday, March 13, 2009 10:08 AM
  • User-413041239 posted

    OK.  I've had it happen again. Here's what happened.  While working on a page (I was updating a page, and refreshing frequently), I clicked on a link and got no response.  I stopped it and clicked the link again, and still got no response.  so, I stopped it again, logged on to the server, and started a netmon session.  I then clicked the link one more time, and still got no response.  I let it run. After about 5 minutes it finally came back and gave me the page I had clicked on.

    So, here is what I have:
    * I've got a  netmon capture file, but don't know what to look for.

    * I checked the IIS logs, but the thing about that is that the time stamp indicated 5:43am.  This occurred at approximately 8:50am (I realize that the time inside the file itself is GMT, but this is the time-stamp on the file itself, which is not GMT).  Even though I'd been accessing several pages on the site, there was no update in there.
    The strange thing is now the entries are there where they weren't before.  Anyway... Here is the entry for the page I was accessing:

    2009-03-13 12:56:25 GET /dlg/bpamem/ConfSpecEvent.asp CID=2863&Inv=C093610&F=I 80 - Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+en-US;+rv: 200 0 0 62

    This coincides with the response.  However, The actual request was made at about 8:50 (12:50 GMT, I suppose), so it took about 6 minutes and change to respond.

    * I have several Failed Request Log entries, but the times do not seem to coincide with the time I had the probem. Most of these have a warning in there of "LOG_FILE_MAX_SIZE_TRUNCATE"

    Where do I go from here?


    Friday, March 13, 2009 10:26 AM
  • User-2064283741 posted

    If that was the same request then IIS responded qucikly and as desired.

    It took a long time to:

    a) getting to the server.


    b) From the server to get to IIS

    Check the packet sniffer logs to see when the request was actually made to the server from that client IP. Did any traffic hit the server from 8:50 to 8:55?

    If the first occurrence was just before the IIS log time say 08:56 then it is a more general networking issue from maybe from the client machine or something on route.

    Friday, March 13, 2009 12:04 PM
  • User1940267948 posted


    I am fully aware of the various components that come into play regarding overall performance and page responsiveness. You are correct to point out that DB, JavaScript, etc. are all sources to look at. However, if it was a general server-side performance issue, it would not be browser-specific. This issue only happens with FireFox, and even then only intermittently. I do believe that VorlonShadow and I are experiencing the same, or at least a related issue. I have seen pages take minutes to respond as well... and the timing of the response is also intermittent.

    Also, I am a bit confused as you state "I can reproduce your problem" and then say "You need to find a pattern where it is reproducable". It is an intermittent issue and following the steps I described it is reproducable. As VorlonShadow mentions, the logs and tracing do not provide much insight into this issue.

    The idea that there is no issue between FireFox 3.0.6 and IIS7 seems a bit odd, considering that I am experiencing it, our site users are experiencing it, and other developers are experiencing it. There clearly is some issue... the question is what is the cause of the problem.



    Friday, March 13, 2009 1:01 PM
  • User1940267948 posted

    Also... just to rule out any programming or client-side issues, as both Vorlon and I have already mentioned, the issue disappears when switching between IIS6 and IIS7. I have run the site on an identical setup, using the exact same code, on IIS6 and cannot produce the issue. It is specific to hosting on IIS7. In fact, I even tried hosting on IIS7 in IIS6 classic-mode but also experienced the issue. So I guess there is a chance that it is a problem with the Server 2008 networking stack and FF... since IIS7 and Server 2008 are inseparable there's no easy way to determine where the problem lies.

    Friday, March 13, 2009 1:07 PM
  • User-2064283741 posted

    Also, I am a bit confused as you state "I can reproduce your problem" and then say "You need to find a pattern where it is reproducable". It is an intermittent issue and following the steps I described it is reproducable. As VorlonShadow mentions, the logs and tracing do not provide much insight into this issue.


    I meant that certain pages on your site don't appear to do this. Others do - more static pages don't seem to have a problem. I do not know enough of the code to understand this more.

    Thus blank statement that it effects IIS7 and FF 3.0.6+ always are misleading. I have a site with .net and IIS7 and FF 3.0.7 and I do not get the same problems? Why is that?

    We need to break the problem down into more detailed segment to work out which area is problematic. Everyone is using .NET so there may be an issue with the stack there under certain conditions.

    BTW Are you using Integrated mode or are they separate?

    The idea that there is no issue between FireFox 3.0.6 and IIS7 seems a bit odd, considering that I am experiencing it, our site users are experiencing it, and other developers are experiencing it. There clearly is some issue... the question is what is the cause of the problem.


    Maybe there are closely related but I am not sure they are the same if that make sense. There seems to be other elements in this too and I am trying to work out what elements are causing the problem.

    For example I can very regularly reproduce the problem (in certain situations) on your site but VorlonShadow it appears very much more intermittent.

    For him It seems so far that there is a delay from when the initial packet is send to the server and IIS receiving and processing it. Is that the same for you?

    Also... just to rule out any programming or client-side issues, as both Vorlon and I have already mentioned, the issue disappears when switching between IIS6 and IIS7. I have run the site on an identical setup, using the exact same code, on IIS6 and cannot produce the issue. It is specific to hosting on IIS7. In fact, I even tried hosting on IIS7 in IIS6 classic-mode but also experienced the issue. So I guess there is a chance that it is a problem with the Server 2008 networking stack and FF... since IIS7 and Server 2008 are inseparable there's no easy way to determine where the problem lies.

    That is interesting that it occurs in the IIS6 mode on Win2008. I do not know about the differences between what happens running in IIS6 mode but there must be some similarities.

    But this leads me to think that it may be something to do with IIS.

    Could you also tell me does it occur on the server itself? Could you install FF on there and reproduce the issue.

    It *could* I suppose also be the network card on the machine maybe it is delaying something getting to the IIS.

    Is there anything in the perfmon for the queue times when you have this problem? The behaviour look a little like this.

    What would be useful is if you code generate a more simple pick of code, that could be tested.

    Maybe just a dummy database and 1 page that causes the problem.

    Sorry if I sound a little curt in the replies I am just trying to understand the issue.

    Friday, March 13, 2009 1:44 PM
  • User1940267948 posted

    I have tested it across different servers, with different network card setups and it occurs on both. I have also tested it in a virtual environment vs a physical machine and it occurs across both. I am not certain if it occurs on the server itself... I'll see if I can setup FF on the server to see if I can reproduce the issue. I'll also see if I can setup a simple page to try to test with.


    Friday, March 13, 2009 1:56 PM
  • User-413041239 posted

    I appreciate ianderson chiming in again. That's exactly the same way I feel.  I think these are the same issues, and he could be right about it being a networking problem with WS08.  If it were, then it would probably explain a couple of other errors that I've been getting on this server as well that are not happening on WS03.  I didn't bring those up right now because I thought it might muddy the waters, but I'm going to anyway.  The other two errors that I get are:
    System.Runtime.InteropServices.COMException (0x800703E3): Unknown Error
    System.Runtime.InteropServices.COMException (0x80070040): The specified network name is no longer available. (Exception from HRESULT: 0x80070040)

    Both of these errors occur when the server is busy.  I haven't gotten them again since we aren't using the server any more for a particualr application.  I've got that same application on a WS03 server, and it's working perfectly. These errors may be related to the other issue, but I'm not sure.

    Anyway, I've checked my netmon capture log, and I've filtered it to only show HTTP requests/responses. However, I'm not 100% sure how to read it.  It has a time offset field, it doesn't show the actual clock time, so how do I figure out what time the activity occurred?  My guess is that the time offset is in seconds. So, looking at this, I can see when a request was made and when a response was sent, and I can tell how long it took.  However, I don't see the clock time that the request/response was made.  All of the response times are very small here,  and without being able to track down the clock time, I'm not sure how to tell which entry could be the one started at 8:50.


    Friday, March 13, 2009 2:08 PM
  • User-413041239 posted

    OK, I've just had it happen again, and I had netmon running for several hours before that.  So, I've got TONS of data.  After making a change to one of my .aspx pages, I hit the F5 button to refresh the screen, and got no immediate response.  It started at about 1:13pm, and I waited for SEVERAL minutes  I wasn't staring at the screen the entire time, so when it actually responded, I really don't know.  But, I do know that by 1:24pm, it had responded,and before 1:18pm, it had not

    Now, I've got all this netmon data. What am I looking for?

    I have checked all of the Windows logs. There is nothing in there for this time.  I have checked the IIS logs, there is also nothing important in there.  The entry for this access is as follows:

    2009-03-19 17:23:03 POST /dlg/tsanat/MemDepGLDet.aspx - 80 - Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+en-US;+rv: 200 0 0 1575

    Once again, this appears to indicate a 1.575 second time to  respond.  So, as indicated earlier, the possible problem appears to be between the request time and getting to the server.  So, maybe the answer is in the netmon data if I only knew what I was looking for??


    Thursday, March 19, 2009 1:41 PM
  • User-413041239 posted

    I guess I've stumped the experts!  There has been no activity on this issue for a while, and I continue to experience the problem. Surely there has to be some way to track this down and fix it???

    We just bought a new server.  In the light of the sort of issues we've been having with IIS8, we decided to get WS03 instead of WS08.  However, we still need to deal with the WS08 server we've got now, and I seriously need help figuring this out.  It's really costing me a lot of time.


    Friday, April 10, 2009 7:45 PM
  • User1940267948 posted

    It seems like this is one of those issues that falls somewhere between 2 companies. It is either something with FireFox or IIS7 and both sides can point to the other as the culprit. This leaves affected users (and developers) out in the cold. I tend to put this one on FireFox, although I would have appreciated some more help from the IIS team to try to determine what the root cause. Frustrating...

    Monday, April 13, 2009 3:10 PM
  • User-2064283741 posted

    Personally I think that this is something to do with the app as well. There are millions of IIS7 sites out there that don't have this problem with FF. But on your winbid site I can recreate it all the time.

    If you can post here/send me a small basic sample of a test case where this happens then I will take a look.

    Monday, April 13, 2009 3:57 PM
  • User1940267948 posted

    Sure, it could be something with our app. Something that is specific to IIS7, and FireFox (only recent builds), and something that has nothing to do with the client-side HTML code (as the client code works fine when hosted on IIS6). Given all of that, do you have any ideas about where the source of this bug might lie? That would be helpful.

    Monday, April 13, 2009 4:10 PM
  • User-2064283741 posted

    To be honest I don't know. I suspect that certain app (I am guessing in asp.NET) configurations are run slightly differently under IIS7/windows 2008 (it could even be at the http.sys level) and newer versions of FF interpret these slightly differently which cause errors.

    So it could be an issue with any of these issues. I suspect that a slight change in the code and these problems will go away. Therefore I would break the site and therefore the problem down in smaller pieces and get the smallest possible areas where it still occurs.

    Analyse this from the packet level to see if there are any more clues. (I am slowly writing a blog article on using netmon to help with IIS problems but there were a few quirks with netmon and I have been speaking to their product team and evangelists in netmon in an attempt to make the system easier to understand)

    Monday, April 13, 2009 4:37 PM
  • User-1965698016 posted

    After months of casual searching, I finally typed in the right phrase, and found someone else with the same problem.  Alas, it looks like you haven't found a solution yet either.

    I've actually got a slightly different setup:


    Hearing that you're getting the same thing with .net leads me to believe that this issue has nothing to do with appilcation code.  Furthermore, I get the issue sporadically across dozens of applications that have been written over the past 5 years.  The same code works just fine on IIS6/Win2k/CF8

    I just got around to installing WireShark right before I found this post, but haven't had a chance to isolate and capture the issue yet.  I did however install sysinternals process monitor on the server and watch the issue occur. The server has such a small load that I'm able to watch the processor spike whenever a request comes in, and sure enough... flatline until right before the request finally came back to the browser.

    I don't suppose anyone has had a revalation on this issue since the last post?

    Thursday, April 30, 2009 4:20 PM
  • User-1965698016 posted
    One more quick thought... is anyone else experiencing this issue running the URL rewrite extension? Trying to think if there's some common variable aside from the standard IIS7 install that could be contributing to this.
    Thursday, April 30, 2009 4:48 PM
  • User1940267948 posted

    Not using URL Rewrite here. I think this issue is more common than people realize. As you discovered, it is hard to classify or search for, and is often quickly dismissed as an "application problem". Hope you have some luck at diagnosing it!

    Thursday, April 30, 2009 5:26 PM
  • User-413041239 posted

     I'm not using URL re-write either, and I've experienced the problem with .net, standard .asp, and I believe once even on a standard .htm page.  So, I agree that it does not seem to be code related.


    Monday, May 4, 2009 8:18 AM
  • User1940267948 posted

    I installed WireShark and captured the issue, although I don't know enough about TCP to make much sense of it. I can see a bunch of TCP Retransmission messages, which don't occur during normal traffic. I would be happy to send the WireShark file to anyone who can help diagnose the problem.


    Tuesday, May 5, 2009 4:13 PM
  • User1940267948 posted

    I have removed all application-code from the loop. I have a test page that is just the HTML source of one of our results pages. It is set to POST back to itself. There is no application-code, no code-behind, and nothing executing on this page on the server. It is only labeled with an .aspx extension to allow an HTTP POST to occur (as IIS disallows POST to .html docs by default). The issue still occurs:


    I still believe this to be a communication issue between IIS7/Server 2008 and FireFox 3+.

    Tuesday, May 5, 2009 5:07 PM
  • User-2064283741 posted

    I have been testing this page and I do not notice any problems with it. I am just refresh the page and it worked every time.

    Also the regular site www.winebid.com seems to function fine as well. I was getting reproducible errors before.

    However I am on another machine XP SP2 with FF 3.0.10 (and otehr corp sofwatre like fairewall, etc) rather than XP SP3 with FF 3.0.9 (the last time I checked) of my home machine to check your site.

    And on a different ISP/corp network also.

    So why is it now working fine? Have you changed your code? Or the server? I imagine not. The only that I can see that has changed is the client setup and now it appears to be all ok using FF 3.0.10?

    Is it if the client machine setup is with XP SP3 AND with new FF AND with certain code AND with WINDOWS 2008/IIS7.0 fails AND maybe certain ISPs/networks it fails.

    I think there are more factors at play than just the what has been identified. Just limiting it to FF 3.0.6+ and WIndows2008/ IIS 7.0 is misleading.

    What user agents are effected? Are there any useragnets that are never effected.

    I am using this user agent string atm

    User-Agent    Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)

    And have been trying to reproduce the error that was every time reproducible on my how machine.

    So why isn't this machine failing?  I would expect it too.

    I cannot compare the client machines/networks side-by-side atm as working away from home.

    Thursday, May 7, 2009 7:00 AM
  • User1940267948 posted

    Rovastar, you have to click on the NEXT link in order to perform a POST. That is the event that causes the issue to occur. Refreshing doesn't test the problem. Also, don't forget to wait about 60 seconds between the initial page load and clicking the link, as that is also a required triggering event.

    Thursday, May 7, 2009 7:24 AM
  • User-2064283741 posted

    On the live site I was going next page.

    (For the test page when you said you removed all the code behind I presumed you had removed the functionality of the buttons, etc so I refreshed.)

    To follow this look at the url (i didn't know what to search for so I just typed 'wine' :) )
    About 10:52:00 AM uk time.

    and subsequent pages from there.

    and get my IP and details from there.

    Then you can track me and see what i did and as you can see the responses were fine.

    Maybe you can do some log file analysis and get a better pattern of the what the useragnet strings are too. 


    Thursday, May 7, 2009 7:33 AM
  • User1940267948 posted

    Looking at the log files I can see you are waiting several minutes between postbacks. That is also a way to avoid the issue. You cannot wait a couple minutes between posts as that seems to clear the issue as well (and is part of the reason why I feel it is related to FireFox's handling of HTTP connections).

    Thursday, May 7, 2009 7:40 AM
  • User1940267948 posted

    Would you like to see the IP traffic of the issue I captured via WireShark? It is definitely different with FireFox compared to MSIE or Safari.

    Thursday, May 7, 2009 7:42 AM
  • User-2064283741 posted

    Looking at the log files I can see you are waiting several minutes between postbacks. That is also a way to avoid the issue. You cannot wait a couple minutes between posts as that seems to clear the issue as well (and is part of the reason why I feel it is related to FireFox's handling of HTTP connections).


    Ummh I thought the longer you left it the more of an issue it was. So there is a peak problem time of say 1 minute and up to what 5 minutes? When a (one of the many) timeout occurs it is all ok again?

    I haven't used wireshark much do you have a netmon output?

    Thursday, May 7, 2009 8:57 AM
  • User-1965698016 posted

     Alrighty, I've got a ticket open with MSDN support and they're looking into the issue.  I was able to reproduce the issue, and provided MS with the following:

    1. Wireshark dump from the client
    2. Wireshark dump from the server
    3. iis log
    4. failed request log

    You can see a whole bunch of black (TCP Retransmissions) on both sides until the request finally comes back.  IIS logs show nothing until all the TCP business gets sorted out, at which point the response is normal. As I suspected, nothing of note in the failed request logs.

    I'll keep the group posted on how this gets resolved.


    Thursday, May 7, 2009 3:12 PM
  • User1940267948 posted

    Fantastic! Great work Paul!

    I actually opened up a case in the FireFox bugtracker to attack the problem from that angle as well:


    Hopefully one of these parties will figure out what the issue is...


    Thursday, May 7, 2009 3:51 PM
  • User-413041239 posted

    Excellent.  I didn't know how to gather some of those logs or how to read them.  I'm glad that someone that knows how to handle that is handling that.  I hope that you'll post results of anything you find to this forum.


    Thursday, May 7, 2009 4:01 PM
  • User1940267948 posted

    The Mozilla team seems to think that IIS7 is not properly closing connections. FireFox apparently holds connections for 5 minutes and attempts to reuse them during this time period. This may be longer than other browsers and may explain why FireFox is the only one that displays this issue. See the updates in the bug report for more details:

    It might be worth asking the MSDN support people to look at how IIS7 (or Windows Server 2008) is closing TCP connections...

    Friday, May 8, 2009 7:43 AM
  • User-2064283741 posted

    Ok so it seems that in some situations that a connection has been left open.

    The firefox people seem to think that they send out the packet information.

    However we still don't know if the server is receiving the packet. If the packet is correct (not corrupted) Then if it has been processed in the TCP/IP stack or then if it is getting to IIS.

    What if it is a dodgy network card/server hardware/etc setup? *shrug*  Did you set the server up or a hosting company?

    If it connections issues you could try increasing your http keepalives timeout from 120 to something more. Hopefully that will give you more functionality.

    What timeout settings are you using for your server? http, asp.net, sessions, etc, etc

    That still doesn't explain why I am not getting any issues at all at the moment. And that too me is even more confusing as it goes against all the investigation that you have made so far as it shouldn't work.

    I just waited 3 minutes on your test page and clicked 'next' and it is all ok.

    Friday, May 8, 2009 8:31 AM
  • User-413041239 posted

    First of all, this will most likely not be a "dodgy network card"  This problem has been duplicated on several different servers. The commonalities are ALWAYS IIS7 and FireFox.  This has been duplicated by MANY different people.  You must wait a specific amount of time before this occurs.  My understanding is if you bring the page up, and wait a little more than 130 seconds (a little over 2 minutes), then try to proceed that the problem will most likely occur.  As was already pointed out too, this does not ALWAYS happen, but it does frequently happen. But, if you change either your browser, or to a different version of IIS (IIS6, for instance), this problem goes away.


    Friday, May 8, 2009 8:45 AM
  • User1940267948 posted

    Please explain to me how it could be a dodgy network card/server that only affects FireFox? You have suggested this numerous times, and each time I have reiterated that the problem is specific to a single browser version. One would expect a dodgy network card (or any hardware issue for that matter) to have problems across the board.

    I believe the reason it is intermittent (i.e. can't be reproduced 100% of the time) has to do with server load. Perhaps IIS/Windows leaves the connection open for a certain period of time until the connection resource is disposed of on the server? Perhaps it does this more often as the server gets more load? That would explain why you have a tuff time reproducing it as you are hitting our site at a very slow time of day (European daytime).

    Friday, May 8, 2009 8:47 AM
  • User-1965698016 posted

    Here is Microsoft's response to the ticket I opened. 

    Firefox is waiting for more than the standard 2 minutes before trying to re-use the connection.

    Firefox never sends "FIN" command(FIN- Finish is used during a graceful session close to show that the sender has no more data to send) to the server, so it cannot re-open the connection.

    IIS times the request out as expected, due to the default 2 minute ConnectionTimeout setting of HTTP.sys.

    The IIS server, however should not be waiting for 9 seconds to send a reset. So we doubt that there could be some issues with the NIC or NIC drivers which initiates this waiting.

    So, the part of the problem here is Firefox trying to reuse an old connection.

    The other problem seems to be with TCP on the server not issuing a timely RST(RST- Reset is an instantaneous abort in both directions (abnormal session disconnection)).


    Let’s  disable TCP chimney and/or update NIC drivers on server.

    Lets run the following command to disable the TCPChimney,

    Netsh int ip set chimney DISABLED

    Unfortunately that command didn't work for me... I kept getting "command not found". So they had me add the following registry entries:

    Lets add the following registry entries and set those values to zero.

    Type: REG_DWORD
    Values: 1 (enabled) 0 (disabled))

    Type: REG_DWORD
    Values: 1 (enabled) 0 (disabled))

    Type: REG_DWORD
    Values: 1 (enabled) 0 (disabled))

    I need to reboot and try to reproduce again, but I figured I'd share what I've got so far in case anyone else has better luck.


    Monday, May 11, 2009 12:11 PM
  • User1940267948 posted

    The 5-minute timeout is probably why the issue is specific to FireFox browsers. MSIE defaults to a 60-sec timeout, which is a shorter window than IIS, so that explains why MSIE appears to be unaffected. I have been testing to try to see if IIS is properly sending a RST to close/cancel the connection after the server timeout is reached, but I don't see IIS responding at all. Seems like either IIS has a bug and it isn't sending the proper RST response, or there is something in the stack that is preventing this command from reaching the browser. Seems like disabling TCPChimney is an attempt by MS to see if the problem lies in the TCP data processing... When it is enabled it appears to pass this off to the network card for handling. Hope disabling it fixes the problem!

    Monday, May 11, 2009 12:25 PM
  • User1940267948 posted

    Also, it seems like a workaround would be to change the IIS connection-timeout to be higher than the FireFox default of 5 minutes. That would ensure that the connections are not closed on the server before FireFox considers them closed. This has implications regarding server resources, so it isn't ideal... but it may resolve the issue for the time being.

    Monday, May 11, 2009 12:26 PM
  • User-2064283741 posted


    Aha the TCP Chimney.

    I have seen some issues with that reported on the forums here. It sounds a little flaky. It seems that the network card process for this is not as good at the CPU.

    So I presume everyone with the problem has TCP Chimney enabled? It is disabled by default hence why didn't initially think of it. If you had a third party or even OEM build of the server they might have enabled.

    It is something that I do not think I will enable at the moment.

    Firefox having it's client timeout set of 5 minutes is strange. Why is it so long? 

    IIS has the longest http keepalive of any web server software at 120 seconds AFAIK the Apache 2 timeout is 15 seconds.

    (IMHO the http keepalive timeout is far too long in IIS and hasn't been changed for years. Microsoft's IIS team have a horrible habit of keep all their default values the same version after version of IIS. I need to run some tests on connection of busy servers to get a better indicatioon of more optimal times.)

    So I don't understand the rational for Firefox to have a timeout of 5 minutes. No webserver software will keep there connection open for that long. So why does the cilent do this? What a waste of resources.

    I'll post something in that firefox thread/bug reports but it does seem a strange one.

    Tuesday, May 12, 2009 4:26 AM
  • User-2064283741 posted

    Also, it seems like a workaround would be to change the IIS connection-timeout to be higher than the FireFox default of 5 minutes. That would ensure that the connections are not closed on the server before FireFox considers them closed. This has implications regarding server resources, so it isn't ideal... but it may resolve the issue for the time being.


    Yeah that should work. It was something I hinted at before in a previous post. It is no huge deal having increased http keep alives it will just have the slight overhead of more connections being open.

    Tuesday, May 12, 2009 4:28 AM
  • User-2064283741 posted

     More on the headaches of the TCP chimney



    Tuesday, May 12, 2009 4:31 AM
  • User-1965698016 posted

    Well, if the TCP Chimney is disabled by default, that would explain why the suggested changes did absolutely nothing. The registry values they had me add didn't exist to begin with, so I was doubtful adding a value of false would change much.

    I'll try increasing the connection timeout to 300 and see what that does.

    Tuesday, May 12, 2009 8:48 AM
  • User1940267948 posted

    I did not enable TCP Chimney, and I do not have any registry settings mentioning it either. It'll be interesting to see what the support staff suggest to try next...

    I made the change to 300 secs on my IIS7 boxes and I can't reproduce the issue, so it seems like that is an effective workaround for those troubled by this issue. Hopefully you have the same experience.

    I also mentioned to the FireFox team that they should consider changing that default timeout as it makes no sense to have such a large default value. If FF didn't have such a large timeout this issue wouldn't even be a problem to begin with!

    Thanks a ton to VorlonShadow and pbreitz for helping to diagnose this incredibly frustrating problem!

    Tuesday, May 12, 2009 8:59 AM
  • User-1965698016 posted

    Actually, before I go increasing the connection timeout, I'm curious what people think would be better:

    1. Increase the connection timeout
    2. Disable HTTP keep-alive

    In theory these should both have an effect, right?  Obviously they're each going to have their own impact on server resources, but which would be better for a site of modest traffic (approx 2000 visitors & 7000 pageviews / day).

    I suppose the higher the pageview/visitor ratio, the more effective a higher connection timeout would be, and vice versa. But I just have no idea what scalar values to attach to each method for purposes of comparing server load.

    Any thoughts?

    Tuesday, May 12, 2009 9:01 AM
  • User1940267948 posted

    From a user-impact perspective I would go with increasing the connection-timeout. If you disable keep-alives altogether then the browsers will have to make tons more connections to your website for each request (resulting in slower page load times and most likely a visible performance decrease for your users). Having a higher timeout just means you'll have a bunch of dead connections hanging around on your server waiting for their 5-minute lifespan to tick away. I would vote for trying the increased timeouts first, and then move to disabling keep-alives as a last resort if you run into some major issue.

    Tuesday, May 12, 2009 9:06 AM
  • User-1965698016 posted

     Thanks ianderson, I've bumped up the connection timeout on a few dev sites and one production site to test things out.  Hopefully I'll have the same experience as you.


    Tuesday, May 12, 2009 9:10 AM
  • User1940267948 posted

    One thing to keep in mind... if you have a load-balancer in between your server and your clients, you'll need to ensure that the balancer has a "sticky" connection timeout of 5 minutes as well. If the load-balancer swaps between two active servers within the 5-minute timeout of FF, then you'll see the same issue.

    Tuesday, May 12, 2009 9:13 AM
  • User-2064283741 posted

    The workaround should work. I would make the keepalive timeout 302 seconds or something just incase you get an overlap.

    In theory yes they should be the same but the behavior is strange so it is unclear what it is.

    The site traffic is so modest I don't think you will notice the difference of either. 

    I would increase the keepalive time rather than disabling. You are unlikely to hit any tcp limits or have much more overhead from these dormant connections. I think this is better than constantly recreating new connections every second.

    As for testing this for comprehensive performance results I'll have to have think about what would be best.

    (Edit: too slow at typing)

    Tuesday, May 12, 2009 9:14 AM
  • User-2064283741 posted

    One thing to keep in mind... if you have a load-balancer in between your server and your clients, you'll need to ensure that the balancer has a "sticky" connection timeout of 5 minutes as well. If the load-balancer swaps between two active servers within the 5-minute timeout of FF, then you'll see the same issue.

    Yeah, Load balancers can add another level of complexity to the http keepalive timeouts. They will need to be sticky. To be safe you can increase this.
    Tuesday, May 12, 2009 9:19 AM
  • User-1965698016 posted

     Just following up for posterity.  Looks like increasing timeout to 300s was a success.  We haven't been able to reproduce the problem since.

    Tuesday, May 19, 2009 4:02 PM
  • User-413041239 posted

     I concur.  Since I've increased my time out, I have not experienced the delay problems.

    Tuesday, May 19, 2009 4:09 PM
  • User-2064283741 posted

    Nice to know that is working. However it doesn't actually solve the problem. Is the case closed now with microsoft?

    Wednesday, May 20, 2009 7:07 AM
  • User-413041239 posted

     I agree with that too.  The "fix" is just a bandaid fix, and should be temporary.  It needs to be fixed on the Microsoft or Firefox side it at all possible.


    Wednesday, May 20, 2009 9:05 AM
  • User1940267948 posted

    The only real issue is on the MS-side. The FireFox default setting just compounds the problem...  but there would be no issue if the server sent the proper connection closing response.

    Wednesday, May 20, 2009 9:12 AM
  • User511787461 posted

    Do you have a netmon trace exhibiting the problem?  I should be able to get tcpip experts here to take a look.  I can see that IIS (actually http.sys) is sending FIN when the server side timeout is hit.  Why do the firefox folks think that is not sufficient?

    Wednesday, May 20, 2009 12:17 PM
  • User1868580765 posted

    I'm having a similar problem and I've tried changing the connection-timeout in IIS to 300 seconds but it's not working for me? We are running Win 2008 Server 32bit with IIS 7. We are a Mac house and use FireFox and Safari on most our machines. Here is our current setup:

    - We have a secure access intranet website that can be access from inside and outside of the office using a domain name. We are using AD and Windows Authentication to verify access.

    - On the intranet website we have online training & HR forms that people fill-in on a regular bases and submit to the HR department.

    We recently noticed that people who are submitting these forms from outside of the office are having timeout issues when using FireFox 3.x. The timeout period seems to be about 2 minutes. If the form is completed and submited in < 2 minutes then all is well. But if the form takes longer than 2 minutes to fill, the submission does nothing. FF just tries to submit the form then eventually displays a blank page or a connection problem message.

    Is there anything else I can try to get around this issue until FF gets fixed?  I appreciate any help you can provide.

    Thank you,


    Saturday, June 13, 2009 10:12 AM
  • User1868580765 posted

    Can any one help? Has this been resolved yet?

    Monday, June 22, 2009 9:30 AM
  • User-413041239 posted

    The "band-aid fix" was to increase the timeout to 3 minutes (read up the thread some to find out more detail).  The problem seems to be a bug in the Microsoft OS that needs to be fixed, but I wouldn't expect that any time soon, so the "band-aid" is all we've got for now.


    Monday, June 22, 2009 4:27 PM
  • User2049170596 posted

    Hi guys,

    I've been reading this thread with interest, and I've been experiencing this issue with one of my web sites since migrating to II7 on Win2008 Server 32bit.  I had no problems under II6 with Win2003 Server.  My browser of choice happens to be MSIE.

     Anyway, I've made sure that KeepAlives are enabled, but I can't find any place to set the value to 302 or even 300.  Where is this setting editted, or how is it to be editted?

    Thank you so much for your help in advance.



    Sunday, June 28, 2009 3:08 PM
  • User511787461 posted

    Navigate to the "Sites" node -> click on "Set Web sites defaults" in the right pane and choose "Connection limits" -> "connection timeout" in the dialog box.

    Thursday, October 22, 2009 7:44 PM
  • User709021487 posted

    I thought I would add to the discussion that this is also an issue with Google Chrome.  I have been experiencing this problem since upgrading to Windows 7.  And am seeing it a lot with my localhost connection as I'm refreshing the page frequently.  I determined it was happening with FF on not IE, but now know that it is also happening with Chrome.  

    I posted a similar thread here...


    Friday, November 6, 2009 4:48 PM
  • User709021487 posted

     Anil, I was wondering if you could affirm what I am seeing as potentially part of this issue. 

    When in FF and the page is not loading, simply "waiting for localhost...".  I can go to IE and load the page fine.  Once I do this it seems to set FF (and chrome) free to load the page as normal.  So when confronted with this problem I refresh the page in IE, and continue working in FF. 

    Does this make sense? And does it seem to align with the potential cause of this issue?

    Friday, November 6, 2009 9:32 PM
  • User511787461 posted

    This does not seem to be the same cause as the issue discussed here - where firefox would hang because it would try to use a connection already timed out by the server.  Your symptoms would suggest that firefox/chrome are having some issues with doing dns lookup for localhost and after IE has done the dns lookup, those guys are able to use the cached dns lookup.  Can you use the instructions at this blog article to collect an etw trace and e-mail them to me at anil (dot) ruia (at) microsoft (dot) com

    Saturday, November 7, 2009 2:53 AM
  • User-1994202689 posted

    I have the same problem - but setting connection timeout setting to 320 doesn't help.... :-Somebody test another solution?




    Friday, November 20, 2009 8:00 AM
  • User-880406344 posted

    Hey Jesse,

    Were you ever able to resolve this?

    I have all the same issues (no-response) on pages using Firefox, but 99% of the time, works in IE.

    All worked fine before switching to Win7-64 with the new IIS.

    Thanks in advance

    Tuesday, January 19, 2010 9:50 PM
  • User-413041239 posted

    I followed the suggestion to increase the connection time-out to 300 seconds in IIS.  I still have the problem every now and then, but it's very rare.  I might experience it once a month now, where before it was 10 times a day.  the setting is in Advanced Settings / Behavior / Connection Settings / Connection time-out (Seconds).  I think the default is 120, and increasing it to 300 worked for me.


    Wednesday, January 20, 2010 8:54 AM
  • User-2009228378 posted

     I too have set the timeout, but continue to experience this issue - but with a more regular frequency. It seems to come and go: I won't have the issue for 2-3 days, then I'll have it continuously for a day.

     I've also noticed that many times clicking in the address bar and hitting ENTER will cause the page to successfully load (as opposed to hitting the refresh button.)

    Thursday, February 25, 2010 1:49 PM
  • User-2009228378 posted

     I also noticed that if I disable my cache in Firefox, the issue seems to be resolved. I ended up downloading an add-on called BetterCache that lets you configure sites to never cache on a per-domain basis, and setting up localhost to never cache - since for me this is only an issue on my local development machine (our production server runs IIS6.)


    Edit: I've since noticed that this only helps sometimes.

    Thursday, February 25, 2010 2:17 PM
  • User-2009228378 posted

     It turns out my issue was two-fold. I was experiencing both the issues with IIS7/Firefox and also similar symptoms caused by the anti-virus software AVG. If you have tried the fixes outlined in this forum and still have the issue, and have AVG installed I would suggest trying uninstalling it. Note that I had tried disabling the AVG add-on for Firefox but it did not resolve the issue. My experience is that AVG must be removed completely.

    Thursday, March 11, 2010 12:09 PM
  • User-49252499 posted

    Has anyone seen this happening with IIS7.5 (WS08R2)? I have an instance where I'm running a PHP app and it will randomly crash the AppPool for the website thus bring the website down.

    Edit: Update I have noticed that it seems like when googlebot goes through my site, its crashing the app. Any ideas?


    Tuesday, April 27, 2010 5:16 PM
  • User-413041239 posted

    Has anyone seen this happening with IIS7.5

    I don't have 7.5, but I have seen it with version 7.  I had a site that sometimes becomes very busy and it crashes the app pool  Re-starting works fine for a little while, and re-booting the server helps some too, but until most of the people get out, there is not a way to recover that I've found.  I've been forced to put my app back on a WS03 server.


    Wednesday, April 28, 2010 8:24 AM
  • User415240220 posted

    We have similar problem and have moved our application to 3 different servers (all Windows server 2008-32bit). I can always reproduce this issue using 'Chrome', but our clients experience this on F.F and I.E as well. 

    Following is TCP/IP behavior in our case for a Chrome session:

    1. Browse a page, wait for 130 seconds or so. Now, when TCP/IP stack on server resets connections it sends RST packet for only one TCP/IP connection, most the times for recent one used by client. Since, the browser doesn't know that all TCP/IP connection have been reset, it does not open a new connection and uses existing one to serve request and this messes up everything. Browser starts sending re-transmissions after incrementing wait intervals. All these re-transmission are received by server.

    2. Rest is same, as soon as browser establishes a new connection with server after ~300 seconds or so it processes it sucessfully and returns response. 

    I tried to capture 'Winsock' events, but it doesn't log anything for such retransmissions which don't get served by server.

    If anybody interested I can send Wireshark dump.

    I would like to add one more point. If we wait for 3 minutes or so server sends RST packets for all remaining connections as well. Even if server doesn't send Chrome sends FIN,ACK to terminate connections.


    Monday, May 3, 2010 10:30 AM
  • User-1972408046 posted

    I am experiencing the same problem with classic asp pages using IE and only IE on 2008 R2 IIS7.5.  It seems the problem is with asp.dll, and ado objects like connection recordset etc... I keep getting server.createobject failed.  But sometimes the pages just work, only to stop again.

    These sites work perfectly on IIS 6.0.  I have migrated 8 sites with minor issues, but this particular site is not reliable.  It also happens to use a javascript script.  I also had to do away with global.asa, it just does not seem to load.


    Anil, is Microsoft aware of all these issues with IIS 7?  Is there a link where Microsoft discusses asp migration from IIS 6 to IIS 7 in a comprehensive way?


    Thank you

    Wednesday, April 13, 2011 1:00 AM
  • User-1672167363 posted

    For the question of Migration IIS http://learn.iis.net/page.aspx/110/changes-in-security-between-iis-60-and-iis-7-and-above/

    Thank you for understanding,



    Wednesday, April 13, 2011 1:33 AM
  • User804046269 posted

    I have the same problem : application error with IIS 7.5, crash .... i try to find where can i increase the https issue but i cant find it

    I find this one : http://technet.microsoft.com/en-us/library/cc772183(v=ws.10).aspx   It's that ?


    Thx u

    Wednesday, March 27, 2013 11:03 AM
  • User-406399410 posted

    Did you try to totally disable your Windows Firewall? i had the same issue, whenever I did a change in any of my .aspx or .cshtml files, I had to wait for around 5 minutes (with chrome and safari). After I disabled my Windows Firewall everything is working fine.

    Wednesday, October 1, 2014 7:59 AM
  • User-49141863 posted


    Did anyone find the solution to this problem. I am also facing a similar issue. I can't turn off the firewall 

    Friday, August 14, 2015 12:19 AM