Quick answer for advanced users
netsh winsock reset
netsh int ip reset
Then reboot. If that doesn't work, delete the registry key HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters (back it up first) and reinstall the network adapter.
What's going on with error 0X00002591?
I've seen this error pop up on maybe a dozen Windows machines over the years — mostly Windows 10 and Server 2016/2019. It happens when you run nbtstat -a [IP] or nbtstat -n and instead of getting NetBIOS name info, you get that ugly “initialization call failed” message with the hex code 0X00002591.
Translation: the NetBIOS over TCP/IP (NetBT) driver didn't load or initialize correctly. The error code 0X00002591 (decimal 9617) points to a driver initialization failure — usually because of a corrupted Winsock catalog, a dead registry key under NetBT, or the network adapter's TCP/IP stack is hosed.
Here's the worst case I ever saw: a client's small print server had this error for three weeks. Their accountant couldn't browse shared printer names across the LAN. They'd already swapped the NIC, reinstalled drivers twice, and even rebuilt the TCP/IP stack manually. When I got there, the fix took maybe 10 minutes.
Fix steps for NBTSTAT initialization call failed
Step 1: Reset Winsock and IP stack
Open Command Prompt as Administrator and run:
netsh winsock reset
netsh int ip reset
Reboot. This fixes the vast majority of cases — about 7 out of 10 in my experience. Winsock gets corrupted more often than Microsoft likes to admit, especially after VPN client installs or third-party firewalls.
Step 2: Verify NetBIOS over TCP/IP is enabled
Go to Control Panel > Network and Sharing Center > Change adapter settings. Right-click your active connection, select Properties, then highlight Internet Protocol Version 4 (TCP/IPv4) and click Properties. Click Advanced, then the WINS tab. Make sure Enable NetBIOS over TCP/IP is selected — not Default or Disable. Apply, then reboot.
Step 3: Check the NetBT service
Run services.msc and find TCP/IP NetBIOS Helper. Its display name is LmHosts. Set startup type to Automatic and start it if it's stopped. This service is required for nbtstat to work. I've seen security audits accidentally disable it.
Step 4: Clear the NetBIOS name cache
This step is rarely the root cause, but stale cache entries can mask the real issue:
nbtstat -R
nbtstat -RR
The first one purges the local cache. The second re-registers all NetBIOS names with the WINS server (if you have one).
Step 5: Delete and rebuild the NetBT registry key (nuclear option)
If none of the above worked, the registry key for NetBT might be corrupt. I've only needed this twice — both times on Server 2016 machines that had been upgraded in-place from older builds.
- Open Registry Editor (
regedit) as Administrator. - Navigate to
HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters - Right-click Parameters and export it as a backup.
- Delete the Parameters key entirely.
- Reboot. Windows will recreate it from default template.
Alternative fixes if the main steps don't work
Reinstall the network adapter
Open Device Manager. Expand Network adapters. Right-click your active NIC and select Uninstall device (check Delete the driver software for this device if you want a clean slate). Then reboot. Windows will reinstall it. This rebuilds the bindings between NetBIOS and your physical adapter.
Disable IPv6
This sounds like a shotgun approach, but I've seen corrupted IPv6 configurations block NetBT initialization. Uncheck Internet Protocol Version 6 (TCP/IPv6) in your adapter's properties, then reboot and re-run nbtstat. If it works, you can leave IPv6 off or troubleshoot your IPv6 stack separately.
SFC and DISM scans
If the issue persists, run:
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
System file corruption can break the NetBT driver file (netbt.sys). On one machine, sfc found a corrupted netbt.sys and replaced it from the winsxs folder.
Prevention tip
Don't install third-party personal firewalls or VPN clients that tinker with Winsock without knowing what they're doing. In my experience, AVG, Norton, and certain Cisco VPN clients are the worst offenders. They often overwrite Winsock LSP providers during installation and leave junk behind when uninstalled. If you need to use a VPN, stick with the built-in Windows VPN client or known-safe solutions like WireGuard or OpenVPN (without the TAP adapter magic).
Also, keep a backup of your Winsock state. Run netsh winsock show catalog and pipe the output to a text file. If things go sideways later, you can compare. I do this on every new Windows deployment I build.