FWP_E_INVALID_INTERVAL (0x80320021): Fix in 3 Steps

Cause 1: Windows Firewall Rule with a Broken Schedule

What's actually happening here is that one or more firewall rules define a time-based activation period—like "only apply this rule between 9 AM and 5 PM on weekdays"—but the interval stored in that rule is corrupt or nonsensical. The WFP driver rejects the rule outright with FWP_E_INVALID_INTERVAL (0x80320021).

This usually shows up in Event Viewer under Microsoft-Windows-Windows Firewall With Advanced Security/Operational with Event ID 5447. You'll see the error logged against a specific rule name. I've seen this happen after a bad third-party firewall uninstall, a failed Windows Update that touched the networking stack, or even a malformed Group Policy object on a domain-joined machine.

Fix: Find and delete the broken rule

1. Open PowerShell as Administrator.
2. Run netsh wfp show state. This dumps the entire WFP state into a file called wfpstate.xml in your current directory.
3. Open that XML and search for 0x80320021 or FWP_E_INVALID_INTERVAL. The surrounding <filter> block will show a <condition> with a userId field—that's the rule identifier.
4. Now match that rule ID to a Windows Firewall rule by running netsh advfirewall firewall show rule name=all verbose and looking for the same GUID in the output. Annoying, I know. Alternatively, scroll through the Windows Defender Firewall with Advanced Security MMC snap-in (wf.msc) and look for any rule with a custom schedule. Delete the offending rule.
5. If you're not sure which rule, the nuclear option is to export all rules first (netsh advfirewall export "C:\backup\firewall.wfw"), then reset the firewall entirely: netsh advfirewall reset. Re-import your clean rules after.

The reason step 3 works is that netsh wfp show state gives you the raw WFP filter database, which includes the exact error codes. The firewall MMC sometimes hides the schedule detail, so the XML is the ground truth.

Cause 2: Corrupted WFP Filter Store

Less common but nastier: the entire WFP filter store gets corrupted. This can happen after a sudden power loss while the WFP engine was updating rules, or after a failed driver installation for a VPN or anti-virus product that hooks into the network stack. The error then shows up on every boot or network change.

You'll know it's this cause if you see the error logged for multiple unrelated rules or even system-owned filters. Event ID 5447 will have a generic description like "The Windows Filtering Platform has detected an invalid interval in a filter."

Fix: Clear and rebuild the store

1. Open an elevated Command Prompt or PowerShell.
2. Run netsh int ip reset to reset TCP/IP. This also clears the WFP store.
3. Run netsh advfirewall reset to reset the Windows Firewall rules to defaults.
4. Reboot the machine.
5. If you use any third-party firewall or security suite, reinstall it cleanly after the reboot. Don't just enable it—uninstall first, reboot, then install fresh.

The reason netsh int ip reset helps is that it flushes the entire TCP/IP configuration and the associated WFP filters. Yes, it's a broad hammer, but when the store is corrupt, surgical fixes rarely work.

Cause 3: Misconfigured Group Policy (Domain Environments)

If your machine is joined to a domain, a Group Policy object (GPO) pushing scheduled firewall rules can be the source. The admin might have set a time interval with a start time after the end time, or used a date format that the local WFP engine interprets differently after a system language or time zone change. I've debugged a case where the GPO specified a schedule in UTC but the client was in UTC+5:30, creating a backward interval.

The symptom is consistent: the error appears on every Group Policy refresh (every 90-120 minutes by default), and it affects all machines receiving that GPO.

Fix: Identify and correct the GPO

1. On the affected machine, open an elevated PowerShell and run gpresult /h "C:\gpreport.html". Open the HTML report and look for any firewall policy that includes a Schedule setting.
2. On a domain controller, open Group Policy Management Console. Edit the GPO that contains the firewall schedule.
3. Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security > Inbound Rules (or Outbound). Find the rule with the schedule.
4. Edit the rule, go to the Scope tab, and under Schedule, verify that the start time is before the end time and that the date range is logical. If the GPO uses a custom time zone, standardize to UTC to avoid client-side misinterpretation.
5. Run gpupdate /force on the client and check the error goes away.

The reason step 4 is critical: Windows stores schedules as relative intervals, not absolute timestamps. If you set a rule to "apply from 14:00 to 12:00" (accidental swap), the WFP engine sees a negative duration and throws 0x80320021.

Quick-Reference Summary