Eu vi um fenómeno semelhante.
Os sintomas não parecem muito semelhantes à primeira vista: às vezes, o Windows Explorer trava por alguns segundos, independentemente de um disco local ou de um compartilhamento de rede ser acessado.
Mas depois de algumas investigações, acredito que o problema tenha sido causado por um problema semelhante de NetBIOS.
Alguns detalhes do sistema:
- Windows XP Pro SP3
- VMware Server 1.0.9 instalado
- Adaptador de rede VMNet1 (apenas host) e NetBOIS sobre TCP / IP ativado
- Adaptador de rede VMNet8 (NAT) e NetBOIS sobre TCP / IP ativado
- A única rede física do sistema endereço IP estático do adaptador é 192.168.10.111. Este adaptador está configurado para usar 192.168.10.192 como seu único servidor WINS. Endereço MAC: 00-16-17-FA-2C-D4
- No adaptador VMNet1, o sistema endereço IP estático é 192.168.137.1. Nenhum servidor WINS configurado. MAC endereço: 00-50-56-C0-00-01
- No adaptador VMNet8, o sistema endereço estático é 192.168.145.1. Não Servidor WINS configurado. Endereço MAC: 00-50-56-C0-00-08
- Todas as VMs estão configuradas para usar NAT, mas estão parados de qualquer maneira.
Eu estava executando o Wireshark todos os dias farejando pacotes no adaptador físico. Notei que sempre que o Explorer ficava pendurado por alguns segundos simultaneamente, um pacote de consulta do Serviço de Nomes de NetBIOS era enviado ao servidor WINS. Esses pacotes continham um dos endereços do adaptador VMNet como seu endereço IP de origem!
Aqui está um dos pacotes suspeitos:
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
Acho que isso não está correto. O endereço IP de origem do pacote deve ser definido como 192.168.10.111.
Eu não cheirei pacotes na interface do servidor WINS. Mas eu espero que ele envie uma resposta para 192.168.145.1 através de seu gateway padrão, já que ele não está conectado à rede 192.168.145.0. O gateway deve rejeitar este pacote com "rede inacessível".
Como este é um pacote UDP, não há conexão no estado SYN_SENT. Mas um pacote TCP SYN que é "corrompido" da mesma maneira deve deixar a conexão no estado SYN_SENT até que ocorra um tempo limite.
Algumas coisas que tentei resolver este problema:
- Desative os dois adaptadores VMNet: Problema resolvido. Não suspeito pacotes.
- Reativar VMnet1: o Explorer é iniciado novamente pendurado às vezes. Suspeito pacotes com fonte 192.168.137.1.
- Desative o VMNet1 e reative o VMNet8: Explorador trava às vezes. Suspeito pacotes com fonte 192.168.145.1.
- Ativar os adaptadores VMNet, mas desativar o NetBIOS sobre TCP / IP para ambos: problema resolvido. Não suspeito pacotes.
- Reativar NetBIOS sobre TCP / IP para VMNet1: o Explorer é iniciado novamente pendurado às vezes. Suspeito pacotes com fonte 192.168.137.1.
- Desativar o NetBIOS sobre TCP / IP para VMNet1 e reativá-lo para o VMNet8: Explorador trava às vezes. Suspeito pacotes com fonte 192.168.145.1.
- Alterar as métricas da interface de métrica automática para valores estáticos para todas as interfaces. O adaptador de rede local tendo a menor métrica: Explorer ainda trava às vezes e suspeito pacotes capturados.
Eu verifiquei o pedido do adaptador em Network Connections- > Advanced- > Advanced Settings , assim como executando netsh interface ip show config . Conexão local é a primeira conexão listada em ambos os lugares.
Além disso, notei que alguns pacotes NTP com endereço IP de origem 192.168.137.1 e 192.168.145.1 foram enviados para 192.168.10.192 (é um AD DC) através do adaptador físico.