Fix FWP_E_CALLOUT_NOT_FOUND 0x80320001 in Windows

When this error actually shows up

You're trying to run a VPN client or a third-party firewall — say, WireGuard, OpenVPN, or a corporate security app — and it fails with FWP_E_CALLOUT_NOT_FOUND (0x80320001). The app starts but can't establish a connection. Event Viewer shows a WFP (Windows Filtering Platform) error from the Microsoft-Windows-WFP source with that code.

What's actually happening here is that the Windows Filtering Platform — that's the kernel-level packet filtering engine built into Windows since Vista — can't find a callout. A callout is essentially a callback function that a driver registers with WFP to inspect or modify network traffic at specific layers. When the callout is missing, the filtering rule that references it becomes dead weight, and any app depending on that rule fails.

Root cause: what makes a callout disappear

A callout doesn't vanish on its own. Three things cause it:

Driver not loaded. The driver that registered the callout was unloaded — maybe you uninstalled a security suite, or Windows Update replaced it mid-flight. The callout registration lives in the driver's memory, not in persistent storage. No driver, no callout.
Driver disabled or failed to start. A driver's start type was set to DISABLED (0x4) or DEMAND_START (0x3) when it needs SYSTEM_START (0x1) or BOOT_START (0x0). Or the driver crashed on boot — check sc query for a STOPPED state with exit code 1.
Corrupted or missing callout entry in the WFP state store. Windows stores callout registrations in a kernel structure that gets rebuilt at boot when drivers register. If a driver registered a callout but that driver's INF file failed to install properly, the callout GUID is missing from the in-memory table. Unlikely but possible after a botched update.

The common thread: a driver didn't survive a reboot, or an installation left a dangling reference to a callout that was never there to begin with.

The fix: four steps that actually work

Skip the sfc /scannow and DISM noise — they won't touch WFP state. Here's the direct path.

Identify which driver owns the missing callout.
Run this as Administrator:
```
netsh wfp show state
```
This dumps the entire WFP state to a file named wfpstate.xml in the current directory. Open it and search for 0x80320001 or FWP_E_CALLOUT_NOT_FOUND. Near it, you'll see a calloutId (a GUID) and the error detail. The GUID corresponds to a specific driver — look for the providerName field in the same file. That's the driver at fault.
Check the driver's current state.
Open an elevated command prompt and run:
```
sc query <drivername>
```
Replace <drivername> with the name from step 1 — for example, wintun for WireGuard, or Vsock for some VMware tools. Look at STATE. If it says STOPPED, the driver isn't running. If it's RUNNING, skip to step 4.
Start the driver and set it to auto-start.
```
sc config <drivername> start= auto
sc start <drivername>
```
The start= auto syntax is picky — there must be a space after start=. Then start it. If it fails with 1058 (service disabled), the driver's start type was set to DISABLED. Change it to SYSTEM_START (0x1) or BOOT_START (0x0) via the registry:
```
reg add "HKLM\SYSTEM\CurrentControlSet\Services\<drivername>" /v Start /t REG_DWORD /d 1 /f
```
Then reboot. The driver should auto-start.
Re-register the driver's callouts.
If the driver is running but the error persists, the callout registration is stale or corrupted. Run the app's installer again — most VPNs and firewalls have a repair option. That re-registers callouts during driver load. For WireGuard, do wintun.dll install. For OpenVPN, run the TAP driver installer. For third-party firewalls, uninstall and reinstall.

If it still fails

You've done the steps and the error won't budge. Check these:

Boot logging. Enable driver boot logging (bcdedit /set bootlog yes, reboot, check %SystemRoot%\ntbtlog.txt). Look for the driver name with failed next to it. If the driver fails to load at boot, it won't register its callouts — that's a driver corruption or incompatibility issue.
Third-party security conflict. Some AV suites — especially McAfee, Norton, or Webroot — hook into WFP and can block callout registrations. Disable the AV's real-time protection entirely, then install the driver again. If it works, add the driver to the AV's exclusion list.
WFP state corruption at boot. This is rare but happens after a failed update or disk check. Boot from a Windows installation media, open Command Prompt with Shift+F10, and run bcdedit /set {current} safeboot minimal. Reboot into Safe Mode, then run net start <drivername> manually. If Safe Mode works, the problem is a third-party driver conflict in normal mode.

The reason step 3 works in Safe Mode is that Windows loads only the bare minimum of drivers — no security suites, no WFP-controlling AV bloat. That isolates the issue to your driver's registration logic.

If none of this helps, the driver itself is likely incompatible with your Windows version. Check the vendor's site for a newer version that explicitly supports your build (e.g., Windows 11 22H2). Some VPN providers shipped drivers that registered callouts in a deprecated format — WFP callout handling changed between Windows 10 20H2 and 11. That's a vendor problem, not yours.