Fix WSA_QOS_EFILTERCOUNT (0X00002B0D) on Windows
This error means your app sent wrong QoS filter counts. The fix is simple: check the FLOWDESCRIPTOR structure. I'll show you exactly where to look.
This error is annoying, I know. Let's fix it.
You're seeing WSA_QOS_EFILTERCOUNT (0X00002B0D) because your application sent a FLOWDESCRIPTOR structure with the wrong number of QOS FILTERSPEC entries. The Windows QoS provider checks this carefully and rejects anything that doesn't match.
The fix: correct your FILTERSPEC count
Here's what you need to do. Open your code where you build the FLOWDESCRIPTOR structure. Look for the FilterCount field. This field MUST match the actual number of QOS_FILTERSPEC structures you point to with FilterList.
// Example - WRONG way (causes error 0x2B0D)
FLOWDESCRIPTOR fd;
QOS_FILTERSPEC filters[2]; // two filters
ZeroMemory(&fd, sizeof(fd));
fd.FilterCount = 3; // BUG! Should be 2
fd.FilterList = filters;
// Example - CORRECT way
fd.FilterCount = 2; // matches the array size
After you fix the count, rebuild and test. The error should disappear. I've seen this happen most often when developers copy-paste code and forget to update the count after adding or removing a filter.
Step-by-step debugging approach
- Find every place you create a FLOWDESCRIPTOR in your code.
- Check the
FilterCountvalue against the actual array size of QOS_FILTERSPEC you pass inFilterList. - Make sure you didn't accidentally set
FilterCountto 0. That's also wrong — must be at least 1 if you have filters. - If you're using dynamic arrays, verify the count variable used matches the array length at the time of the call.
- Recompile and test with a debugger to confirm the fix.
Why this happens
The Windows QoS service provider reads your FLOWDESCRIPTOR structure when you call WSAIoctl with SIO_SET_QOS or SIO_GET_QOS. It expects the FilterCount to match exactly how many QOS_FILTERSPEC entries are in the array. If the numbers don't match, the provider can't parse your request correctly. It returns WSA_QOS_EFILTERCOUNT to tell you the filter count is wrong.
This isn't a network problem. It's a programming mistake — usually a simple off-by-one error or forgetting to update a counter after changing the filter list. I've fixed this dozens of times for developers who thought their network was broken. It never was.
Less common variations of this issue
Sometimes the problem isn't the count itself but something else related to filters. Here are a few I've run into:
1. FilterCount set to 0 when you have filters
If you set FilterCount to 0 but still provide a pointer in FilterList, the QoS provider will ignore the pointer. But if you're trying to apply filters and set count to 0, you get this error. The fix: always set FilterCount to the actual number of filters you want to apply.
2. Double pointer mistake
Some developers mistakenly set FilterList to a pointer-to-pointer instead of a flat array. For example, if filters is QOS_FILTERSPEC** instead of QOS_FILTERSPEC*, the count will be misinterpreted. The provider might read garbage and throw this error. Check your types in the debugger.
3. Using FLOWDESCRIPTOR from a different SDK version
If you're mixing Windows SDK versions (like using an older header with a newer runtime), the structure layout might differ. The FilterCount field can shift positions. This is rare but I've seen it when someone copies struct definitions from the internet instead of using the official headers. Stick to the official <winsock2.h> and <qos.h>.
How to prevent this from happening again
- Use constants for filter counts — define a constant like
#define NUM_FILTERS 2and use that everywhere. This way you only change it in one place. - Add assertions — before calling
WSAIoctl, assert thatfd.FilterCount == actual_array_size. This catches bugs early. - Peer review your QoS code — this error is easy to miss during a solo code review. Have a colleague look at your FLOWDESCRIPTOR setup.
- Use a helper function — write a small function that builds the FLOWDESCRIPTOR for you, taking the filter array and count as parameters. This centralizes the logic and reduces errors.
- Stay on recent Windows SDK — newer SDKs have better documentation and sometimes clearer error messages. Windows 10 SDK version 10.0.19041.0 or later is good.
That's it. Fix the count, and you're done. No need to restart Windows or reinstall networking components. This is purely a coding issue, and now you know exactly where to look.
Was this solution helpful?