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.
Are you using the -T flag on vmrun to indicate that the target is a vmware player?:
-T <hostType> (ws|server|server1|fusion|esx|vc|player)
I was able to run suspend with:
$ vmrun -T player suspend /export/vmware/cmp/cmp.vmx
That's with the player version (3.0.0 build-203739) included in VMWare Workstation 7 (on Ubuntu 9.10).
Best Answer
I guess to mark this question as answered, I need to post an answer, not a comment...
Below is the resolution that worked for me. I hate having any extra networking protocols/bindings, they always seem to cause impossible-to-troubleshoot networking problems like this.
I removed 2 networking protocols and did restore defaults in the vmware network tool, and that seemed to resolve this problem. For good measure I disabled antivirus and firewall. The 2 protocols were: Cisco Discovery Protocol Packet Driver and iPass 802.1x. These were removed by uninstalling a Cisco Voip softphone and iPass client software (for logging into pay wifi networks). Both were part of the standard build on this PC, and luckily I didn't need either. Perhaps reinstalling them after VMware would work if I needed them. Hope somebody finds this helpful!