Open working-name opened 4 years ago
Hi, thanks for your feedback and for those reproducible steps. This issue will not occur anymore in WFN v2 final as the notification triggering will be based on an always running agent instead of a task triggered one. We're a bit late on our initial schedule, partly for tragic reasons I won't mention again, but an alpha version is available on the releases page (use with caution... but cannot be worse than what you're experiencing here already 🤔).
We're a bit late on our initial schedule, partly for tragic reasons I won't mention again,
I have not noticed any mention before. I hope that everything will turn out well!
@wokhan That sounds awesome. The alpha version doesn't enable the firewall. You flip the switch, click save, and then it's back to off. Unfortunately cannot use it.
Much luck with the tragic reasons.
I have not noticed any mention before. I hope that everything will turn out well!
Said reasons aren't directly related to me, the mention I was talking about is a commit comment (and an additional statement in the about screen of WFN) about a member passing away suddenly a few months ago (Harry). He wasn't around the project for long but motivated me to start working on it again, and the newest version is clearly there thanks to him...
@wokhan That sounds awesome. The alpha version doesn't enable the firewall. You flip the switch, click save, and then it's back to off. Unfortunately cannot use it.
Much luck with the tragic reasons.
Hi @working-name, I'll have a look at this ASAP, might be a stupid regression when tweaking the layout. Thanks for your feedback
I wasn't able to reproduce but anyway the setup process is being tweaked a bit, and I'm also including a "direct feedback log" (which will be improved a lot soon) in the same page to help. Feel free to try again, if you still encounter the same issue, I guess WFN log will be helpful. Thanks
Okay, so I have since swapped hardware and now I'm back to windows 10 with a more stable setup (aka not needing to boot into macOS or linux anymore.
I've also been running 2.5.370.0 on w10 64bit 2004 (19041.804) for quite a while now and noticed a few odd things:
Otherwise its UI looks much better now, and is much more manageable. Unfortunately I didn't enable verbose logging, but I do see quite a few logs in the app folder, from Feb 7 on. Not very useful, it's mostly a lot of the following:
2021-02-09 15:55:15,285 ERROR [ 30] - Cannot parse eventlog entry: eventID=0
System.FormatException: Input string was not in a correct format.
at System.Number.ThrowOverflowOrFormatException(ParsingStatus status, TypeCode type)
at System.Number.ParseUInt32(ReadOnlySpan`1 value, NumberStyles styles, NumberFormatInfo info)
at Wokhan.WindowsFirewallNotifier.Common.UI.ViewModels.LogEntryViewModel.TryCreateFromEventLogEntry[T](EventLogEntry entry, Int32 index, T& view) in D:\a\WFN\WFN\Common\UI\ViewModels\LogEntryViewModel.cs:line 96
Just a hint to the original topic: The process of starting hundredth of Notifiers was also reproducible to me on every PC with Microsoft’s gaming spyware. I think they introduced it with Windows 8. (I just don’t know their name right now, maybe some kind of "manager". I’m speaking of the component which looks for known .exe-files which are about the be started. This event should be sent to Microsoft so that they could do whatever they want with the knowledge who does play which game and when. In fact, it should have been sent sooo urgently that the starting process is blocked completely until there is some answer. The version I did know (Today I’m back at Windows 7 Professional - programs do start just like intended, no phoning home.) was implemented so worse, it even did not wait for any answer, it just hammered new connection attempts into the system until it died of the above described resource loss.
But the solution for WFN was quite easy: Just change the settings for the task which starts the Notifier.exe! You must not start a new instance for every event but queueing the start until the last one was processed (and closed). So, Windows does let only one instance run. And when you are done with the rules for the process with this obtrusive behaviour then you can discard all planned starts of Notifier.exe using the Task Planer.
Using what I believe is beta3, I can reproduce this bug 100% of the time. I initially thought it was just my laptop being weird or some incompatibility with other software on there causing this to happen but I've now been able to reproduce it on my desktop as well.
Steps:
Initially you're able to kill off some notify.exe processes but they get spawned at an incredible rate and it's impossible to keep up. Needless to say the GUI (if any is seen) is not responsive. Nothing you can do to come back from this once it starts.
This will consistently happen on windows 10 build 2004.