Greetings Gurus, FYI, I am cross posting this to the IIS forums as well as I'm not certain what, exactly, is causing my issue. I have a Windows 2003 server running IIS 6 and hosting a fairly straightforward ASP based site which consults a database and serves report files for download by our clients. This environment has only been in production for a couple of weeks and in the last 2 days we've been getting reports of the search results frame occasionally appearing as Page Not Found. It doesn't occur all the time, but if we get enough sessions going we can eventuallyreplicate the issue. I did so today while running WireShark and what I saw was that when this occurs the request comes inproperly formed (the server responded to it correctly 5 minutes prior) but the server responds this time immediately with a RST packet which the browser interprets correctly as page not found. The fact this is occuring is odd in and of itself, but what's even odder is that it's a badly formed RST packet.Per Wireshark:The acknowledge field is nonzero while the ACK flag is not set. I have seen this type ofissue discussed in various forums I found through google searches, but I haven't seen a good resolution. The IIS log files don't appear to contain anything out of the ordinary (all the log linesaround that timeare status 200) and neither do any of the server's event logs during that time. Any help would be greatly appreciated. Thanks, Scott

hi there, RST genereally or 98% of times are related to application, which means application sends a reset on the port for many reasons. So primarily you are on right track to troubleshoot applciation in the first phase. But yes , there is a NDIS stack which is also responsible for the packet loss and which might occur in a reset and sometimes i would suspect the hardware. a) try changing NIC card / update the NIC drivers to check if the behavior exists.b) Is there any data loss ?c) how are you overcoming the issue ? sainath !analyze

Greetings Gurus, FYI, I am cross posting this to the IIS forums as well as I'm not certain what, exactly, is causing my issue. I have a Windows 2003 server running IIS 6 and hosting a fairly straightforward ASP based site which consults a database and serves report files for download by our clients. This environment has only been in production for a couple of weeks and in the last 2 days we've been getting reports of the search results frame occasionally appearing as Page Not Found. It doesn't occur all the time, but if we get enough sessions going we can eventually replicate the issue. I did so today while running WireShark and what I saw was that when this occurs the request comes in properly formed (the server responded to it correctly 5 minutes prior) but the server responds this time immediately with a RST packet which the browser interprets correctly as page not found. The fact this is occuring is odd in and of itself, but what's even odder is that it's a badly formed RST packet. Per Wireshark: The acknowledge field is nonzero while the ACK flag is not set. I have seen this type of issue discussed in various forums I found through google searches, but I haven't seen a good resolution. The IIS log files don't appear to contain anything out of the ordinary (all the log lines around that time are status 200) and neither do any of the server's event logs during that time. Any help would be greatly appreciated. Thanks, Scott We have exactly the same problem when report executed 10 mins or more: IIS sends data back but the format is incorrect (The acknowledge field is nonzero while the ACK flag is not set) No solution found for 2 weeks We can't control the servers directly Any idea what we can try to fix the issue? Nick

Hi Nick, Our problem turned out to be use of the OneConnect feature on an F5 Load balancer we were using that didn't handle large POSTs well. Basically, the OneConnect feature was keeping TCP sessions open longer than the server was willing to allow which caused it to send out RSTs. Our options were to disable the feature that wasn't really adding a lot of value for us or chasing down the TCP timeout settings on the server and matching them to the OneConnect timers and the latter seemed like a lot more hassle than it was worth to us so we went with the former and the site has been stable ever since. Here's the link to the discussion and resolution in the IIS forums: http://forums.iis.net/p/1158787/1908444.aspx Hope this helps, Scott