I have seen a similar phenomen.
Symptoms sound not too similar at first sight: Windows Explorer sometimes hangs for a few seconds regardless whether a local disk or a network share is accessed.
But after some investigation I believe the hang is caused by a similar NetBIOS issue.
Some system details:
- Windows XP Pro SP3
- VMware Server 1.0.9 installed
- VMNet1 (host-only) network adapter
and NetBOIS over TCP/IP enabled
- VMNet8 (NAT) network adapter and
NetBOIS over TCP/IP enabled
- The system's only physical network
adapter's static IP address is
192.168.10.111. This adapter is configured to use 192.168.10.192 as
its only WINS server. MAC address:
00-16-17-FA-2C-D4
- On the VMNet1 adapter the system's
static IP address is 192.168.137.1.
No WINS server configured. MAC
address: 00-50-56-C0-00-01
- On the VMNet8 adapter the system's
static address is 192.168.145.1. No
WINS server configured. MAC address:
00-50-56-C0-00-08
- All VMs are configured to use NAT but
are stopped anyway.
I was running Wireshark all day sniffing packets on the physical adapter. I noticed that whenever Explorer hung for a few seconds simultaneously a NetBIOS Name Service query packet was sent to the WINS server. These packets contained one of the VMNet adapter's address as its source IP address!
Here's one of the suspicious packets:
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
I think this is not correct. The packet's source IP address should be set to 192.168.10.111 instead.
I haven't sniffed packets on the WINS server's interface. But I expect it to send a reply to 192.168.145.1 via its default gateway since it is not connected to the 192.168.145.0 network. The gateway should reject this packet with "network unreachable".
As this is a UDP packet there's no connection in SYN_SENT state. But a TCP SYN packet that is "corrupted" in the same way should leave the connection in SYN_SENT state until a timeout occurs.
Some things I tried to work around this problem:
- Disable both the VMNet adapters:
Problem solved. No suspicious
packets.
- Re-enable VMnet1: Explorer starts
again hanging sometimes. Suspicious
packets with source 192.168.137.1.
- Disable VMNet1 and re-enable VMNet8:
Explorer hangs sometimes. Suspicious
packets with source 192.168.145.1.
- Enable both the VMNet adapters, but
disable NetBIOS over TCP/IP for
both: Problem solved. No suspicious
packets.
- Re-enable NetBIOS over TCP/IP for
VMNet1: Explorer starts again
hanging sometimes. Suspicious
packets with source 192.168.137.1.
- Disable NetBIOS over TCP/IP for
VMNet1 and re-enable it for VMNet8:
Explorer hangs sometimes. Suspicious
packets with source 192.168.145.1.
- Change interface metrics from
automatic metric to static values
for all interfaces. The LAN adapter
having the lowest metric: Explorer
still hangs sometimes and suspicious
packtes captured.
I have checked adapter ordering in Network Connections->Advanced->Advanced Settings as well as by running netsh interface ip show config. Local Area Connection is the first connection listed in both places.
Additionally I noticed some NTP packets with source IP address 192.168.137.1 as well as 192.168.145.1 being sent to 192.168.10.192 (it's an AD DC) via the physical adapter.