This project has moved. For the latest updates, please go here.

Any updates

Editor
Feb 21, 2016 at 8:37 PM
As I last recall, WFN got some new developers a few months ago. I am curious to know if anyone has made any progress in updating 2.0 so it works properly? Windows 10 still doesn't have notifications for outbound rules, so I think continuing this project would be good.
Developer
Feb 22, 2016 at 5:59 PM
I've already committed a small bugfix, but I'm sorta waiting until NotDifficult uploads his/her logging fixes... I don't want to trample all over his/her work before it's in the code repository. Do you have a way to contact NotDifficult?

Also, I'm currently in the process of setting up a Windows 10 machine specifically for fixing WFN on Win10, and I no doubt will be looking into the Skype-doesn't-play-nice issue.

That said, I don't even know the procedure to release a new version, or if I even can do that...
Editor
Feb 23, 2016 at 5:22 PM
No, I do not know who NotDifficult is. I haven't seen anyone here on the forums by that name, though.

Is there anything I could provide for you? I do run a Windows 10 Pro 64-bit system, as well.

What bug fixes have you fixed so far?
Developer
Feb 23, 2016 at 5:34 PM
NotDifficult claimed to have some fixes for the logging, but I just fixed the main issue with it myself. :)

Here's a list of the biggest bugs I've fixed so far:
  • The access violation crash that caused WFN.exe to die when started.
  • A race condition with the log file that caused Notifier.exe to crash when started multiple times.
  • A crash if coordinates couldn't be retrieved on the Map view.
I'm currently working towards making a new release, so that people can re-test if this indeed stabilized WFN.
Editor
Feb 23, 2016 at 5:40 PM
Edited Feb 23, 2016 at 5:43 PM
What about the spam of notifer.exe processes within task manager that causes severe system lag and instability? That was the main issue I had with WFN 2.0.

I think Codeplex works similar to GitHub. Any code changes done to the sourcecode needs to be approved by the led developer first before being processed.
Developer
Feb 23, 2016 at 5:45 PM
ROCKNROLLKID wrote:
What about the spam of notifer.exe processes within task manager that causes severe system lag and instability? That was the main issue I had with WFN 2.0.
I've already once accidentally nuked my PC as well. :P
Even though that was before several of the fixes (that should help fix this), I can't guarentee that's all gone now. I have to look into the code a bit deeper to see exactly what's triggering this bad behavior, and how to stop it once and for all.
One cause is that the Windows Crash Reporter accesses the internet, causing a new Notifier.exe to pop up. So if the Notifier.exe crashes all the time, you end up in an infinite loop. One of the causes for this I just corrected with the log file fix, so I think this that at least significantly reduces the chances of this happening.

ROCKNROLLKID wrote:
I think Codeplex works similar to GitHub. Any code changes done to the sourcecode needs to be approved by the led developer first before being processed.
Actually, my code changes are already visible in the source code viewer, so I guess that isn't set-up for this project?
Editor
Feb 23, 2016 at 6:06 PM
Interesting. What if you made a temporary workaround that causes wfn to auto-terminate after a certain number of processes start (like 10 or something)? At least we won't have to worry about the instability and still be able to test it somewhat.

What about some of the bugs that was reported in this topic: https://wfn.codeplex.com/discussions/639980

More specifically, I was having an issue with the "block and prompt" option and when I selected that, wfn would report back with "Unhandled exception has occured in a component in your application. If you continue, the application will ignore this error and attempt to continue. Access to path C:\program Files\Windows Firewall Notifier\Wokhan.WindowsFirewallNotifier.common.log is denied" If I click continue, WFN will crash with an error message that says "The exception unknown software exception (oxe0434352) occured in the application at location 0xfd03b3dd".
Developer
Feb 23, 2016 at 6:35 PM
Yes, I was already thinking about adding such a workaround as a safety measure myself. :)

