PO Box 1214 • La Pine • Oregon • 97739 • 541-410-2760

 

M
a
i
n

Home

  • Tech Notes
  • Showcase
  • What We Do
  • Downloads
  • Store
  • IMO
  • Contact Us
  •  
    Windows Server Auto-disconect Bug

    Windows Server Auto-disconect Bug

    Synopsis:

    There are actually two bugs, that I know of, that can be covered by this title. Unfortunately in the workplace they often work together to create a large amount of trouble. The first issue is a Windows NT, 2000, XP and 2003 (I haven't tested beyond 2003) issue, which results in client sessions being dropped. The second issue involves Windows 98 and 98se. The workstation will simply forget it has a connection to the server and create a new one ignoring the first. When using applications that share files, specifically database files, and all clients have to be able to access the files in a synchronized manner, these issues become real ugly.

    Windows NT, 2000, XP, 2003 (WinNT) and probably beyond:

    This bug involves a feature called "Autodisconnect". According to Microsoft documentation (knowledge base article Q138365) it's supposed to shutdown connections that don't have any open files and after the connection has remained idle for a specified period of time. If the autodisconnect feature did what it was supposed to all things would be well. However it appears that this isn't the case. Through experience I've been able to prove that what usually happens is that the connections are dropped after they have been in use for that period of time, whether or not files are still open.

    The problem tends to manifest itself with error messages telling you that a network resource is unavailable. When you browse for it through "My Computer" or "Network Neighborhood" you find the resource intact. In other situations the programs that you're running may freeze up. In general programs don't behave well when the files they are using suddenly disappear.

    Windows workstations are programmed to automatically reconnect to their servers after the connection was closed and some resource on that server is being requested. This is why you can browse for the files, even re-open them, and everything appears to be working correctly. This makes it difficult to diagnose the problem and tends to make it look like there is some piece of hardware failing.

    The problem is easiest to reproduce with a Linux workstation with an old samba client, because those clients didn't perform an auto-reconnect. What I would typically see was that the connection could remain up and active as long as I didn't use it. After I had used the connection for the specified period of time the connection would get dropped, even if files were still in use.

    I was migrating files from one Windows 2000 server to another when I noticed this bug raised its ugly head once again. From a command prompt, on the client side, I would use the XCOPY utility to start copying files from the server to the client. It would copy happily along until the specified time limit and then it would crash saying it couldn't find the file it had been happily copying. I could then use DIR to discover that the file was still there. I could then restart the XCOPY process from where it had died and continue on till the time expired again (about 18 minutes on 2000) .

    This problem is pretty easy to fix. All that has to be done is to set the time limit to its maximum, which makes the autodisconnect time about 8,171 years (according to MS). This should effectively turn off the feature. You can do this in one of two ways:

    1. Issue the following command at the command prompt:

      net config server /autodisconnect:-1
      	
    2. In the registry set the "HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters\Autodisconnect" to 4294967295.

    Microsoft recommends using the registry method. Unless you are experienced at manipulating the registry it is recommended that you have an experienced tech. perform this operation for you. It is possible to adversely affect your system if this isn't done properly.

    Since MS has let this bug live for so long I doubt they have fixed it in newer versions of the their OSes. Their solution has been to push developers into using SQL server, which has other advantages. It will still break software that needs access to a file for long periods of time. The command line seems to be the most affected as "Explorer" the GUI file manager / shell seems to auto-reconnect better. Even the command prompt has improved with time. More recent xcopy runs showed that the drive would come back automatically after xcopy failed. Where as prior versions you would have to "click" into the drive again with "My Computer".

    Windows 98 & 98se (Win98):

    There was an issue with this version of Windows that caused it to forget about established connections when using mapped drives. In most situations mapped drives are still very useful, especially when using software that shares centrally stored database files with other clients. You would typically see messages about files no longer being available, programs appear to freeze (on multiple workstations) or strange messages about network issues.

    Because of the way software attempts to synchronize multiple stations accessing a single source of data on a network the symptoms get spread to multiple clients on the network. This can make it seem like you have a server or network hub related issue.

    What really happens is that a workstation will forget that it has a connection to the server and spawn a new one to handle continuing data requests. However file and record locks on the previous connection will remain locked on the server, but the client will have no knowledge of them. At this point any client, including the station that caused the problem, can hang or time out with a network connection error while waiting for the lock to be released. because the connection is no longer remembered by the client it is probable that the locks won't be released. Of course locks aren't the only thing that might not get updated.

    If you look on the server you're likely to find a single user logged on twice. If you have a situation where a user name is shared by multiple physical users it would be difficult to detect this event. In those cases its easiest to logout all users and go to the server to force off any remaining users. When everyone logs back in things will work again for a while.

    Due to the age of this produc the Microsoft patches for it don't seem to be available anymore. The patch would fix the bug in most situations. It may also be helpful to make sure that client side caching and opportunistic locking is turned off.