WFN Notifier.exe Death Battles slow Windows

[a-raccoon]

This program is great! However, unlike the other Windows Firewall Control'er (binisoft) out there, this one uses Windows Task Scheduler to spawn new processes for every connection that doesn't match a known firewall rule. This means certain programs that really hammer to establish a connection can cause WFN to spawn dozens and hundreds of Notifier.exe processes. I can visually tell when this is happening, because my mouse will continually flicker to hourglass in any program I happen to be using.

Would it be possible to continue using the Task Scheduler, but instead have it trigger an event to a singular always-running user process or system service rather than spawning new processes for each event? DDE or other system messaging the permanent process can hook? The rapid fire opening of new Notifier.exe processes 20 times per second is quite daunting to deal with.

This seems to like to happen when attempting to create a temporary rule, which may be a separate bug. I believe it last happened to me with Google Updater.

Edit: At times, it also seems to just spawn a new Notifier.exe once per second for a program that already has a firewall rule. I'm not sure why.

EditEdit: Changing my Mouse Properties > Pointers > Working in Background cursor to the regular pointer helps assuage some frustrations.

[SyrianBallaS]

I honestly had the same problem here's what worked for me.
In settings of the task in Task Scheduler put "Queue a new instance" (Which I think should be the default if it's going to keep on forking/spawning processes). If that's still giving you trouble, pick "Do not start a new instance".

[AtlasHackert]

@SyrianBallaS: That is an interesting setting to change! Not sure how it'll impact performance in normal situations though...

[BADJAG]

I can confirm that changing the setting to "QUEUE A NEW INSTANCE" makes a huge difference in being able to handle multiple alerts.

I was recently messing around with Windows Firewall and decided to restore the default settings to start from scratch. I disabled the network connection, then turned off WFN notifications from its SETTINGS menu, and reset the firewall. Then I enabled WFN again. As soon as I enabled the network connection, the system was brought to its knees by tens of parallel NOTIFIER.EXE processes. Using an Intel Atom based notebook with only 2 GB RAM made it a lot worse, I guess. I had to disable the network connection again in order to make the system responsive again.

So I repeated the process, but before enabling the network connection, I set the task to "QUEUE A NEW INSTANCE". When I enabled the connection this time, the CPU usage shot up to 100% again, but the system was still quite responsive, and I was easily able to allow or block whatever connections I wanted with no trouble at all.

In short, I'm adding a +1 to the suggestion to change the default settings for the task to queue a new instance instead of running alerts in parallel.

[0xorial]

tens of parallel NOTIFIER.EXE

I've just had tens of thousands of those spawned. In my case it had something to do 1password - after I added a rule for it it was fixed. But that was really annoying because I had to power-off my system for a few times and disable WFN very quickly after startup because otherwise whole OS was completely stuck.

[wokhan]

Parallel alerts was by design as the Notifier was supposed to add them to its internal list (keeping a single instance). If you queue the corresponding tasks, it defeats this purpose.
Anyway this issue can be closed since next release won't have this problem: the launching logic is being rewritten and this will be taken care of, if not already.