Fix STATUS_FWP_CONTEXT_INCOMPATIBLE_WITH_LAYER 0XC022002E

This Windows error pops up when a firewall rule or VPN software uses a provider context that doesn't match the filtering layer. I'll show you how to track down and fix the bad rule.

What triggers this error

You'll see 0XC022002E (STATUS_FWP_CONTEXT_INCOMPATIBLE_WITH_LAYER) when you try to add or modify a Windows Filtering Platform (WFP) rule, and the provider context you're referencing doesn't match the filtering layer. It's common after:

Installing a VPN client that didn't clean up its rules (NordVPN, ExpressVPN, Cisco AnyConnect are repeat offenders)
Running a third-party firewall that conflicts with Windows Defender Firewall
Manually editing WFP rules with netsh wfp or PowerShell and getting the layer wrong

The error is misleading because it's not a hardware problem or a driver crash. It's a configuration mismatch. The system is saying: "You gave me a context object that's meant for a different layer, so I can't apply it here."

First cause: stale or orphaned VPN provider contexts

This is the #1 reason. VPN software registers a provider context (like a unique GUID) during install, then ties it to a firewall rule at the FWPM_LAYER_ALE_AUTH_CONNECT_V4 or V6 layer. When the VPN uninstalls badly, the rule stays but the context disappears. The next thing that tries to modify that rule hits the error.

How to fix it

Open PowerShell as Administrator. Press Win+X, choose Windows PowerShell (Admin).
List all WFP filters. Run:
```
netsh wfp show filters
```
Wait 30 seconds — this command takes time because it dumps the entire WFP state. You should see a long table with columns for Layer, Filter ID, and Provider Context.
Look for orphaned entries. Find any filter where the Provider Context column shows a GUID that looks like {00000000-0000-0000-0000-000000000000} or a random GUID with no matching netsh wfp show providers output.
Export current WFP state in case you break something:
```
netsh wfp export policy C:\backup-wfp-xml
```
This saves to a file you can re-import with netsh wfp import policy if needed.
Delete the bad filter. Use:
```
netsh wfp delete filter id=YOUR_FILTER_ID
```
Replace YOUR_FILTER_ID with the actual number from step 3. If the command succeeds, you'll see Ok — no extra messages.

After deleting the orphaned filter, try your original operation again. The error should be gone. If you see The filter does not exist, it means the filter was already deleted by something else, or you typed the ID wrong.

Second cause: wrong layer in a custom PowerShell rule

This happens when you write a script to add a firewall rule and accidentally use a provider context from one layer on another. For example, taking a context meant for FWPM_LAYER_INBOUND_TRANSPORT_V4 and applying it to FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4.

How to fix it

Identify the provider context GUID. Run:
```
netsh wfp show providers
```
Look at the Provider Contexts section. Each row shows a GUID and the layer it's registered for.
Check your rule's layer. If you're using PowerShell, you might have a line like:
```
$condition = @()
$condition += New-WFACondition -FieldName ...
New-WFARule -LayerName "FWPM_LAYER_ALE_AUTH_CONNECT_V4" -ProviderContext $context
```
The $context variable must come from a provider registered at that same layer.
Re-register the provider context for the correct layer, or create a new provider context that matches. The safest fix is to remove the rule and re-create it without a provider context (unless you absolutely need it for traffic inspection).

Clean up with:

Remove-NetFirewallRule -Name "YourRuleName"
New-NetFirewallRule -DisplayName "YourRuleName" -Direction Outbound -Action Allow -Protocol TCP -LocalPort 443

This bypasses the context issue entirely.

If you need that provider context for your app to work (like a VPN that inspects packets), contact the vendor for a corrected install or a registry patch that fixes the layer mapping.

Third cause: registry corruption in provider context store

Less common, but I've seen it after a failed Windows update (specifically KB5012170 on Windows 10 21H2) or after restoring a system image from a different hardware spec. The WFP provider context database inside HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BFE\Parameters gets scrambled.

How to fix it

Back up the registry key. Open regedit.exe as Admin. Navigate to:
```
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BFE\Parameters
```
Right-click Parameters, select Export, save the .reg file somewhere safe.
Delete the subkeys named ProviderContexts and ProviderContextMapping. These are binary blobs that WFP regenerates on reboot.
Restart the Base Filtering Engine service. Open an Admin PowerShell and run:
```
Stop-Service BFE -Force
Start-Service BFE
```
When BFE restarts, it rebuilds the provider context store from scratch using the remaining registry data. You may see a brief network interruption (10-15 seconds).
Test your operation. If the error persists, restore the backup by double-clicking the .reg file you saved, then repeat steps 2 and 3 with more care — you might have missed a subkey.

I don't recommend this as a first step because deleting those registry subkeys can break all your third-party firewall rules. Only do it if steps 1 and 2 didn't help.

Quick-reference summary

Cause	Symptom	Fix	Difficulty
Orphaned VPN provider context	Error appears after uninstalling VPN	Delete orphaned filter with `netsh wfp delete filter`	Intermediate
Wrong layer in custom PowerShell rule	Error during rule creation	Remove context or re-register for correct layer	Intermediate
Registry corruption in BFE Parameters	Error after Windows update or restore	Delete `ProviderContexts` subkeys, restart BFE	Advanced

Start with the first fix. Nine times out of ten, it's a dead VPN rule hanging around. If you're still stuck after trying all three, run netsh wfp capture and look at the XML output for any filter with a layerId that doesn't match the providerContext layer — that's your smoking gun.