（从StackOverflow移到此处）
前段时间，我们团队中几乎所有的工作站（Windows XP SP2）在访问networking上的共享时都出现间歇性但频繁的延迟。 通常情况下，第一次访问一段时间内尚未访问的共享导致近30秒的冻结工作站。 然后一切都开始正常工作了。
从Sysinternals使用TCPView我看到，在这个延迟期间，有一个连接到处于SYN_SENT状态的文件服务器上的netbios-ssn端口。
第一次尝试：
为Intranetnetworking适配器禁用TCP / IP上的NetBIOS 。
问题解决了，但我不喜欢操纵我们的集中pipe理的networkingconfiguration的Intranet。
第二次尝试：
仅针对VMWarenetworking适配器（用于主机通信的VMNet1）禁用TCP / IP上的NetBIOS 。
问题再次解决！
我的问题：
附加信息：
我看到了类似的现象。
症状听起来不太相似：Windows资源pipe理器有时会挂起几秒钟，无论是访问本地磁盘还是networking共享。
但经过一番调查，我认为这个挂起是由一个类似的NetBIOS问题引起的。
一些系统细节：
我一整天都在运行Wireshark，在物理适配器上嗅探数据包。 我注意到，每当浏览器同时挂起几秒钟，一个NetBIOS名称服务查询包就被发送到WINS服务器。 这些数据包包含一个VMNet适配器的地址作为其源IP地址！
这是一个可疑的数据包：
Frame 25475 (92 bytes on wire, 92 bytes captured) Ethernet II, Src: 00:16:17:fa:2c:d4 (00:16:17:fa:2c:d4), Dst: 00:15:c5:87:4f:6a (00:15:c5:87:4f:6a) Internet Protocol, Src: 192.168.145.1 (192.168.145.1), Dst: 192.168.10.192 (192.168.10.192) User Datagram Protocol, Src Port: netbios-ns (137), Dst Port: netbios-ns (137) NetBIOS Name Service Transaction ID: 0x82a5 Flags: 0x0000 (Name query) Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0 Queries *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>: type NBSTAT, class IN 我认为这是不正确的。 数据包的源IP地址应该设置为192.168.10.111。
我没有在WINS服务器的接口上嗅探数据包。 但我期望它通过它的默认网关发送一个192.168.145.1的回复，因为它没有连接到192.168.145.0networking。 网关应该拒绝“无法访问networking”的数据包。
由于这是一个UDP数据包，在SYN_SENT状态下没有连接。 但是一个TCP SYN数据包以同样的方式“损坏”，应该把连接保持在SYN_SENT状态，直到发生超时。
有些事情我试图解决这个问题：
我已经在networking连接 – >高级 – >高级设置 ，以及通过运行netsh接口IP显示configuration检查适配器sorting。 本地连接是在两个地方列出的第一个连接。
此外，我注意到一些NTP数据包的源IP地址为192.168.137.1，以及192.168.145.1通过物理适配器发送到192.168.10.192（这是一个AD DC）。
这里同样的问题。 使用wireshark捕获可疑数据包：协议：NBNS，信息：名称查询NBSTAT
来自vmnet8的IP数据包在物理networking上发送尽pipeNAT已configuration！
看来，这个奇怪的NetBIOS的东西没有NAT的vmware！
冈特。
我的经验发现，Vmware NAT是有限的能力。 在其他networking模式下，也不返回某些types的数据包。 我认为这是Vmware处理networking数据的一个错误。