ROCKNROLLKID wrote:
Access to path C:\program Files\Windows Firewall Notifier\Wokhan.WindowsFirewallNotifier.common.log is denied"
I see, but that's one of the bugs I fixed! So this shouldn't happen anymore in the next release! :D
Editor
Feb 23, 2016 at 6:44 PM
Excellent. Well I can't wait for the next release. Would be nice to get this back up and running in my system.
Developer
Feb 25, 2016 at 5:09 PM
I just released v2.0 Alpha 5! :)

Can you please check it out, and let me know if it's more stable or not?
Editor
Feb 25, 2016 at 5:31 PM
I am still getting the "Unhandled exception has occured in a component in your application. If you continue, the application will ignore this error and attempt to continue. Access to path C:\program Files\Windows Firewall Notifier\Wokhan.WindowsFirewallNotifier.common.log is denied" bug.

I installed WFN to C:\Program Files\Windows Firewall Notifier. Please note that this is not the x86 folder. This bug seems to only happen when outbound rules are set to "Block and Prompt". After I got that error, it then spammed the notifier.exe processes in task manager again. I assume because it was spamming this error message. I seen that the notifier.exe processes were auto-terminating, but they were spamming faster then they were getting terminated.
Developer
Feb 25, 2016 at 5:39 PM
Can you try putting it outside of Program Files, so in a folder where your normal user has writing rights?
Editor
Feb 25, 2016 at 5:44 PM
Edited Feb 25, 2016 at 5:45 PM
Ok. This time I put WFN on my desktop. I checked "Block and Prompt" and same issue happened.

I am finding that a quick resolve is to switch WFN back to allow, thus it ends the spam of notifier.exe.
Developer
Feb 25, 2016 at 5:56 PM
Ok, I think there's no other option but to put the log-file in the location where Windows wants it. The downside is that this means the log-file won't be automatically deleted when people "uninstall" WFN... :(
Editor
Feb 25, 2016 at 5:59 PM
How about if you made a installer to install WFN to the program files then a uninstaller to delete WFN from that location plus the log files?
Developer
Feb 25, 2016 at 6:13 PM
Yeah, I was hoping I could avoid that, but I guess it's the best solution.

I don't know how to make .msi installers, but I do have experience with NSIS, so I'll start working on that.
Developer
Feb 25, 2016 at 6:34 PM
Actually, I have another thing that we should probably test first. I assume you're using some anti-virus product? It's quite possible that an improperly coded anti-virus suite (and don't think the more expensive suites are exempt!) is interfering with the fast and multi-process way WFN accesses its log-file. Can you try disabling (or even uninstalling) it, and testing WFN again?
Editor
Feb 25, 2016 at 7:22 PM
I use Windows Defender that is built into Windows 10, along with ClamWin, which doesn't have on-access scanning, and Clam Sentinel, which only has limited on-access scanning. I had Sentinel disabled and Windows Defender didn't have any issue with WFN, nor has it in the past.

That does remind me though. Clam Sentinel uses its own made heuristics to scan files. The following files get blocked by Clam Sentinel: WFN.exe, RuleManager.exe, and Wokhan.WindowsFirewallNotifier.Common.dll. Clam Sentinel has a simple heuristic build. You can view the Clam Sentinel's source code to see how the heuristics work. If you put a legit valid digital signature on these files, it might actually prevent Clam Sentinel from blocking these files. This doesn't have to do with the other issue I am having, but it should something to consider in the future, and I am sure Clam Sentinel isn't the only one that is like this.
Developer
Mar 3, 2016 at 3:48 PM
Edited Mar 3, 2016 at 3:48 PM
I get this too. I attached a log to issue 5168

I've also had some suspicious low memory app kills which I'm assuming are related to Notifier.exe - I look for open apps when something dies and there are number of Notifier.exe and WerFault.exe. Is there anyway to completely disable WerFault.exe for this executable? I stumbled across https://blogs.msdn.microsoft.com/oldnewthing/20160204-00/?p=92972 ... not sure if that applies
Editor
Apr 29, 2016 at 12:40 AM
I hate to keep asking and nagging, but any updates/news on if you can fix the Access denied and notifier.exe bugs?
Developer
May 25, 2016 at 7:34 AM
I'm working on a workaround right now. The issue is that, as far as I can see, the problem isn't with WFN but with other programs interfering with WFN's logging.
Developer
Sep 3, 2016 at 4:34 PM
I have finally managed to get a full fix in place. Can you all please re-test with the new V2.0 alpha 8, and let me know if that indeed fixes the problem?
Editor
Sep 3, 2016 at 7:46 PM
It seems to be ~80% fixed. I monitored Task Manager behavior over time with "Block and Prompt" enabled for outbound connections. I still see, at times, a spam of Wokhan.WindowsFirewall.notifier processes that usually pops up multiple times, but they do not spike cpu up to 100% anymore and they seem to go away quickly. It also doesn't happen 24/7 anymore, but it does happen once in a while.

The "Unhandled exception has occured in a component in your application. If you continue, the application will ignore this error and attempt to continue. Access to path C:\program Files\Windows Firewall Notifier\Wokhan.WindowsFirewallNotifier.common.log is denied" error still happens, but I seem to be able to use WFN just fine if I just ignore it, so I assume it is now just a harmless error, maybe?

WFN doesn't seem to show a notification with my network, so it just blocks it from me and I have to manually enable it.

Also, the "security log" section takes a long time to load every time you try to access that section, despite the fact if there is anything there to show or not.

Lastly, the test notification is bugged. It pops up with a demo mode notification, but every time I try to allow or block it just says "The corresponding rule has not been created".
Editor
Sep 3, 2016 at 7:55 PM
Ok, so I tested it outside of the program files directory (specifically on my desktop) and I am not getting the access violation issue anymore and notifications seem to be working well (it detected my network now). So I guess this just an issue with it being in the Program Files?
Developer
Sep 3, 2016 at 8:27 PM
Unfortunately, this is a limitation at the moment, yes. WFN needs to be able to write to its directory, and as non-admin you don't have those rights, causing that error and the other trouble you've noted.
Editor
Sep 3, 2016 at 9:06 PM
Thanks for fixing this Daniel. Wokhan will be proud that you have fixed this long-term issue. I think it is OK to take it out of Alpha and move it into beta stage (unless you have some new features to add still). Actually Wokhan was originally going to move it to beta after alpha 4, but I assume it was better to leave it until the notificer.exe spam was solved, which is it for me now.
Developer
Sep 3, 2016 at 9:23 PM
ROCKNROLLKID wrote:
Thanks for fixing this Daniel.
No problem! Glad I could help. :)

ROCKNROLLKID wrote:
I think it is OK to take it out of Alpha and move it into beta stage (unless you have some new features to add still).
I was thinking about doing that too. There's a couple of things that I feel need correcting before I feel confident enough to declare this "beta"-ready, so there might be one more alpha before that happens. The window that pops up when multiple services are detected is brain-dead ("OK" literally does nothing; its code is simply not written). There appear to be a few GUI inconsistencies in the notifier, and creating rules doesn't always seem to succeed the first (few) times. Calling it a "beta" will probably attract some new users, and if those things aren't fixed they might get disappointed and move on.

But I think the core functionality is now quite stable, and we (I ;) ) can finally move on to finishing all the functionality.
Editor
Sep 3, 2016 at 9:40 PM
ROCKNROLLKID wrote:
Lastly, the test notification is bugged. It pops up with a demo mode notification, but every time I try to allow or block it just says "The corresponding rule has not been created".
Oh, by the way, now that I have it on desktop, now every time I press "Click here to test", it just pops up with a error message saying "Failed to write to log file". Don't know if that is one of the GUI issues you mentioned.
Developer
Sep 5, 2016 at 3:26 PM
Edited Sep 5, 2016 at 3:27 PM
That's the message I put in as the final fix for the logging problems. The message is harmless (except that obviously there will be entries missing in the log). I seriously suspect third-party programs (anti-virus, but maybe also explorer.exe) interfering with the log-file, so I don't think it can ever be reliably fixed, but at least WFN and your computer don't die a fiery death anymore. :P