'NBTSTAT -R' wont purge remote NetBIOS names for XP-Home Workgroup!

[Nexus9er]

'NBTSTAT -R' wont purge remote NetBIOS names for XP-Home Workgroup, thus wrong IP! Can't Share!!

I have a simple home network consisting of a dlink G router, a dlink G repeater (correctly configured to boost the signal strength), and 3 computers belonging to the same Workgroup. One computer is running Vista32-Home, the other XP-Pro SP3, and the problem computer is XP-Home SP3. I don't have a WINS server, or use any LMHOSTS on any of the machines. I am simply using DHCP from the router and NetBIOS over TCP/IP.

The XP-Home computer will stop being able to browse the other Shares across the network when either of the other computer leaves and then rejoins the network and is assigned a new IP.

Notice that when I try and Purge the remote name table, it says the purge is successful, but if I follow by immedietly typing 'nbtstat -c' it shows that the name table is still lingering.

After leaving and then rejoining the network the other two computers, are assigned new IPs by DHCP from the router. But on this one XP-Home computer, the old IP Addresses are held onto and not resolved to the new addresses.

I've tried 'arp -d *', 'ipconfig /flushdns' (and renew), tried 'Repair' on the wireless adapter. But no matter what I do, the names are resolved to the old NetBIOS IP Addresses!

This means I can't share across my network, I can't browse folders, 'My Network Places' keeps saying: "The network path was not found."

I am sure it is a problem with this one laptop, because one of the other computers is running XP-Pro and I cannot duplicate this error on that machine. On that computer, the remote NetBIOS name table is purged correctly so that when one of the other computers re-joins the network it correctly discovers the newly changed IP.

Here is the result of the two other computers leaving and then rejoining the network and then 'nbtstat -c'. Notice the <20> addresses (Server service) are still there from before and have the wrong IP!

Does this make any sense? Any ideas on why I can't get the correct IP Address to be resolved by NetBIOS, and why the old IPs are not being purged?

Thank you so much in advance for your time and for any help you might lend me!

~ Nexus9er

 

[riser]

Interesting issue.

Try NBTStat -RR

Check your Host file as well: C:\windows\system32\drivers\etc\hosts

It might have a static set address in there.

 

[Nexus9er]

Try NBTStat -RR

Check your Host file as well: C:\windows\system32\drivers\etc\hosts

It might have a static set address in there.

Thanks Riser for the fast reply.

NBTStat -RR has no effect on the problem. I checked the HOSTS file, nothing in there either.

Once these NetBIOS IPs get in they don't seem to get out unless I reboot. I don't understand it, nor why my other XP machine works fine on this network. I wish I could find out where the remote NetBIOS addresses are stored. I am about at the end of my rope with this problem.

 

[Nexus9er]

UPDATE: I have SOLVED my own problem!

For the sake of any others who may suffer this problem I will post what I have uncovered.

After carefully researching and studying the problem I began to suspect that perhaps I had a Layered Service Provider (LSP) affecting my Winsock. But after installing and running Sysinternal's Autoruns and also from looking through MSInfo32 - Network - Protocol, I could find nothing that pointed to a corrupted winsock. The KB article http://support.microsoft.com/kb/811259 offered help but I found it to be misleading in many ways.

I also discovered that all the advice online about resetting Winsock entries and the TCP/IP stack by typing:
netsh winsock reset catalog
netsh int ip reset resetlog.txt

...didn't really help much either since it does not reset the MSAFD NetBIOS entries in the Winsock keys -- at least not on my WinXP SP3 Home computer. And these are the entries that I suspect are causing my difficulties with names not being purged from the NetBIOS Remote Cache Name Table. Those commands will however successfully reset the first four entries: MSAFD Tcpip [TCP/IP], MSAFD Tcpip [UDP/IP], RSVP UDP Service Provider and RSVP TCP Service Provider. But what about the other ones?

When I first peered into the Protocol page in MSInfo32, I discovered way more entries then what the microsoft article could explain:

MSAFD Tcpip [TCP/IP]
MSAFD Tcpip [UDP/IP]
RSVP UDP Service Provider
RSVP TCP Service Provider
MSAFD Tcpip [TCP/IPv6]
MSAFD Tcpip [UDP/IPv6]
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{1579CABA-...}] SEQPACKET 7
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{1579CABA-...}] DATAGRAM 7
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{AEF3C58D-...}] SEQPACKET 4
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{AEF3C58D-...}] DATAGRAM 4
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{93E9068C-...}] SEQPACKET 5
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{93E9068C-...}] DATAGRAM 5
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{9CD47064-...}] SEQPACKET 6
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{9CD47064-...}] DATAGRAM 6
MSAFD NetBIOS [\Device\NetBT_Tcpip_{1579CABA-...}] SEQPACKET 8
MSAFD NetBIOS [\Device\NetBT_Tcpip_{1579CABA-...}] DATAGRAM 8
MSAFD NetBIOS [\Device\NetBT_Tcpip_{93E9068C-...}] SEQPACKET 3
MSAFD NetBIOS [\Device\NetBT_Tcpip_{93E9068C-...}] DATAGRAM 3
MSAFD NetBIOS [\Device\NetBT_Tcpip_{AEF3C58D-...}] SEQPACKET 0
MSAFD NetBIOS [\Device\NetBT_Tcpip_{AEF3C58D-...}] DATAGRAM 0
MSAFD NetBIOS [\Device\NetBT_Tcpip_{F10AE339-...}] SEQPACKET 1
MSAFD NetBIOS [\Device\NetBT_Tcpip_{F10AE339-...}] DATAGRAM 1
MSAFD NetBIOS [\Device\NetBT_Tcpip_{DBE3C768-...}] SEQPACKET 2
MSAFD NetBIOS [\Device\NetBT_Tcpip_{DBE3C768-...}] DATAGRAM 2

So I went into Network Connections - Advanced and removed ALL of the 'Optional Networking Components' and then also went into Network Connections and uninstalled IPv6 on one of the adapters (applies to all adapters). I ended up with this:

MSAFD Tcpip [TCP/IP]
MSAFD Tcpip [UDP/IP]
RSVP UDP Service Provider
RSVP TCP Service Provider
MSAFD NetBIOS [\Device\NetBT_Tcpip_{1579CABA-...}] SEQPACKET 8
MSAFD NetBIOS [\Device\NetBT_Tcpip_{1579CABA-...}] DATAGRAM 8
MSAFD NetBIOS [\Device\NetBT_Tcpip_{93E9068C-...}] SEQPACKET 3
MSAFD NetBIOS [\Device\NetBT_Tcpip_{93E9068C-...}] DATAGRAM 3
MSAFD NetBIOS [\Device\NetBT_Tcpip_{AEF3C58D-...}] SEQPACKET 0
MSAFD NetBIOS [\Device\NetBT_Tcpip_{AEF3C58D-...}] DATAGRAM 0
MSAFD NetBIOS [\Device\NetBT_Tcpip_{F10AE339-...}] SEQPACKET 1
MSAFD NetBIOS [\Device\NetBT_Tcpip_{F10AE339-...}] DATAGRAM 1
MSAFD NetBIOS [\Device\NetBT_Tcpip_{DBE3C768-...}] SEQPACKET 2
MSAFD NetBIOS [\Device\NetBT_Tcpip_{DBE3C768-...}] DATAGRAM 2

And this is the reason why I find the Microsoft KB article to be misleading. It states that I should have only 10 Winsock entries listed in total. The first four and then the 6 NetBIOS entries, but I have 10 NetBIOS entries! I was pulling my hair out over this for many, many hours. I uninstalled anything I could think of that was causing the extra entries (iTunes, Bonjour, Skype, etc.) Then I came to realize that because I have an NIC card and a WLAN card, that perhaps there are extra entries listed on the page for the extra devices. It is also possible that all the extra adapters (visible once you click View - Show hidden devices) within Device Manager (installed as part of the default setup of the Network cards) are also causing the extra entries. In any event I found the KB article to be less then helpful since having both an NIC and WLAN card is commonplace today and my chasing of a red heron was due in no small part to the lack of an explanation as to why someone might have more then 6 MSAFD NetBIOS entries.

My next line of reasoning was to completely uninstall all 'Clients,' 'Services' and 'Protocols' on the adapters including the uninstalling and reinstalling of 'Internet Protocol (TCP/IP)' which is not normally un-installable by default on XP. Once all of them including the TCP/IP Protocol was successfully uninstalled the first 4 protocols were removed but the other 10 NetBIOS protocols were still left! These 10 network protocols, contained in the Winsock and WinSock2 registry keys were not removed, so a manual deletion of the two winsock keys was performed which finally removed all the protocols. I finally have a completely blank page on the MSInfo32 Protocol page!

Doing all this will result in a complete rebuild of Winsock and TCP/IP once everything is reinstalled. Removal of everything except TCP/IP is straightforward enough since you need only select uninstall for each item on the adapter properties, but for TCP/IP I performed the following steps:

Uninstall of TCP/IP:
(copied from: http://support.Microsoft.com/kb/325356)
1. Locate the Nettcpip.Inf file in %winroot%\inf, and then open the file in Notepad.
2. Locate the [MS_TCPIP.PrimaryInstall] section.
3. Edit the Characteristics = 0xA0 entry and replace 0xA0 with 0x80.
4. Save the file, and then exit Notepad.
5. In Control Panel, double-click Network Connections, right-click Local Area Connection, and then select Properties.
6. On the General tab, click Install, select Protocol, and then click Add.
7. In the Select Network Protocols window, click Have Disk.
8. In the Copy manufacturer's files from: text box, type c:\windows\inf, and then click OK.
9. Select Internet Protocol (TCP/IP), and then click OK.
Note: This step will return you to the Local Area Connection Properties screen, but now the Uninstall Button is available.
10. Select Internet Protocol (TCP/IP), click Uninstall, and then click Yes.
11. Delete the following registry keys:
HKLM\system\CurrentControlSet\services\winsock
HKLM\system\CurrentControlSet\services\winSock2
12. RESTART
Note: Succesful un-installation of TCP/IP will remove numerous keys from the registry including:
HKLM\system\CurrentControlSet\services\atmarpc
HKLM\system\CurrentControlSet\services\dhcp
HKLM\system\CurrentControlSet\services\dnscache
HKLM\system\CurrentControlSet\services\ipsec
HKLM\system\CurrentControlSet\services\netbios
HKLM\system\CurrentControlSet\services\netbt
HKLM\system\CurrentControlSet\services\nla
HKLM\system\CurrentControlSet\services\policyagent
HKLM\system\CurrentControlSet\services\tcpip

Reinstall of TCP/IP:
1. Following the above step #2 and #3, to replace the 0x80 back to 0xA0, this will eliminate the "unsigned driver" message that was encountered during the uninstallation phase.
2. Return to "local area connection" and choose: properties > general tab > install > Protocol > TCP/IP

Once the TCP/IP Protocol was reinstalled only the first 4 protocols were restored so that my MSInfo32 - Network - Protocol page looked like this:

MSAFD Tcpip [TCP/IP]
MSAFD Tcpip [UDP/IP]
RSVP UDP Service Provider
RSVP TCP Service Provider

In order to get the NetBIOS entries to be restored, the Network Client 'Client For Microsoft Networks' needed to be installed on a network adapter. Doing this correctly restored all of the protocols and corrected the Winsock corruption resulting in a correct purging of the NetBIOS Remote Cache Name Table with correct functionality of the 'Nbtstat -R' command. The final MSInfo32 correct entries look like this:

MSAFD Tcpip [TCP/IP]
MSAFD Tcpip [UDP/IP]
RSVP UDP Service Provider
RSVP TCP Service Provider
MSAFD NetBIOS [\Device\NetBT_Tcpip_{AEF3C58D-...}] SEQPACKET 0
MSAFD NetBIOS [\Device\NetBT_Tcpip_{AEF3C58D-...}] DATAGRAM 0
MSAFD NetBIOS [\Device\NetBT_Tcpip_{93E9068C-...}] SEQPACKET 1
MSAFD NetBIOS [\Device\NetBT_Tcpip_{93E9068C-...}] DATAGRAM 1
MSAFD NetBIOS [\Device\NetBT_Tcpip_{1579CABA-...}] SEQPACKET 2
MSAFD NetBIOS [\Device\NetBT_Tcpip_{1579CABA-...}] DATAGRAM 2
MSAFD NetBIOS [\Device\NetBT_Tcpip_{8CF1AE8A-...}] SEQPACKET 3
MSAFD NetBIOS [\Device\NetBT_Tcpip_{8CF1AE8A-...}] DATAGRAM 3
MSAFD NetBIOS [\Device\NetBT_Tcpip_{BBFCF804-...}] SEQPACKET 4
MSAFD NetBIOS [\Device\NetBT_Tcpip_{BBFCF804-...}] DATAGRAM 4

I have seen numerous posts about the Netsh Winsock and TCP/IP resets not working for everyone (including myself); or even Winsock key deletions resulting in no MSAFD NetBIOS entries. Doing a complete adapter/protocol reset by uninstalling everything then reinstalling it all back again, finally fixed my problems and may work for others who did not solve their problem with Netsh or Winsock key deletions. I do find it interesting that the above entries are now ordered sequentially as in 0,1,2,3,4 whereas before they were 8,3,0,1,2.

~ Nexus9er


UPDATE: After installing uTorrent, my problem resurfaced! I then repeated the above steps and once more my problem has been solved. To be certain it was being caused by the installation of uTorrent, I reinstalled once more, and again the NetBIOS Remote Cache Name Table problem occurred. I have posted on the uTorrent Bug Report forum concerning this issue.