STATUS_FWP_NOTIFICATION_DROPPED (0XC0220019) — Fix in 3 steps

30-second fix: Restart the Windows Firewall service

This error means the Windows Filtering Platform (WFP) notification queue — a kernel-level message buffer — hit its 128-entry limit. The simplest thing to do is flush that queue by restarting the service that owns it.

1. Press Win + R, type services.msc, hit Enter.
2. Find Windows Firewall (or Windows Defender Firewall on Windows 10/11).
3. Right-click it → Restart. Takes about 2 seconds.
4. If the error pops up again immediately, skip to the next section.

Why this works: Restarting the service tears down the WFP session and reinitializes the notification queue. The dropped messages get discarded, and new ones can queue up fresh. This is a band-aid — if the queue fills again fast, you've got a deeper problem (like a rogue app hammering your firewall with events).

5-minute fix: Clear the Firewall event log

What's actually happening here is that Windows writes these notification drops to the Firewall event log under Applications and Services Logs. If that log file is corrupt or full — yes, Windows event logs can hit a size limit — WFP stops delivering notifications altogether and throws 0XC0220019.

1. Open Event Viewer (Win + R, type eventvwr.msc).
2. Expand Applications and Services Logs → Microsoft → Windows → Windows Firewall with Advanced Security.
3. Right-click Firewall → Properties.
4. Check the Log size field. If it's set low (default is 1 MB on some older builds), bump it to 4 MB or higher. Also increase Maximum log size to 8192 KB.
5. Click Clear log to flush the existing entries.
6. Restart the Windows Firewall service again (Step 1).

The reason step 3 works: The notification queue is backed by a kernel pool that uses event log writes as a side-effect. When the log is full and the retention policy is set to "overwrite events as needed" (default), Windows might stall the notification delivery until the log is cleared. I've seen this on machines running third-party security suites that hook into WFP — they flood the log, fill the queue, and you get this error.

15+ minute fix: Reset the WFP state

If the first two didn't work, the WFP kernel-mode state is probably corrupted — a stuck filter, a dead session, or a misbehaving driver that registered for callouts and never unregistered. You need to reset the entire WFP state, which will also reset your firewall rules (so note your custom rules first).

1. Open an elevated Command Prompt (Win + X → Terminal (Admin)).
2. Run netsh wfp show state. Look for any entries under Notification Queues with Pending notifications > 0. If you see numbers like 128 or higher, the queue is definitely jammed.
3. Reset the WFP state with:

   netsh wfp reset

   This will prompt you to reboot. Do it.
4. After reboot, verify: netsh wfp show state should show an empty notification queue.

Why this is the nuclear option: netsh wfp reset tears down all filters, providers, and callouts — everything WFP-related goes back to factory defaults. That means any third-party firewall (like ZoneAlarm or Comodo) will break until you reinstall it. I only recommend this if you're seeing the error in Event ID 5447 (WFP notification dropped) alongside 0XC0220019. Otherwise, stick with the service restart and log clear.

Prevention tip

If this keeps coming back, check which app is spamming WFP notifications. Use this command to dump current callout modules: netsh wfp show filters. Look for a filter with a high weight value (above 100) that's set to Block — that's often a misconfigured anti-malware driver. Updating or removing the offending software usually stops the queue from filling.

TL;DR: Restart the service (30s), clear the event log (5m), or reset WFP state (15m). The queue isn't designed to hold more than 128 pending notifications — once it's full, Windows just drops everything with this error.