STATUS_FWP_DYNAMIC_SESSION_IN_PROGRESS fix that actually works
You're getting this firewall error when a Windows Filtering Platform session is already open. Here's how to kill it fast.
Yeah, this error is annoying. It pops up when you're trying to change firewall rules or run a script that touches Windows Filtering Platform (WFP) — and some other session already has a lock on it. Happens a lot with VPN clients, security software, or even leftover PowerShell commands that didn't close cleanly.
The quick fix: kill the session
Open an elevated Command Prompt (right-click, Run as Administrator). Run this:
netsh wfp set options netevents = off
netsh wfp set options netevents = on
This toggles WFP's netevent mode, which forces the session to reset. Nine times out of ten, that's it. You can now run your firewall command again.
If that doesn't cut it, try the nuclear option:
netsh advfirewall reset
That resets the entire Windows Firewall policy. It'll nuke any custom rules you added — so make sure you have a backup. I've seen this fix the error when a VPN client left a session hanging after disconnect.
Why this happens
WFP uses sessions to manage firewall states. When an app starts a session and doesn't release it — crash, improper shutdown, or a race condition — the system blocks new calls with 0XC022000B. The netsh commands above close any stale session by resetting the WFP engine's internal state. No need to reboot 90% of the time.
The culprit is almost always a third-party firewall, VPN client (I'm looking at you, Cisco AnyConnect and OpenVPN), or a script that calls Add-NetFirewallRule in a loop without proper cleanup. The WFP session gets orphaned when the process dies unexpectedly.
If netsh doesn't work
Sometimes the session is locked so tight netsh can't touch it. Here's what you do:
- Stop the Windows Firewall service. Run
net stop MpsSvcin an elevated prompt. Wait 5 seconds, then start it again withnet start MpsSvc. This forces WFP to drop all sessions and reinitialize. Don't bother stopping it via Services GUI — takes longer and rarely works different. - Kill the offending process. If you know which app started the session — like a VPN client — close it properly. If it's stuck, use Task Manager to end the process tree. Then run the netsh toggle above.
- Check for driver conflicts. Some security software (McAfee, Symantec) installs WFP callout drivers that hold sessions open. Run
fltmc instancesto see mini-filter drivers. If you see something suspect, disable it in msconfig and reboot.
In rare cases on Server 2019 or Windows 10 1809+, I've had to reboot the machine. But that's the exception. A reboot always clears the session, but it's a sledgehammer when you need a scalpel.
Less common causes you should know
| Trigger | What happens |
|---|---|
PowerShell script using New-NetFirewallRule in a loop | Script crashes mid-execution, leaving the WFP session open. Use try/finally to ensure cleanup. |
| Docker with Windows containers | Docker's networking component sometimes holds a WFP session. Restart Docker Desktop or run net stop Docker then net start Docker. |
| Hyper-V virtual switch changes | Adding/removing a virtual switch can trigger this error. Toggle the Hyper-V Virtual Switch service. |
| Windows Sandbox | Sandbox uses WFP for isolation. Close it, then run the netsh toggle. |
Prevention: don't let it happen again
If you're writing scripts that touch Windows Firewall, add cleanup code. Here's a bare-bones PowerShell example:
$session = New-Object -ComObject HNetCfg.FwPolicy2
# Do your firewall rule changes here
[System.Runtime.InteropServices.Marshal]::ReleaseComObject($session) | Out-Null
Remove-Variable session
This explicitly releases the COM object. Without it, PowerShell holds the session until the process ends — and if you're running scripts in the same console, you'll hit the error.
Also, avoid running multiple firewall tools at once. Windows Firewall, third-party firewalls, and VPN clients all fight over WFP sessions. Stick to one, or at least close the others before making changes.
One more thing: if you see this error after a Windows Update, roll back the update. I've seen KB5006670 on Windows 10 21H2 cause this exact issue. Uninstalling it fixed it for three clients.
Was this solution helpful?