FWP_E_DYNAMIC_SESSION_IN_PROGRESS (0x8032000B) fix

Quick answer

Close your dynamic WFP session by calling FwpmEngineClose on the session handle, or restart the service that opened it. Then retry your API call outside that session.

What's happening here?

You got FWP_E_DYNAMIC_SESSION_IN_PROGRESS (0x8032000B) – that's Windows Filtering Platform saying, "Hey, you're already inside a dynamic session, and this call isn't allowed from in here." This typically shows up when you're writing a firewall management tool, a VPN client, or a security app that uses WFP. I've seen it most often with custom software that opens a dynamic session for bulk rule changes, then tries to add a single rule or query the engine inside that same session. The WFP API has a strict rule: some calls – like FwpmFilterAdd or FwpmNetEventSubscribe – just don't work from within a dynamic session. They need a standard session or no session at all.

Fix steps

1. Identify the session – If you're writing code, check where you called FwpmEngineOpen with FWPM_SESSION_FLAG_DYNAMIC. That's the dynamic session. If you're using a tool like netsh wfp, check if there's an open dynamic session from another tool or service. Run netsh wfp show sessions in an admin command prompt to list current sessions.
2. Close the dynamic session – In code, call FwpmEngineClose(hEngine) where hEngine is your session handle. In netsh, use netsh wfp close session and specify the session ID. Or just restart the service that owns it – like net stop MpsSvc && net start MpsSvc for Windows Firewall.
3. Open a new session without the dynamic flag – When you reopen, pass 0 for sessionFlags in FWPM_SESSION. Or use netsh wfp open session without any dynamic option.
4. Retry your original call – That FwpmFilterAdd or whatever failed should now work. Test it. If it still fails with the same error, you didn't actually close the dynamic session. Check your code logic – maybe the session handle wasn't closed properly.

Alternate fixes

If closing the session doesn't work or you can't find it, here's what else to try:

• Restart the WFP service – Run net stop BFE && net start BFE in an admin command prompt. BFE (Base Filtering Engine) manages WFP. This kills all sessions. Warning: it'll break your firewall for a few seconds. Don't do this on a production server without a maintenance window.
• Switch to a different API pattern – If you need to make multiple changes atomically, keep the dynamic session but move the failing call outside it. Open a second, non-dynamic session just for that one call. WFP lets you have multiple handles at once.
• Check third-party software – Antivirus, VPNs, and firewall apps like Norton, McAfee, or Cisco AnyConnect often open dynamic sessions. Uninstall or disable them temporarily, then test your call. If the error goes away, you've got a conflict. Reinstall the third-party software or contact their support.

Prevention tip

The real fix is understanding the WFP session model. A dynamic session is meant for temporary, atomic changes – like reconfiguring a bunch of filters and committing them all at once. Calls that subscribe to events or query persistent objects just don't belong there. Map out your API calls first. Use a dynamic session only when you need to batch changes. For everything else, use a standard session. That one design decision will save you this error forever.