Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[UNUSABLE] 2.0.6636.29380 severe resource abuse leading to system crash *reproducible* #116

Open
working-name opened this issue Oct 16, 2020 · 8 comments

Comments

@working-name
Copy link

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:

  1. enable WFN, make sure notify.exe can run and is doing well
  2. Open Task Manager
  3. Connect to a VPN server or start software you have not so far, one that is incessant about retrying the connection (think Steam, Epic Games Launcher, or some game)
  4. Observe as 100s of notify.exe processes are started continuously, nothing you can do to kill that, your CPU is at 100% at all times until windows 10 crashes.

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.

@wokhan
Copy link
Owner

wokhan commented Oct 16, 2020

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 🤔).

@hoasis2
Copy link

hoasis2 commented Nov 4, 2020

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!

@working-name
Copy link
Author

@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.

@wokhan
Copy link
Owner

wokhan commented Nov 4, 2020

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
Copy link
Owner

wokhan commented Nov 4, 2020

@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

@wokhan
Copy link
Owner

wokhan commented Nov 14, 2020

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

@working-name
Copy link
Author

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:

  • notifier doesn't pop up when a notification exists. Unless I click it manually, I don't know there's a question - I did however notice there's an exclamation point on the icon
  • if I ignore a notification for a while, it will result in 100% cpu usage (fan ramping up and all). I don't know how long that is, I just come back to a computer that's trying hard to keep cool, and as soon as I handle whatever notification(s), it goes back to normal cpu usage
  • notify.exe crashes sometimes, needs to be restarted

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

@esrat
Copy link

esrat commented Apr 6, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants