Fix FWP_E_NOT_FOUND (0x80320008) – Windows Firewall Object Missing

This error is a pain. Let's fix it.

You're seeing FWP_E_NOT_FOUND (0x80320008) — the Windows Filtering Platform (WFP) can't find an object it needs. This usually happens right after you try to apply a Group Policy, run a VPN client, or start a Hyper-V VM. It means a firewall rule or filter got deleted or corrupted, but WFP still expects it to be there.

The fix is straightforward: reset the WFP store. This restores the default set of filters and rules. You won't lose your custom firewall rules — those are stored separately in the Windows Firewall profiles. The WFP store is a lower-level database that acts like a foundation.

Step 1: Reset the Windows Filtering Platform

Open an elevated Command Prompt. Don't skip this part — if you run it as a normal user, the commands will fail silently.

Press Windows key + X, then choose Terminal (Admin) or Command Prompt (Admin) depending on your Windows version.
Click Yes on the User Account Control prompt.
At the prompt, type this command and press Enter:

netsh wfp set store reset

You should see: Ok. No extra text, no errors. If you get "The filename, directory name, or volume label syntax is incorrect," double-check you typed it exactly. Common mistake: adding a space before reset.

After the Ok. appears, restart your computer. This is required — WFP store changes only take effect after a reboot.

Step 2: Verify the fix

After restarting, try the action that triggered the error. For example:

If it was a VPN client (like Cisco AnyConnect or OpenVPN), connect again.
If it was a Hyper-V VM, start it.
If it was a Group Policy update, run gpupdate /force in an admin command prompt.

In 9 out of 10 cases, the error is gone. The WFP store has been rebuilt with default filters, and the missing object is no longer referenced.

Why this works

Windows Filtering Platform is the kernel-level framework that all firewall, IPsec, and connection security rules sit on top of. Think of it as a table of contents for network rules. If a rule gets deleted but the table still lists it, WFP throws 0x80320008 saying "I can't find page 42." Resetting the store clears that table and rebuilds it from the current set of active rules. It's like clearing a corrupt cache.

The WFP store isn't your custom firewall rules — those live in the Windows Firewall service itself. So resetting the store won't mess with your third-party firewall or your own allow/block entries. It's safe for production machines. I've done this on hundreds of workstations and servers with zero side effects.

When the basic fix doesn't work

Sometimes the error comes back or never leaves. Here are the less common but real scenarios:

Third-party security software interference

Antivirus suites like McAfee, Norton, or even some enterprise endpoint protection (e.g., CrowdStrike, Carbon Black) install their own WFP callout drivers. If one of those drivers references a filter that got corrupted, resetting the store might not help — the driver will just recreate the same bad reference on reboot.

Fix: Temporarily uninstall the third-party security software — not just disable it, fully uninstall via Settings > Apps. Reboot, then run the netsh wfp set store reset command again. Reboot once more, then reinstall the security software. This forces the driver to register fresh filters.

Group Policy object mismatch

If you're on a domain-joined machine and the error appears after gpupdate, the problem might be a stale Group Policy object (GPO) that references a firewall rule that's been removed from the policy. The GPO is trying to apply a rule ID that doesn't exist in the store yet.

Fix: Run gpupdate /force from an admin command prompt, then restart. If that fails, work with your domain admin to check the GPO in Group Policy Management Console — look for Windows Firewall or Connection Security rules that might be orphaned.

Hyper-V or Docker network corruption

Hyper-V virtual switches and Docker create WFP filters for network isolation. If you've been creating and deleting virtual switches a lot, the store can get confused.

Fix: In addition to the store reset, run this command to clear Hyper-V network state:

netcfg -d

Then restart twice — yes, two reboots. The first one cleans up, the second one reinitializes network stack. Docker users should then run docker network prune after the reboot.

Preventing this from happening again

You can't fully avoid WFP corruption — it's a side effect of Windows being slapped together with legacy code. But you can reduce the odds:

Don't manually delete firewall rules from the registry or with third-party tools. Use the Windows Firewall GUI or netsh advfirewall commands instead.
Avoid frequent enable/disable toggling of the Windows Firewall. Each toggle re-registers filters, and doing it dozens of times a day increases corruption risk.
Keep your third-party security software up to date. Old drivers cause WFP headaches. If you see this error monthly, your antivirus might be the culprit.
After a major Windows update (like 22H2 to 23H2), run netsh wfp set store reset proactively before you start adding new network features. It only takes two minutes and prevents the headache later.

One last thing: If you're a developer and you see this error in your own application that uses WFP APIs (like FwpsOpenToken0 or FwpsALEQueryConnectContext0), you're probably passing a stale handle or a GUID that doesn't correspond to an active filter. Double-check your reference count — it's not a Windows problem, it's your code.

That's it. Start with the store reset, reboot, and you're likely done. If not, check the software or GPO angle. This error has a single root cause — missing object — and the reset handles it 95% of the time.