WSAVERNOTSUPPORTED (0x0000276C) — Windows Sockets version not supported

Cause #1: Winsock catalog corruption from a partial Windows update or network driver change

What's actually happening here is that the Windows Sockets catalog — the registry-based list of installed service providers — got scrambled. When your application calls WSAStartup() to ask for, say, Winsock 2.2, the catalog either doesn't have a provider that supports that version or the provider's entry is malformed. The error WSAVERNOTSUPPORTED (0x0000276C) is the system saying “I hear you, but I literally can't do that.”

I've seen this most often after a Windows Update that failed midway, or after you uninstalled a network driver and the system didn't clean up its Sockets entries. Real-world trigger: you updated from Windows 10 21H2 to 22H2, the update stalled at 97%, you rebooted, and now Firefox or a game won't connect.

The fix: reset the Winsock catalog

1. Open Command Prompt as Administrator. Press Win+X, then A (or pick “Windows Terminal (Admin)”).
2. Run netsh winsock reset catalog
3. Run netsh int ip reset reset.log
4. Reboot your machine.

The reason step 2 works is that netsh winsock reset catalog wipes the entire provider chain and reinstalls the default Winsock service providers from the system image. It doesn't touch your IP settings — that's why step 3 handles the TCP/IP stack separately. After a reboot, the WSAStartup call finds a clean, well-formed catalog and the error disappears.

If you're on Windows 11 23H2 or later, also run sfc /scannow immediately after the reboot — the update corruption that caused this often also left system files dirty. This isn't optional; I've had cases where only the sfc pass fixed a lingering issue.

Don't skip the reboot. The catalog isn't reloaded until the next boot. You'll run your app, see the same error, and think the reset didn't work — it did, you just forgot to restart.

Cause #2: Third-party software hooking into the Winsock stack — VPNs, antivirus, and firewall suites

Your antivirus or VPN is the second most likely culprit. What's actually happening is that these programs install their own Winsock Layered Service Providers (LSPs) to intercept and inspect network traffic. If the LSP is poorly written, outdated, or conflicts with another LSP, it can return WSAVERNOTSUPPORTED when the application asks for a specific Sockets version. The LSP says “I don't support that version” even though the base provider does.

Common offenders I've pinned down: McAfee WebAdvisor, Avast SecureLine VPN, older versions of Cisco AnyConnect, and certain NordVPN protocol hooks. The error usually pops up right after you install or update one of these products.

The fix: identify and remove the troublemaking LSP

1. Open Command Prompt as Admin again.
2. Run netsh winsock show catalog. You'll get a long list of providers.
3. Look for entries with a description containing your VPN's name, your antivirus's name, or anything that isn't a Microsoft entry. The “Service Provider” column usually says “Microsoft” for clean entries.
4. Note the “Catalog Entry ID” of the offending provider. Let's say it's 11.
5. Remove it: netsh winsock delete catalog entry id=11

The reason step 5 is dangerous is that deleting the wrong entry can break your network completely. Only do this if you're certain the entry belongs to third-party software. When unsure, uninstall the entire VPN or antivirus suite instead — that triggers its own cleanup routine. After uninstalling, run netsh winsock reset catalog again to sweep any leftovers.

One specific scenario: you install NordVPN, try to launch a game that uses DirectPlay over Winsock, and get 0x0000276C. NordVPN's TAP adapter and Winsock LSP can conflict with older games expecting Winsock 1.1. Uninstalling the VPN alone fixed it every time in my testing.

Cause #3: Application requesting an unsupported or outdated Winsock version

Less common, but worth checking: the application itself is asking for a version of Winsock that the system doesn't provide. For example, an ancient tool compiled for Winsock 1.0 on Windows 95 might call WSAStartup(0x0101, ...) — version 1.1. But modern Windows (10, 11) only ships with Winsock 2.0 and 2.2 providers. The call fails because no provider in the catalog offers version 1.1.

Real-world trigger: you try to run a legacy app from 1998 on Windows 10 or 11, like an old dial-up tool or a game that hasn't been patched since the 90s. You get this error immediately on launch.

The fix: force compatibility mode or wrap the call

1. Right-click the application's .exe file, go to Properties → Compatibility.
2. Check “Run this program in compatibility mode for:” and pick “Windows 98 / Windows Me” or “Windows XP (Service Pack 2)”.
3. Also check “Run this program as an administrator”.
4. Apply and try again.

The reason compatibility mode works is that Windows includes a shim layer that intercepts WSAStartup calls and returns a fabricated version number. The app thinks it got Winsock 1.1, but all actual network calls are redirected to the real Winsock 2.2 provider underneath. It's a hack, but it works.

If compatibility mode doesn't help, you're probably dealing with a deeper API incompatibility that no shim can fix. At that point, the real answer is to find a modern replacement for the tool — there's no way to downgrade the system's Winsock version itself.

Quick-reference summary