The focus of this thread is to understand the expected behaviour of the Windows 7 TCP Stack and Adapter Cards on resume from sleep/hibernation -not- to post suggestions that have been posted in other threads. I also wanted to gather some of the folklore relating to this issue in one place ...
There appears to be a body of people having this issue Windows 7 "no DNS (or no network) after resume (wake up) from sleep (or hibernation)" without definitive (or with various) answers as to what the issue is.
Doing some reading on this in various places I see:
- Suggestions to disable UPnP. This should be largely irrelevant to the problem.
- Reset router to factory defaults. This should typically not be necessary.
- Reinstall Windows 7 (ah yes, the panacea for all ills!).
- Change from DHCP to Static IP. This should not be necessary (considered a workaround at best).
- - If it solves the problem it points the finger at DHCP functionality/state on resume from sleep?
- Disable firewall. This should not be an issue (why would it be).
- - If it is an issue, it is likely to be one in isolated, rather than the majority of cases.
- VMWare (or similar) Virtual Networks.
- - This could be an issue for some people. It would be useful for anyone having a problem to confirm if they have VMWare or similar virtualisation products installed (those which may create virtual networks).
- Disable TCP auto tuning (TCP Sliding Windows).
- - It is possible that TCP auto tuning could be a problem for some people -but- unlikely it would be an issue for people purely on resume from sleep. I suspect anyone having issues relating to TCP auto tuning (TCP Sliding Windows) would have intermittent connectivity issues rather than issues on resume.
- - Some people report improved performance when the turn off this feature. MSFT report from 10x to 1000x performance in lab. conditions. This is one you'll have to test yourself to see if it helps or otherwise.
- - - NETSH INTERFACT TCP SET GLOBAL AUTOTUNING=DISABLED
- - - NETSH INTERFACT TCP SET GLOBAL AUTOTUNING=NORMAL
- It works on XP but not on Windows 7?
- - It is commented widely enough that the TCP stack has been re-written/improved through Vista and Windows 7. It is no surprise therefore that problems occur on Windows 7 that do not occur on Windows XP. This does not necessarily imply that the Windows 7 stck is buggy, just that not all software and devices in the TCP food chain are speaking the same/current language (for want of a better technical description).
- - One wonders therefore are the issues related purely to additional tuning/offloading optimisations that have been made in the new TCP stack? How does that tie up with issues that occur only on resume from sleep/hibernation?
- Some people recommended preventing the system from powering down their adapter cards during sleep/hibernation. Does this imply:
- - That the card is not stateful.
- - If the card is allowed to be powered down then there will be a disconnect between the state recorded in Windows and the state represented (none) in the card when the system is brought out of sleep (or hibernate).
- - - Perhaps this is something that needs to be addressed in the Windows 7 TCP stack/sleep functions - how to handle/recover the situation when the NIC is powered down?
- - If we are putting systems to sleep, do we want to have to have power supplied to the adapters, or not (what are the implications)?
- - Are people having the same issue for hibernate?
- - If there is a state issue relating to adapters, could that be why in some cases people have resolve the problem by turning off optimisations that involve some processing being handed off to the adapter cards rather than being performed using the CPUs. If it were kept in the CPUs, would we have consistent state on resume (versus the adapter cards)?
I think what I would like to understand from MSFT here is:
- What is the designed behaviour in the revised stack for ensuring consistent state between the adapter, stack, previously obtained DNS, DHCP settings, etc, on resume from sleep/hibernation.
- Unlikely connections persist through sleep/hibernate - so are they remembered/re-established?
- Does Windows 7 need more work to handle this properly for cards that --are-- powered down during sleep?
- Is it a requirement of MSFT at this time that for a clean resume, the adapter card should remain powered on?
Some discussion from MSFT on how this is supposed to work would be useful. Then maybe the hundreds if not thousands of people experiencing this issue can understand correctly why it occurs and how they can address it.
[ to the floor ....]
