Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

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: support.microsoft.com/kb/2663418 ? – 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:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet

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 :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .