Fix FWP_E_TXN_IN_PROGRESS 0X8032000E Error

What's This Error Really Mean?

You're getting 0X8032000E with the message "The call is not allowed from within an explicit transaction." This happens when your code or a service tries to call a Windows Filtering Platform (WFP) function while an explicit transaction is open. WFP transactions are used for batch configuration—things like adding firewall rules or changing filters atomically. The problem is, some API calls just won't work inside that transaction context.

I've seen this most often with third-party antivirus or VPN software that tries to add firewall rules during installation, and also with custom scripts or management tools that use WFP directly. If you're running a PowerShell script or a .NET application that calls FwpmTransactionBegin and then tries to do something simple like query a provider, boom—you get this error.

The 30-Second Fix: Close the Transaction

This is the simplest thing you can try. If an explicit transaction is running, you've got to either commit it or abort it before making certain WFP calls. Here's how:

1. Open a command prompt as Administrator (right-click Command Prompt, select Run as administrator).
2. Type netsh wfp show state and press Enter. Look at the output—if you see something like "Transaction count: 1" or "Explicit transaction active: Yes," you've got a hanging transaction.
3. To clear it, run: netsh wfp capture start then netsh wfp capture stop. That forces a transaction cleanup.
4. Reboot. I know it's cliché, but it kills any orphaned transaction handles.

After reboot, try whatever was failing. If it works, you're done. If not, move to the next section.

The 5-Minute Fix: Reset the Firewall Service

Sometimes the transaction gets stuck inside the Base Filtering Engine (BFE) service. Killing and restarting it does the trick. But be careful—this can break your network rules temporarily.

1. Press Win + R, type services.msc, press Enter.
2. Scroll down to Base Filtering Engine. Right-click it and select Stop.
3. Right-click it again and select Start.
4. Now restart the Windows Firewall service the same way: stop it, then start it.

What you should see: After restarting BFE, any orphaned WFP transaction should be cleaned up. Your network might drop for 5-10 seconds during the restart—that's normal.

Try your operation again. If it still fails, there's a code-level issue, and you'll need to fix it at the source.

The 15-Minute Fix: Fix the Calling Code

This fix is for developers or anyone who controls the software throwing the error. The root cause is almost always bad transaction management. Here's the pattern:

// WRONG - calls inside explicit transaction
FwpmTransactionBegin(engineHandle, 0, NULL);
FwpmFilterAdd(engineHandle, &filter, NULL, &id);
// This next call fails with 0X8032000E
FwpmProviderGetByKey(engineHandle, &providerKey, &provider);
FwpmTransactionCommit(engineHandle);

// RIGHT - move non-transactional calls outside
FwpmProviderGetByKey(engineHandle, &providerKey, &provider);
FwpmTransactionBegin(engineHandle, 0, NULL);
FwpmFilterAdd(engineHandle, &filter, NULL, &id);
FwpmTransactionCommit(engineHandle);

You need to separate calls that don't need to be in the transaction (like queries and enumerations) from those that do (like adds, deletes, or updates). Microsoft's documentation says it explicitly: calls that read data must happen outside an explicit transaction.

If you're using PowerShell with the NetSecurity module, you might hit this if you manually start a transaction with Start-Transaction and then try to use New-NetFirewallRule inside it. Don't do that. The NetSecurity cmdlets manage their own transactions internally.

How to Check if Your Code Has This Problem

If you're not a developer but you're supporting an app that throws this, grab a trace with Process Monitor or WFP's own logging:

1. Open an elevated command prompt.
2. Run netsh wfp show netevents to see recent WFP events. Look for the call that errored out.
3. Check your application logs in Event Viewer under Applications and Services Logs -> Microsoft -> Windows -> Windows Filtering Platform. You'll see error IDs pointing to the API call that failed.

The real fix is to update the app or script to manage transactions correctly. If you can't update it, contact the vendor and tell them their code is calling WFP APIs inside an explicit transaction. They'll know exactly what that means.

Preventing This Going Forward

When you write firewall management scripts or tools, follow these rules:

• Only use FwpmTransactionBegin / FwpmTransactionCommit / FwpmTransactionAbort around write operations (add, delete, set).
• Keep read operations (get, enumerate) outside the transaction.
• Never nest transactions. If you call FwpmTransactionBegin twice without a commit or abort in between, the second call will fail.
• Always handle cleanup—if your code crashes mid-transaction, you leave a dangling transaction that causes problems for everyone.

That's it. You should be up and running now.