Duplicate name on the network 0x80070034 and a broken Winsock TCP stack

Fix it now

0x80070034 is Win32 error 52, ERROR_DUP_NAME: you were not connected because a duplicate name exists on the network. It comes from the NetBIOS-over-TCP/IP layer while a session is being set up, not from DNS and not from the share. Either two devices are claiming the same name, or the client’s own Winsock provider chain is broken. Share permissions have nothing to do with it.

nbtstat -n
nbtstat -a FILESRV
netsh winsock show catalog > %USERPROFILE%\Desktop\winsock-before.txt

1. Read the state column in the nbtstat -n output. Microsoft documents Conflict as meaning a duplicate computer name has registered the same service; Registered is healthy.
2. From a second machine, run nbtstat -a <name> to see who else answers to it and with which MAC address, then rename or reconfigure whichever device should not have it.
3. If no name is in Conflict, suspect the socket layer instead: look for 0x8007277A, and for entries in the catalog whose DLL you cannot find on disk.
4. Reset the stack only after writing down any static addressing: netsh winsock reset, then netsh int ip reset c:\resetlog.txt, then reboot.
5. Retest the path that failed with Test-NetConnection FILESRV -Port 445 before touching the share itself.

netsh int ip reset has the same effect as removing and reinstalling TCP/IP and rewrites the Tcpip and DHCP parameter keys, so a machine with a static address comes back on DHCP. The log file argument records everything it changed.

If names read Registered and port 445 answers, you are done. If not, the next section separates the name clash from the socket fault, which look identical from the desktop.

Why it happens

A Windows machine with NetBIOS over TCP/IP enabled registers a set of names on its segment when the network comes up: its computer name for the workstation service, the same name again for the server service, and the workgroup or domain name. Registration is a claim, and the claim can be objected to. Where another device already holds one of those names, the registration fails and session set-up that would have used the name fails with error 52.

It is worth being precise about what a NetBIOS name is, because a lot of folklore is not. The name is fifteen characters; Microsoft reserves the sixteenth byte to identify which service on the device the name refers to. Windows does not permit computer names longer than fifteen characters in the first place, so two Windows machines cannot collide by having long names truncated into each other. Real clashes come from somewhere else: a cloned or imaged machine that was never renamed, a NAS or appliance configured with a name already in use, or a stale registration left in WINS that nothing has cleared.

The second family of causes has nothing to do with names at all. Every socket call passes through the Winsock catalog, an ordered list of service providers. If an entry points at a DLL that has been removed, or a layered provider was left behind by software that uninstalled badly, socket creation fails part-way. That surfaces as 0x8007277A – Winsock error 10106, WSAEPROVIDERFAILEDINIT, which Microsoft describes as the provider’s DLL failing to load or its start-up function failing. Because the break sits below the protocol, it takes down anything that opens a socket, not just file sharing.

Full reference

Reading the symptom to find the layer

Command reference

What a reset actually rewrites

Two commands get run together as though they were one. They are not. netsh winsock reset returns the Winsock catalog to defaults and removes layered providers, which is what you want when 0x8007277A is in play. netsh int ip reset is heavier: Microsoft describes it as having the same effect as removing and reinstalling TCP/IP, and it overwrites SYSTEM\CurrentControlSet\Services\Tcpip\Parameters and SYSTEM\CurrentControlSet\Services\DHCP\Parameters. Both need a restart before anything changes.

Record static addresses, gateways and DNS servers before running netsh int ip reset. The reset rewrites the interface configuration, and a server that comes back on DHCP with no reservation is a worse problem than the one you started with.

Turning NetBIOS off instead

In a network that resolves everything through DNS, disabling NetBIOS over TCP/IP removes this whole class of fault rather than fixing it, and it is a reasonable piece of cleanup. The setting is per adapter, under the IPv4 properties, Advanced, WINS tab. Test before you commit: some older line-of-business applications, backup agents, multifunction devices and network browsing still depend on it, and the failures that follow are quiet ones.

When the short name fails and the long name works

They take different paths, which is the whole explanation. The fully qualified name is resolved by DNS and connects straight over TCP. The short name can still be claimed and answered through NetBIOS on the local segment, so a clash on the short name leaves the DNS path completely untouched. That asymmetry is a useful diagnostic: if \\FILESRV\share fails and \\FILESRV.example.local\share works, you are looking at a name registration problem, not a share, a firewall or a permission.

When none of it fits

• Check for a duplicate IP address on the segment, which produces resets and refusals that look exactly like a name clash.
• Check whether the client and the server are on the same subnet. NetBIOS name registration is a broadcast claim and does not cross a router without WINS.
• Look at the System log on both machines for NetBT events at the moment of the failure; they name the conflicting address.
• On a machine that was imaged, confirm it has a unique computer name and, on a domain, a healthy computer account rather than one that was reused.

Every code this article covers

Confirm the fix worked

1. nbtstat -n on both machines shows every name Registered and none in Conflict.
2. Test-NetConnection FILESRV -Port 445 returns true from the client subnet, not only from the server.
3. The share opens by short name and by fully qualified name, both without a credential prompt.
4. Unrelated network applications work, which is what tells you a Winsock reset actually took.
5. After a reboot, the System log carries no new NetBT duplicate-name entries and static addressing is still in place.

Questions people ask about this