STATUS_FWP_IN_USE (0xC022000A) – Object Can't Be Deleted

1. The Sublayer or Provider Still Holds a Reference

Your script or GUI tool tried to delete a WFP object — a filter, a sublayer, or a provider — and Windows spat back 0xC022000A. The culprit here is almost always a sublayer or provider that still has filters pointing at it. You can't delete the parent while children exist.

Open an elevated PowerShell or command prompt. Run:

netsh wfp show filters

That spits out a ton of XML. Pipe it to a file:

netsh wfp show filters > C:\temp\wfpfilters.xml

Search the XML for the GUID or name of the object you're trying to delete. Look for <providerKey> or <sublayerKey> that matches. If you find filters referencing it, delete those first with netsh advfirewall firewall delete rule or the specific Delete-WFPFilter cmdlet (if you're using the WFP module).

Real-world trigger: You installed a third-party VPN client that registered its own WFP sublayer. Uninstalling the VPN didn't clean up the sublayer, so any attempt to delete it fails with 0xC022000A.

2. The Object Is a System Default – You Can't Delete It

Windows ships with dozens of built-in WFP objects — providers like "Microsoft Windows Filtering Platform" and sublayers like "FWPM_LAYER_INBOUND_IPPACKET_V4". You can't delete those. The error code appears when you try.

Check the object type. Run this in PowerShell (as admin):

Get-WFPObject -Type Sublayer | Where-Object {$_.Name -eq "YourSublayerName"}

Look at the Flags property. If it includes System or BootTime, that object is protected. Don't bother trying to delete it — you'll waste time. Instead, disable it if you can, or accept it's permanent.

Quick test: Try deleting a default rule via netsh advfirewall firewall delete rule name="Core Networking". You'll get the same error. That's Microsoft's way of saying "hands off."

3. Another Process Has an Open Handle to the Object

Less common, but I've seen it. A service or driver holds a reference to the WFP object. The Windows Filtering Platform API won't release it while the handle is open.

Use Handle from Sysinternals or Get-Process to find what's locking it. Run:

handle.exe -a -p *WFP*

Or for a specific object GUID:

handle.exe -a "{GUID}"

If you see a process like svchost.exe hosting the WFPSvc or a third-party firewall driver, that's your blocker. Restart the service or kill the process (carefully — don't kill critical system processes). Then try the delete again.

I've personally hit this with Symantec Endpoint Protection. Its driver symefasi.sys kept a handle on a custom sublayer. Stopping the service let me delete the sublayer cleanly.

Quick-Reference Summary

If none of these work, reboot cleanly. That forces the WFP engine to reinitialize and releases any stale handles. Nine times out of ten, the first fix covers it.