WSAEINVALIDPROVIDER (0x00002779) Fix - Winsock Repair Guide

WSAEINVALIDPROVIDER means Winsock can't find the network provider your app needs. Usually a corrupt Winsock or LSP entry. Here's the fix, fastest first.

What WSAEINVALIDPROVIDER Actually Means

WSAEINVALIDPROVIDER (decimal 10047, hex 0x00002779) is Winsock's way of saying "the service provider you asked for doesn't exist or is broken." Every network app that opens a socket talks to Winsock, which hands the request off to a "service provider" — usually MSAFD Tcpip or MSAFD Tcpip [TCP/IP]. When that handoff fails, this is the error you get.

I had a client last month whose entire print queue died because of this. A Konica Minolta MFP driver snuck in a third-party LSP during an install and clobbered the catalog. Every app on that PC that touched the network threw 0x00002779 for two days until we reset Winsock. So no, this isn't always malware or a bad VPN client — sometimes it's a printer driver doing something stupid.

You'll usually see it in one of these places:

An app that calls WSAStartup and asks for a specific provider by GUID
VPN clients (older Cisco AnyConnect, some SonicWall builds) that install their own LSP
After a Windows update or a botched driver install
Games and launchers that hard-code the provider name

Work through the three fixes below in order. Stop when your issue goes away.

Fix 1: Reset Winsock (30 seconds)

Nine times out of ten this is the whole fix. netsh winsock reset throws out the Winsock catalog and rebuilds it from scratch. Any LSP entries that are orphaned or corrupt get swept away.

Right-click Command Prompt or Terminal and pick Run as administrator.
Run this:

netsh winsock reset
netsh winsock reset catalog

You'll see Successfully reset the Winsock Catalog. Now reboot. Don't skip the reboot — the catalog doesn't reload until you do.

After the reboot, launch the app that was throwing 0x00002779. If it works, you're done. If it doesn't, move on.

One caveat: if you run a third-party firewall (older Comodo, some enterprise AV), resetting Winsock can break its network filter until you reinstall or repair it. That's not a bug, that's how LSPs work. Just repair the AV afterwards.

Fix 2: Rebuild TCP/IP and Winsock (5 minutes)

Winsock reset handles the provider catalog, but if the underlying TCP/IP stack is also damaged — which happens together more often than people realize — you need to rebuild that too. This combo fixes the vast majority of cases I've seen where Fix 1 didn't stick.

Open an elevated Command Prompt.
Run these in order:

netsh int ip reset resetlog.txt
netsh winsock reset
ipconfig /flushdns
ipconfig /release
ipconfig /renew
netsh int ipv4 reset
netsh int ipv6 reset

Reboot after. Yes, all of it. The resetlog.txt file gets dumped in the current directory — you can read it if you're curious, but it usually just tells you which keys were rewritten.

If you're on Windows 10 2004 or newer, or Windows 11, there's also the nuclear option in Settings:

Settings → Network & Internet → Advanced network settings → Network reset

That wipes every adapter, every saved Wi-Fi profile, and every VPN config. I only use it when the command-line stuff fails, because you'll spend another 10 minutes reconnecting to everything. Try the netsh route first.

Fix 3: Hunt Down the Broken LSP (15+ minutes)

If both resets fail, or the error comes back after a reboot, you've got an LSP being reinstalled by something. A VPN client, a security agent, or — in the case of my printer client — a driver that's silently pushing its own provider back into the catalog every time Windows starts.

Check what's registered:

netsh winsock show catalog

You'll get a wall of output. What you're looking for is any entry that isn't Microsoft's. The two you should always see are:

MSAFD Tcpip [TCP/IP] — GUID {E70F1AA0-AB8B-11CF-8CA3-00805F48A192}
MSAFD Tcpip [UDP/IP] — GUID {E70F1AA0-AB8B-11CF-8CA3-00805F48A193}

For each non-Microsoft entry, note the Library Path and the Provider GUID. Common culprits:

Provider	Typical owner	What to do
Deterministic Networks DNE	Old Citrix, some VPN clients	Uninstall the VPN client fully
MSAFD Tcpip [RAW/IP]	Leftover from packet capture tools	Remove via LSP removal tool or reinstall the tool
Symantec/Blue Coat LSP	Old proxy agents	Remove via vendor uninstaller

To nuke a bad LSP, the safest tool is still LSPFix from Cexx.org — old but works. On 64-bit Windows, use netsh winsock reset catalog after removing the parent app. Deleting entries by hand in the registry (HKLM\SYSTEM\CurrentControlSet\Services\WinSock2\Parameters\Protocol_Catalog9\Catalog_Entries) is possible but you will break networking if you get it wrong. Don't do it unless you've got a system image to fall back on.

Then uninstall the offending app. A reset without removing the source is just a countdown until the error comes back.

When It's Not Winsock At All

Rare, but worth a mention: this error can also come from a Windows Filtering Platform (WFP) callout that got orphaned. You'll see it in apps that use WSASocket with an explicit provider pointer. If that's you, run netsh wfp show state and look for callouts pointing at a DLL that no longer exists on disk. Deleting the callout via netsh wfp delete is the fix, but the syntax is fiddly and I've only needed to do it twice in ten years.

Also double-check that the Windows Ancillary Function Driver for WinSock (afd.sys) is running. If it's stopped or disabled, nothing network-related will work:

sc query afd

Should say RUNNING. If not, sc config afd start= system then reboot.

Quick Recap

netsh winsock reset and reboot. Fixes most cases.
If not, rebuild TCP/IP with the full netsh sequence plus reboot.
If it comes back, find and remove the LSP that's reinstalling itself. netsh winsock show catalog is your map.

Don't waste time reinstalling Windows. I've seen people do that for 0x00002779 and land right back in the same spot because they reinstalled the same VPN client afterwards. Fix the provider catalog, or the provider catalog fixes you.