Recently, the MS PSS team received some reports regarding issues happening on the Windows Vista computers located in a domain. The typical symptom sounds like:
-Indefinite delay (hang) when opening the Certificate Services snap-in
-Slow (sometimes no) group policy application
-Trying to select a domain user in order to add that principal to a local security group (the object picker) would hang indefinitely
-Instant Messaging was not working well (sometimes not at all)
-Access to local file servers was slow and sometimes did not succeed at all (appears to hang).
In some scenarios, users cannot copy files from a network share to the Vista box from Windows 2000/2003 shares. The error is:
"You do not have permissions to perform this action"
"access is denied."
With intensive testing, we can copy a .txt type of file (text, log, etc) as long as it is less than 4K, while any other type of file (.doc, .xls) fails regardless of size.
This issue is finally determined to be linked to a new feature included with the Vista -TCP Auto Tuning, which uses a scaling factor communication between the server and client, to negotiate a bigger window size during connection establishment so that more traffic can be transported in less time. Windows XP and earlier versions do not have this feature.
Here’s a bit more on that:
Note: Some Internet gateway devices and firewalls block packet flows because they do not correctly interpret the scaling factor used in TCP connections. Because of this, Internet Explorer in Windows Vista uses an initial scaling factor of 2. Other applications use a default initial scaling factor of 8. Microsoft is investigating changing the initial scaling factor for Internet Explorer-based connections to 8 in a future update of Windows Vista. Microsoft is working with the manufacturers of these devices so that they can be updated for compliance with TCP window scaling.
To see if this issue applies to you, first see if the criteria and symptoms mentioned above apply. If they do, please take some traces. The TCP Auto Tuning can be seen in the packets like these truncated samples:
Working (no problem seen):
...TCP\Window: 8192 (scale factor 0) = 8192
......WindowsScaleFactor not listed
Failing (problem supremely evident and most annoying):
...TCP\Window: 8192 (scale factor 8) = 2097152
......type: Windows scale factor. 3(0x3)
......Length: 3 (0x3)
......ShiftCount: 8 (0x8)
If the above symptom appears, we can try disabling this feature as a workaround and this will certainly tell the tale on what the problem is if the issue no longer happens afterward. From a command prompt:
netsh interface tcp set global autotuninglevel=disabled
If the issue no longer occurs, this reveals that you have a network device in your environment that doesn’t support RFC 1323 “TCP Extensions for High Performance”.
Windows Vista Auto-Tuning TCP Scaling, FireFox connection problems, Linksys rout
If Vista users using firefox 126.96.36.199 are having problems with a website you are running on an older Linux server, upgrading the kernel from a 2.4.xx to a 2.6.xx kernel will fix the problem.
I was having trouble using FireFox on Vista, I do not really care to use FireFox at all anymore (now
Forgive a newbie, but if we've got one application in particular giving us trouble, is there something less 'global' than "netsh interface tcp set global autotuninglevel=disabled"?
I tried it, and it fixed my problem. (My problem was with Subversion.) However, everything else seems to be working fine. Am I fooling myself? If not, can I turn off autotuning for a particular application or for particular destinations/ports?
We were having problems connecting to servers with RDP during a Remote Web Workplace session. The RDP logon screen would hang. This only happened when our Vista laptops were connected to the domain either on the local network or with VPN. Disabling TCP autotuning did the trick:
netsh interface tcp set global autotuning=disabled
Hi, regarding the note about IE7 using highly restricted autolevel. How can I force my application to to do the same without changing global tcp stack settings ?
For application developers:
use SIO_SET_COMPATIBILITY_MODE option of
Read more at:
My name is Elena. To me of 20 years.
I would like to get acquainted with you if you not against.
I Look forward to hear you soon with impatience. <a href="http://toplop.com/?idAff=59">Adult">http://toplop.com/?idAff=59">Adult Dating</a>[url=http://toplop.com/?idAff=59]Adult Dating[/url]
Is there any way that we can get rather more help from Microsoft on this disastrous issue?
i) a comprehensive test tool to definitively identify this specific issue in routers, with very detailed reporting,
ii) MS to help build up a definitive list of known good/bad router firmware versions, to save us all having to repeat the same tests,
iii) using Microsoft's might to put pressure on specific router manufacturers to get timely firmware fixes? (most important of all)
I have just found an interesting forum on this theme