Microsoft KB Archive/187735

= Delay in NetBIOS Connections from a Multihomed Computer =

Article ID: 187735

Article Last Modified on 11/1/2006

-

APPLIES TO


 * Microsoft Windows NT Server 4.0 Standard Edition
 * Microsoft Windows NT Workstation 4.0 Developer Edition

-



This article was previously published under Q187735



SYMPTOMS
When a NetBIOS connection is established from a multihomed computer running TCP/IP protocol to another computer, it might experience a delay in completing the connection.

On versions of Windows NT earlier than Windows NT 4.0 Service Pack 3 (SP3), a multihomed computer will always try to establish a NetBIOS session using the primary transport bound to the redirector before it tries other transports.

For additional information about this feature, please see the following article:

ARTICLE-ID: 166159

TITLE : NetBIOS Connections from a Multihomed Computer



CAUSE
When the redirector accepts the first transport that responds to complete the call, it will issue cancel calls to the primary transport and all other transports if applicable. It will then wait until all cancels are returned before it continues with the session setup process on the accepted transport. NetBT does not respond to a cancel call immediately until its session setup is complete or times out (that is, going through all its name resolution methods). This will cause a redirector delay in the session setup on the accepted transport.



RESOLUTION
To resolve this problem, contact Microsoft Technical Support to obtain the following fix, or wait for the next Windows NT service pack.

This fix should have the following time stamp:



STATUS
Microsoft has confirmed this to be a problem in Windows NT version 4.0.

A supported fix is now available, but has not been fully regression tested and should be applied only to systems experiencing this specific problem. Unless you are severely impacted by this specific problem, Microsoft recommends that you wait for the next service pack that contains this fix. Contact Microsoft Technical Support for more information.



MORE INFORMATION
This problem and hotfix do not apply to Windows Sockets-based connections. When a Windows Sockets application places a call from a multi-homed host the best local source address is chosen automatically (using the route table), unless the application specifies otherwise by choosing a local IP address to use in the bind call.

This behavior was changed in Windows NT Service Pack 3, where you can set a registry parameter that causes the redirector to accept the first transport to complete a call, rather than waiting for success or failure on the primary transport.

Additional query words: Netbios wait

Keywords: kbhotfixserver kbqfe kbbug kbfix KB187735

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.