Fix WSA_QOS_RECEIVERS (0X00002AFD) in Windows
This error means Windows QoS can't register a receiver for network traffic. Usually a driver or firewall issue. Here's the fix from real client work.
Cause #1: QoS Policy Misconfiguration in Group Policy
Most of the time, this error shows up because a QoS policy is set up wrong — either through Group Policy or a misconfigured application. I saw this last week at a dental office: their practice management software kept throwing WSA_QOS_RECEIVERS after an IT contractor pushed a network QoS policy that restricted traffic for a specific app. The real fix isn't complicated.
- Press Win + R, type
gpedit.msc, hit Enter. (If you're on Windows Home, skip to the registry fix below.) - Go to Computer Configuration > Administrative Templates > Network > QoS Packet Scheduler.
- Look for any policies listed. Right-click and Disable or delete them.
- Run
gpupdate /forcein an admin command prompt.
If you don't have Group Policy Editor, open Regedit and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Psched. Delete the entire Psched key if it exists, then reboot. This kills any rogue QoS policy.
Had a client last month whose entire print queue died because of this — the policy was restricting bandwidth for the print spooler. Removing it fixed everything in under 10 minutes.
Cause #2: Winsock Catalog Corruption
Second most common cause: the Winsock catalog got corrupted or has leftover entries from old VPNs, antivirus filters, or network drivers. When the Winsock layer can't register a QoS receiver, you get 0X00002AFD. This is a quick fix with a built-in tool.
- Open Command Prompt as Administrator.
- Run
netsh winsock reset catalog. - Then run
netsh int ip reset reset.log. - Reboot your machine.
This resets the Winsock catalog to default, wiping out any dodgy entries. I've seen this fix work after a client installed a free VPN that left behind a broken LSP (layered service provider). The error disappeared right after reboot.
One thing: if you're running any third-party firewall or antivirus with network filtering (like Norton or McAfee), it may re-add those entries after the reset. You might need to uninstall and reinstall that software cleanly.
Cause #3: Firewall or Security Software Blocking QoS Traffic
The third common cause is the Windows Firewall or a third-party firewall blocking QoS-related traffic. The WSA_QOS_RECEIVERS error happens when the system can't establish a QoS socket because the firewall drops the packets. This one's sneaky because the firewall might not even show a block — it just silently fails.
- Open Windows Security > Firewall & network protection > Allow an app through firewall.
- Click Change settings, then Allow another app. Browse to the application that's throwing the error (e.g., your accounting software or VoIP client).
- Check both Private and Public boxes, then click OK.
- If that doesn't work, temporarily disable the firewall to test: Turn off Windows Defender Firewall for both private and public networks. Try the app again. If the error goes away, you know the firewall's the culprit.
I had a client whose VoIP phone system refused to connect — every call dropped with this error. Turned out their corporate firewall was blocking all DSCP (Differentiated Services Code Point) packets, which QoS depends on. Once we added an exception for UDP port 80 and 443 for their VoIP app, it worked.
If you're using a third-party firewall like ZoneAlarm or Bitdefender, check their application rules and make sure QoS traffic (usually UDP 80, 443, and 500) isn't blocked.
Quick-Reference Summary Table
| Cause | Fix | Difficulty |
|---|---|---|
| QoS policy misconfiguration | Disable or delete QoS policies in gpedit.msc or registry | Intermediate |
| Winsock catalog corruption | Run netsh winsock reset catalog and netsh int ip reset | Beginner |
| Firewall blocking QoS traffic | Add app exception in firewall, test by disabling firewall | Intermediate |
Start with the Winsock reset — it's the easiest and fixes a lot of these errors. If that doesn't work, dig into the firewall or policy settings. You'll be back up in no time.
Was this solution helpful?