Fix STATUS_FWP_TCPIP_NOT_READY (0xC0220100) Error

Quick Answer (for the impatient)

Restart the Base Filtering Engine service and the Windows Firewall service. Open an elevated command prompt and run: net stop BFE && net start BFE. Then net start MpsSvc. If that fails, reboot.

What's Actually Happening Here?

I've seen this error pop up on Windows 10 (build 1909 and later) and Windows 11, especially after a system update or a third-party security suite installs a kernel-mode firewall driver. The code 0xC0220100 maps to STATUS_FWP_TCPIP_NOT_READY — the Windows Filtering Platform (WFP) tells your app that the TCP/IP stack hasn't finished initializing. The real trigger? The Base Filtering Engine (BFE) service is either hung, disabled, or crashed during boot. This service controls all firewall and network security policies. If BFE doesn't start, MpsSvc (Windows Firewall) can't start either, and TCP/IP stays in a limbo state where it's half-loaded but not accepting connections.

I've debugged this at a customer site where a Symantec Endpoint Protection update broke the WFP driver stack. The result: every network-aware app threw this error at login. So don't blame your app — it's a system-level fight between firewall components.

Fix 1: Restart the Core Services

Press Win + R, type services.msc, hit Enter.
Find Base Filtering Engine. Right-click → Properties. Set Startup type to Automatic if it isn't. Click Start if it's stopped.
Find Windows Firewall. Do the same — set to Automatic, start it.
Find IKE and AuthIP IPsec Keying Modules (it depends on BFE). Set to Automatic and start.
Reboot. Test your network app again.

Why this works: BFE must be running before Windows Firewall. Most third-party firewalls also register filters through BFE. When BFE fails, the whole WFP subsystem can't initialize TCP/IP properly.

Fix 2: Reset the Winsock and WFP Catalog (If Fix 1 Fails)

If the services start but the error persists, the firewall filter chain is corrupted. This is common after uninstalling a third-party firewall without rebooting. Run this in an elevated command prompt (as Administrator):

netsh winsock reset catalog

netsh int ip reset reset.log

Reboot. Then reapply Fix 1. This clears any leftover filter drivers that might be blocking TCP/IP from completing its initialization.

Fix 3: Disable Third-Party Firewalls Temporarily

If you're running Norton, McAfee, Avast, or any real-time security suite with a firewall module, disable it completely (not just the UI). Uninstall that firewall component if the software allows. I've seen Avast's kernel-mode filter driver cause this exact error on Windows 11 22H2. After removal, reboot and check if the error disappears.

Fix 4: Check Group Policy or Security Center

Domain-joined machines often have Group Policy that disables Windows Firewall. But if the policy leaves BFE running but blocks MpsSvc, you get this half-baked state. Run gpresult /H gp.html and look for firewall-related policies. If you see Windows Firewall: Protect all network connections set to Disabled, that's normal — but then the policy should also allow BFE to start. If BFE is also disabled, that's your culprit.

Alternative: Repair the WFP Driver Manually

If nothing works, the WFP driver (tcpip.sys or fwpkclnt.sys) may be damaged. Run System File Checker: sfc /scannow. Then DISM: DISM /Online /Cleanup-Image /RestoreHealth. This fixed it for a client whose SSD had bad sectors corrupting the driver file.

Prevention Tip

Never install two firewall products. If you switch security suites, uninstall the old one completely using the vendor's removal tool (e.g., Norton Removal Tool, McAfee Consumer Product Removal Tool). Then reboot before installing the new one. Also, disable Fast Startup in Windows — that feature often prevents BFE from initializing correctly after a shutdown. Go to Power Options → Choose what the power buttons do → Uncheck Turn on fast startup. This alone stopped the error from recurring for one of my clients.

One last thing: if you're a developer hitting this from your app, you can retry the call with exponential backoff. But the real fix is at the system level — BFE and WFP need to be up before you call FwpmEngineOpen or similar. My rule: wait for the network to be available (listen for NetworkAvailabilityChanged in .NET or check IsNetworkAvailable in Win32). Don't assume TCP/IP is ready just because the system says it's booted.