[Bug] Repeated notifications for filtered processes.

[9wow]

Checklist

• I have used the search function to see if someone else has already submitted the same bug report.
• I will describe the problem with as much detail as possible.

App version

v.3.9.1

Windows version

Windows 11 Pro 25H2

Steps to reproduce

Accept the Simplewall app's update request (to a Pre-release version???)
Open Simplewall

Expected behavior

fixed repeatedly notifications (issue #2107)

Actual behavior

Simplewall spams notification pop-ups from the same processes I already allowed or denied, even when deactivating (Disable Filters).
Same behavior listed here (issue #2107) which is said to be fixed in v.3.9.1.
This version also minimizes fullscreen applications when a notification is given. None of these issues exist in v.3.8.7

Logs

No response

[henrypp]

give me name of filter displayed notification, or screenshot

[aminya]

In the last version, I constantly get notifications for svchost and System. Previous versions did not have this issue. Downgrading to 3.8.7 fixes the problem

[Bokai-Bi]

Experiencing same problem with Firefox after update to newest version of simplewall.

Initially display without detail, getting details around 5 seconds later

Ignoring the notification does not interfere with normal use of the application

[cev-api]

Yes please fix this, its an absolute nightmare, constantly spamming me with the same thing no matter what I do, allow, create rule, block, ignore. I run this on multiple PC's and they're all affected and feature the same apps/rules in the alerts.

These alerts appear about 10-30 seconds after each other non stop forever.

[68498468]

I have this problem too; it's very easy to reproduce every few minutes using Deluge with about twenty active torrents.

I won't post a screenshot for privacy reasons but the address and host change with every pop-up.

[henrypp]

this filter is part of a rule that restricts inbound and outbound traffic

this filter is part of a rule that blocks DNS request

this garbage is not main, disable dumbass defender firewall, this stupid shit has 0 IQ (same as its authors, lol)

hahah, defender blocks DNS requests just for fun, idiots

[krzemien77]

Just to report that I updated from v3.9 to v3.9.1 some half an hour ago or so, and am not seeing any more such issues - as reported above and here.

Many thanks @henrypp for tending to this annoying behaviour and getting it fixed in no time!

[oopman2002]

v3.9.1 resolved my issues. Thank you after 3 days of constantly clicking "Allow."

[cev-api]

Yeah all good now thanks <3

[rlsalgueiro]

Back to 3.8.7. versions 3.9.0 and 3.9.1 are duplicating the apps internet access.

Window 11 home, Version 25H2, build 26200.8894

[6BCC2C3896]

[Bug] v3.9 intermittently suppresses and repeats notifications for blocks created by another WFP provider

App version

SimpleWall 3.9

Windows version

Windows 10 Pro N 22H2, build 19045, x64

Other relevant software

• ExpressVPN for Windows
• ExpressVPN Network Lock / WFP filtering
• Windows Firewall enabled
• SimpleWall configured with outbound filtering and network notifications

Summary

After updating SimpleWall to version 3.9, network notifications became unreliable when ExpressVPN's WFP filters were active.

The behavior is not limited to one application. It affected:

• ChatGPT/Codex desktop
• Codex CLI
• Granola
• Wispr Flow
• Spotify
• Chrome and Windows services in earlier tests

Applications can be allowed in SimpleWall and work normally for some time, but then network access is blocked without a visible notification.

At other times, notifications suddenly begin appearing later, sometimes after starting an unrelated WFP diagnostic or generating another network event.

Some notifications then repeat even after pressing Allow.

Important distinction

The popup sometimes identifies the blocking filter as belonging to ExpressVPN, for example:

ExpressVPN WFP Tool - block all outbound IPv4

One captured example was:

• Application: spotify.exe
• Direction: outbound
• Protocol: UDP
• Destination: 239.255.255.250
• Port: 1900
• Filter: ExpressVPN WFP Tool - block all outbound IPv4

I understand that a SimpleWall allow rule cannot necessarily override a terminating block installed by another WFP provider.

The suspected SimpleWall bug is therefore not simply that the packet remains blocked.

The apparent bugs are:

1. Notifications are sometimes not displayed when the block occurs.
2. Notifications sometimes appear much later after another event triggers the notification system.
3. The same application/filter combination can be prompted repeatedly.
4. Pressing Allow presents the decision as actionable even when the displayed block belongs to another WFP provider and cannot be overridden by SimpleWall.
5. The notification state appears to become stuck or desynchronized after a burst of WFP events.

Steps to reproduce

1. Install or update SimpleWall to version 3.9 while preserving an existing profile.
2. Enable SimpleWall filtering and network notifications.
3. Install and connect ExpressVPN with its WFP-based Network Lock enabled.
4. Allow an application such as Spotify, ChatGPT, Granola, or Wispr Flow in SimpleWall.
5. Confirm that the application initially has network access.
6. Cause ExpressVPN to reconnect, temporarily lose its tunnel, or reapply its WFP filters.
7. Trigger network activity in the allowed application.
8. Observe that the application may fail without a SimpleWall notification.
9. Generate additional network activity or start a WFP diagnostic capture.
10. Observe that notifications may suddenly appear.
11. Press Allow on the notification.
12. Observe that the same or similar notification can be shown again.

Expected behavior

• A block notification should be displayed promptly when the event occurs.
• Notifications should not remain internally queued until an unrelated event occurs.
• A previously recorded SimpleWall decision should not be requested repeatedly for the same executable and rule context.
• When the blocking filter belongs to another WFP provider, the UI should clearly state that SimpleWall cannot override the block.
• The Allow and Block buttons should either be disabled for an external provider block or clearly explain what the decision will and will not change.
• Large bursts of WFP events should not stall or suppress the notification system.

Actual behavior

• Applications lose network access intermittently.
• Some failures occur without any notification.
• Notifications sometimes begin appearing only after a later or unrelated trigger.
• The same applications can be prompted repeatedly even though they are already allowed.
• Clicking Allow does not stop notifications associated with the ExpressVPN catch-all WFP filter.
• The resulting state is confusing because the application is shown as allowed in SimpleWall while its traffic is still denied.
• Connectivity may return when ExpressVPN reapplies its filters or completes reconnection, making the issue appear random.

User-visible application errors

Observed errors included:

• ChatGPT desktop: net::ERR_NETWORK_ACCESS_DENIED
• Codex CLI: Winsock error 10013 / socket access prohibited by access permissions
• Granola: transcription requests failing or not reconnecting
• Wispr Flow: transcription failing
• Spotify: repeated outbound notification for UDP multicast traffic

WFP observations

During earlier captures, Windows Security events showed repeated blocks involving:

• svchost.exe
• Spotify
• Chrome
• ExpressVPN services
• Tailscale

Observed runtime filter IDs included:

• 46882098
• 46895951
• 46895946

One filter inventory associated 46882098 with SimpleWall's internal block rule:

Internal\BlockConnection

Other blocked events coincided with ExpressVPN DNS and outbound blocking behavior.

A representative capture contained:

• 51 blocked svchost.exe events associated with filter RTID 46895951
• 20 blocked svchost.exe events associated with filter RTID 46882098
• additional blocks for Spotify, Chrome, ExpressVPN services, and Tailscale

Regression information

This behavior began after updating to SimpleWall 3.9.

The previous installation had been used together with ExpressVPN for a long period without this notification loop or the same pattern of missing notifications.

I am downgrading to SimpleWall 3.8.7 for an A/B comparison and can update this report with the result.

Working hypothesis

This may be a regression in one or more of the following areas introduced in 3.9:

• WFP network-event subscription or resubscription
• notification queue processing
• notification deduplication
• handling bursts of WFP drop events
• handling events whose terminating filter belongs to another WFP provider
• state synchronization after another provider dynamically removes and recreates filters
• persistence of Allow/Block decisions when the visible event originates from an external provider

ExpressVPN dynamically recreates its WFP filters as the VPN changes between connecting, connected, reconnecting, and disconnected states.

It may be useful to test SimpleWall 3.9 with a second WFP provider that repeatedly removes and recreates terminating outbound filters.

Suggested improvements

1. Include the WFP provider name and provider GUID prominently in the notification.
2. Identify whether the terminating filter is owned by SimpleWall or another provider.
3. Mark external-provider blocks as informational rather than presenting Allow as a guaranteed override.
4. Deduplicate repeated events using the provider/filter identity in addition to the executable path.
5. Ensure the notification queue cannot stall during a large burst of WFP events.
6. Add a debug log entry for:
   • event received
   • notification queued
   • notification suppressed or deduplicated
   • notification displayed
   • user decision applied
7. Provide a way to export the exact event and filter metadata directly from the notification.

Attachments

I can provide:

• screenshot showing the ExpressVPN WFP filter in the SimpleWall notification
• WFP filter inventory
• Windows Security 5152/5157 event exports
• process-path inventory
• SimpleWall profile after removing private information
• comparison results between SimpleWall 3.9 and 3.8.7