FWP_E_RESERVED (0X80320029): Reserved Field Nonzero Fix

When You'll See This Error

You're trying to start a VPN client—maybe OpenVPN, WireGuard, or your corporate Cisco AnyConnect—and it crashes immediately with error code 0x80320029. Or you're running a tool like netsh wfp show state and get back FWP_E_RESERVED (0x80320029). The pattern is always: a reserved field that the Windows Filtering Platform (WFP) expects to be zero has been set to something else. This isn't a random glitch—it's a specific corruption in the firewall rules store.

What's Actually Happening Here

WFP is the kernel-level security layer that sits under Windows Firewall. Every network filter rule has a rigid structure defined by Microsoft. Certain fields are reserved for future use and must be zero. If a third-party application—usually a VPN, firewall, or security suite—writes a rule that accidentally sets one of those reserved bytes to a non-zero value, WFP rejects the entire operation. The error code 0x80320029 is literally: "Sorry, one of your reserved fields isn't zero."

What's the most common cause? Windows updates that don't clean up old driver versions, combined with a VPN client that updated its internal rule format but left stale rules behind. I've also seen it after uninstalling a firewall like ZoneAlarm or Comodo that didn't properly remove its WFP callout drivers.

The Fix: Two Steps, No Bloat

Skip the five-step registry edits you'll find on generic forums. The real fix is resetting the WFP state store and cleaning out corrupted rules. Here's exactly how:

Step 1: Reset the WFP State Store

1. Open Command Prompt as Administrator. Press Win+X → Terminal (Admin) or Command Prompt (Admin).
2. Stop the Windows Firewall service:

   net stop MpsSvc

3. Kill the WFP state store files. These live in %SystemRoot%\System32\spp\store\2.0. Delete the entire contents of that folder. Don't delete the folder itself—just the files inside. If Windows complains a file is in use, you missed step 2; reboot into Safe Mode with Networking and try again.
4. Restart the firewall service:

   net start MpsSvc

5. Run netsh wfp show state to verify the store is clean. You should see no errors.

Step 2: Nuke Corrupted Rules from the Third-Party App

Resetting the store alone won't keep the error away if the VPN client re-applies the bad rule on startup. You need to clear its rule cache too.

1. Uninstall the VPN client completely. Use the vendor's cleanup tool if they provide one (e.g., OpenVPN's openvpn-uninstall.exe, or Cisco's anyconnect_uninstall.exe).
2. Reboot. Yes, a full restart—not shutdown with fast startup. On Windows 10/11, shutdown with fast startup enabled doesn't fully clear kernel state. Use shutdown /r /t 0 or hold Shift while clicking Restart.
3. Reinstall the VPN client fresh. If you're using OpenVPN, grab the latest version from the official site—not an old MSI you saved on a USB stick.

If It Still Fails: Check for Leftover WFP Callout Drivers

Some firewalls and VPNs install kernel-mode drivers that register WFP callouts. These survive the uninstall process. Run this command to list them:

netsh wfp show filters | findstr /i "callout"

Look for entries with a "callout" or "provider" that matches the old app's name. If you see any, you need to manually delete the associated registry key under HKLM\SYSTEM\CurrentControlSet\Services that references that callout driver. This is risky—only do this if you're comfortable with regedits and have a backup. A safer alternative: use Autoruns from Sysinternals to disable the driver on boot, then remove it permanently after a clean reboot.

One more thing: if you're on Windows 11 23H2 or later, Microsoft tightened the WFP validation in a cumulative update. An old VPN client that worked fine before might suddenly trigger 0x80320029 after that update. In that case, the fix is updating the VPN client, period. The old rule format isn't valid anymore.