FWP_E_INVALID_PARAMETER (0x80320035) Fix for Windows

You're getting FWP_E_INVALID_PARAMETER (0x80320035), and Windows tells you "The parameter is incorrect." What's actually happening here is that the Windows Filtering Platform (WFP) — the kernel-level firewall engine that underpins Windows Defender Firewall, IPsec, and many third-party security tools — received a call with an invalid parameter. That parameter could be a malformed filter condition, a pointer to garbage memory, or a rule that references a non-existent layer.

I've seen this error pop up in three specific real-world scenarios: after a third-party antivirus uninstall leaves behind WFP callout drivers, after a Windows update partially corrupted the WFP store, or when a VPN client installs bogus filters. The fixes below are ordered by likelihood of success.

The WFP store is corrupted — reset it with netsh

This is the most common cause. The WFP store lives under %SystemRoot%\System32\drivers\wfplwfs.sys and a companion database file. If that database gets a single bad byte, every filter operation fails with this error. You'll see it when trying to enable Windows Defender Firewall, start the Windows Firewall service, or run netsh advfirewall show allprofiles.

1. Open an elevated Command Prompt (right-click Start > Windows Terminal (Admin)).
2. Run this command to reset the WFP store and rebuild it from the default policy:
   

   netsh wfp reset

   
   This deletes the existing WFP database and reloads the default firewall rules. It doesn't affect network connectivity — it just clears the corrupted state.
3. Reboot the machine. The error should be gone.

If netsh wfp reset fails with "Access denied" even as admin, you've got a deeper problem — likely a filter driver (from Comodo, McAfee, or an old VPN client) that's holding a lock on the WFP database. That's fix #2.

A third-party filter driver is corrupting WFP calls

Some security software and VPN clients install kernel-mode drivers that hook into WFP to inspect or block traffic. If that driver is buggy, outdated, or partially uninstalled, it can pass garbage parameters to WFP's FwpsCalloutRegister or FwpsFilterAdd functions. The result? 0x80320035 every time a process tries to query firewall rules.

1. Open Device Manager (right-click Start > Device Manager).
2. Go to View > Show hidden devices.
3. Expand "Non-Plug and Play Drivers". Look for entries named like cfw* (Comodo), mx_wfp* (McAfee), vsock* (VMware), or anything from a VPN vendor you've uninstalled.
4. Right-click any suspicious driver, select Properties > Driver tab, and check the Driver Provider and Version. If it's from a company you don't use anymore, disable it: right-click > Disable device.
5. Reboot. Then run netsh wfp reset again (fix #1) to clear any lingering corrupt state.

The reason step 3 works is that disabling the driver prevents it from loading at boot, so WFP no longer receives its broken callbacks. If you find an offending driver, uninstall the parent software completely using Revo Uninstaller or the vendor's cleanup tool, then delete the driver file from %SystemRoot%\System32\drivers. Do not delete random drivers — stick to ones you know came from software you've removed.

A misconfigured firewall rule has invalid parameters

Less common, but I've seen it when someone manually exported and imported firewall rules between different Windows versions (e.g., Windows 10 22H2 to Windows 11 24H2). The rule might reference a WFP layer ID that doesn't exist on the newer OS, or use a condition key that's been deprecated.

1. Open an elevated PowerShell prompt.
2. Export all firewall rules to a file:
   

   netsh advfirewall export "C:\firewall_backup.wfw"

3. Reset the firewall policy entirely:
   

   netsh advfirewall reset

   
   This nukes all custom rules and re-enables the default profile.
4. Reboot. The error should be gone. If you need your custom rules back, you'll have to manually re-create them — importing the backup might re-import the bad rule. Don't do that. Instead, use the backup as a reference list and re-add rules one by one, testing each.

The reason step 3 works is that netsh advfirewall reset deletes the entire rule set from the WFP store, not just the UI view. Any rule with an invalid parameter is gone. You're starting fresh.

Quick-reference summary table

One last thing: if none of these work, check the Windows Event Log under Applications and Services Logs > Microsoft > Windows > Windows Filtering Platform. Look for event IDs 5447 (filter add failure) or 5440 (callout registration failure). The event details often include the specific layer GUID or filter ID that's broken — that's your needle in the haystack. You can then write a tiny PowerShell script to remove that specific filter. But 99% of the time, fix #1 alone handles it.