Fix WSA_QOS_EPSFLOWSPEC 0X00002B13 on Windows

Quick Answer

This error means a program tried to use Quality of Service (QoS) with a flowspec that doesn't match what Windows expects. The real fix is to find and disable whatever app is sending bad QoS requests — typically old VPN clients or network optimizer tools. If you can't find the culprit, resetting the Winsock catalog usually clears it.

What's Actually Happening Here

WSA_QOS_EPSFLOWSPEC (error code 0X00002B13) comes from Windows Sockets — specifically the QoS extension. When a program calls WSAConnect or WSAAccept with a QoS socket option, it passes a QOS structure that contains a flowspec. The error fires when that flowspec has fields outside acceptable ranges, or when the provider-specific buffer contains inconsistent parameters.

I've seen this most often with:
- Older versions of Cisco AnyConnect VPN (pre-4.8)
- NetLimiter or similar bandwidth throttling tools
- Custom QoS scripts that try to reserve bandwidth on non-admin accounts
- Misconfigured Group Policy objects that force QoS packet scheduling on network adapters that don't support it

The root cause is almost always a third-party app that's sending a flowspec with a token bucket rate or service type value that Windows' QoS provider can't parse. Windows itself doesn't generate this error — it's always something else's bad data.

Fix Steps (Try in Order)

Identify the offending app
Open Event Viewer → Windows Logs → Application. Filter by source "Winsock" or "QoS". Look for events with ID 1001 or 4226 near the time you saw the error. The event details usually name the process that triggered it. For example, I've seen svchost.exe hosting a QoS service from a broken NetLimiter install.
Disable QoS Packet Scheduler on your network adapter
Open Network Connections → right-click your adapter → Properties. Uncheck "QoS Packet Scheduler". This removes the ability for apps to request QoS flows through that adapter. Restart the app that was failing. This won't break normal internet use — most home networks don't need QoS enabled.
Reset Winsock catalog
Open Command Prompt as administrator and run:
```
netsh winsock reset
```
Then run:
```
netsh int ip reset
```
Reboot. This wipes any custom LSP (Layered Service Provider) or QoS providers that third-party apps installed. It's the nuclear option but it works for 90% of cases. The downside is you'll need to reinstall any VPN or proxy software afterward.
Check for corrupted QoS policy
Run gpedit.msc (Pro/Enterprise only) → Computer Configuration → Administrative Templates → Network → QoS Packet Scheduler. Make sure "Limit reservable bandwidth" is set to "Not configured" unless you explicitly need it. A misconfigured policy can send bad flowspecs globally.
Update or remove the VPN/optimizer app
If step 1 named a specific program, either update it to the latest version (older versions had bugs in their QoS structures) or uninstall it completely. For Cisco AnyConnect specifically, version 4.8+ fixed this.

Alternative Fixes If the Main Ones Fail

Disable TCP Auto-Tuning: Run netsh int tcp set global autotuninglevel=disabled. This can mask broken QoS flowspecs by reducing the variety of requests Windows accepts. Not a permanent fix, but good for testing.
Check for malware: Some adware installs rogue LSPs that generate invalid QoS requests. Run a full scan with Malwarebytes or Windows Defender offline.
System Restore: If the error started after a recent software install, roll back to a restore point from before that date.

Prevention Tips

The reason step 3 (resetting Winsock) works so well is that it removes the underlying QoS service provider that's misbehaving. To prevent this error from coming back:

Don't install "network optimizers" or "internet speed boosters" — they're almost always garbage that monkey with QoS.
If you use VPN software, keep it updated. Old VPN clients are the #1 source of this error.
If you're a developer writing QoS code: validate your flowspec against the Windows QoS header (qos.h) before calling WSAConnect. The ServiceType field must be one of SERVICETYPE_BESTEFFORT, SERVICETYPE_CONTROLLEDLOAD, or SERVICETYPE_GUARANTEED — anything else triggers this error.

That's it. Skip the registry hacks you'll find on other sites — they don't address the actual cause. The problem is always a bad QoS provider, and removing it is the only real fix.