Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If I try to connect (over Windows file sharing) to a machine that has gone to sleep, I get a timeout followed by "The network path was not found". If I then wake the machine and try again, I still get "The network path was not found" because the connection failure has been cached. If I wait 30 seconds from the initial failure (I've timed this) and then try again I can connect successfully.

I understand this behaviour. My question is: is there any way to shorten the delay before I can try the connection again?

share|improve this question
Have you tried installing the hotfix from: ? – Adam Dec 3 '12 at 22:42
Which Windows version are the 2 computers? And is the network adapter on the sleeping one allowed to wake up the computer? – harrymc Dec 4 '12 at 17:24
@harrymc: Windows 7 x64 SP1. The network adapter is configured to wake on receiving a magic packet, but that's not really relevant to the question. If the two machines are in the same room, I can reproduce this behaviour just as easily without using WOL. – Harry Johnston Dec 4 '12 at 22:44
@Adam: thanks for the suggestion. Installing that hotfix did not reduce the timeout period. – Harry Johnston Dec 4 '12 at 23:09

Another shot in the dark:

Locate and then click the following registry key:


Click the Control subkey Right-click the ServicesPipeTimeout DWORD value, and then click modify -> decimal -> type 60000 (for 60s) -> ok (in your case I would try 10s so: 10000)

If the ServicesPipeTimeout value is not available add the new DWORD value.

I saw this here: Original Article

share|improve this answer
ATTENTION: That's actually the time that the Service Control Manager waits before terminating a starting service and it affects the functioning of all system services. Shortening it could have unpredictable effects including the premature termination of slow-to-start services. Absolutely not recommended. – harrymc Dec 6 '12 at 16:14

A shot in the dark:

The SESSTIMEOUT parameter is apparently still functional on later Windows versions. I base this assumption on the fact that this parameter is mentioned here for Server 2008.

The parameter is found in the registry at :

SESSTIMEOUT is of type DWORD and its value is the number of seconds. Changes are supposed to take effect immediately, but I would still reboot.

share|improve this answer
Thanks for the suggestion. Lowering SESSTIMEOUT to 10 seconds did not reduce the timeout period. Looking at the documentation, I think SESSTIMEOUT probably only applies to activity on established sessions, rather than to establishing new sesssions. – Harry Johnston Dec 5 '12 at 20:40
Another long shot: See SMB2 Client Redirector Caches Explained. Try in the registry at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanworkstation\Paramete‌​rs to create (if not already there) the DWORD values of DirectoryCacheLifetime, FileNotFoundCacheLifetime, FileInfoCacheLifetime and setting them all to zero for no caching. Create first a system restore point, just in case. – harrymc Dec 6 '12 at 16:23
No change, but that article could explain some other odd behaviour I've noticed in certain applications in Windows 7. Thanks! – Harry Johnston Dec 7 '12 at 3:04
Since this doesn't solve my original problem I haven't marked it as the answer, but bounty awarded because the referenced articles were useful in other respects. – Harry Johnston Dec 10 '12 at 20:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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