Fix WSA_QOS_ADMISSION_FAILURE 0x2B02 on Windows

You're on a Teams call at 9:15 Monday morning. The app tries to reserve bandwidth for the audio stream, Windows returns WSA_QOS_ADMISSION_FAILURE, and the call drops to a tinny 8 kHz mono mess. Or maybe it's a SIP softphone, a UDP telemetry feed, or a custom app that calls WSAIoctl with SIO_SET_QOS. Either way, the socket call to set up a QoS reservation comes back with 0x2B02 and the reservation never lands.

This isn't a rare error. It hits most often on Wi-Fi when you've got a dozen devices saturating the 5 GHz band, on VPN adapters that strip QoS tags before they hit the wire, and on Windows Server boxes where a Group Policy already locked down the available bandwidth. Same code, three very different fixes.

What 0x2B02 actually means

Windows has a QoS subsystem built into the TCP/IP stack. When an app asks for guaranteed bandwidth — say 512 kbps for a voice stream — the RSVP and GQoS components check whether the local adapter, the driver, and any active policies can honor that reservation. If the answer is no, you get WSA_QOS_ADMISSION_FAILURE.

It's a local admission decision. The error doesn't mean the far end refused you. It means your own machine looked at its own resources and said "can't spare that." Common causes:

The link is already saturated. A 100 Mbps switch port running at 98% has nothing left to reserve.
The QoS Packet Scheduler isn't bound to the adapter you're sending on. This is the #1 cause on fresh Windows installs.
A Group Policy caps reservable bandwidth below what the app requested. Default is 20% of link speed.
The VPN driver (OpenVPN TAP, WireGuard NT, Cisco AnyConnect) doesn't expose a QoS-capable interface. Windows can't reserve what the driver won't admit exists.
Wi-Fi in a congested cell where the driver reports low available airtime.

Socket error 11010 maps to this same condition, so if you're staring at a Winsock log, they're the same event.

The fix

Work top to bottom. Don't skip step 3 — half the machines I've seen had the scheduler missing and that was the whole story.

Check what the adapter reports. Open an elevated Command Prompt and run:
```
netsh int ip show interfaces
netsh int tcp show global
```
Look at the interface you're actually sending on. If the media state is disconnected or the link speed is showing something absurd (10 Mbps on a gigabit NIC), fix the physical layer first.
Confirm the QoS Packet Scheduler is bound. Press Win+R, type ncpa.cpl, hit Enter. Right-click your active adapter → Properties. In the list you should see QoS Packet Scheduler with a checked box. If it's not in the list, click Install → Service → Add → QoS Packet Scheduler. After adding it, you'll see the list refresh and the checkbox will already be ticked. Click OK.
Kill competing reservations. Other apps can hold reservations you don't know about. Run:
```
netsh int ipv4 show subinterfaces
netsh int ipv4 show dynamicport tcp
```
If a stale app is holding a large reservation, restart that app or reboot. The reservation table clears on reboot.
Check QoS policy. Hit Win+R, run gpedit.msc (Pro/Enterprise). Navigate to Computer Configuration → Administrative Templates → Network → QoS Packet Scheduler → Limit reservable bandwidth. If it's Enabled with a value like 10%, either bump it or set it to Disabled. On a home machine this is usually Not Configured, which means 20% is reserved for QoS by default.
Restart the QoS service. In an elevated prompt:
```
net stop "QoS RSVP"
net start "QoS RSVP"
```
On some builds the service is named RSVP instead. If you get "service name is invalid," try that.
If you're on a VPN, disconnect it and retest. If the error disappears, your VPN driver is the problem. WireGuard's NT driver historically doesn't advertise QoS capability. The workaround is to run the QoS-tagged app on the physical adapter and let the VPN tunnel ride on top — or switch to a tunnel that supports the NDIS QoS OID.
Flush and reset the stack as a last resort. This reboots the machine, so save your work:
```
netsh int ip reset
netsh winsock reset
```
Reboot. Winsock reset removes any LSPs that a sketchy VPN or AV product injected and that were eating QoS requests.

If it still fails

Test with a different app. If a plain UDP socket with no QoS succeeds but your QoS app fails, the problem is definitely admission, not connectivity. Grab Wireshark and watch the RSVP PATH and RESV messages on your adapter — if you see PATH go out and no RESV come back, the local stack is the one refusing.

Check the adapter driver version. Realtek and Intel NIC drivers from before 2019 have bugs where the NDIS QoS OID returns success but never actually reserves anything, and Windows reads the empty reservation as a failure. Update to the vendor's latest driver, not the one Windows Update ships.

Finally, look at event viewer under Applications and Services Logs → Microsoft → Windows → QoS. Any admission failure leaves a breadcrumb there with the requested bandwidth and the reason for refusal. That log has saved me more time than any forum thread.

The blunt truth: if you're on Wi-Fi and the air is busy, no amount of config will make QoS admission succeed. Get on Ethernet. Voice and video codecs don't care about your policy file — they care about having the wire.