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

[Bug] WFN is hoarding CPU cores in certain situations #138

Open
esrat opened this issue Apr 6, 2021 · 1 comment
Open

[Bug] WFN is hoarding CPU cores in certain situations #138

esrat opened this issue Apr 6, 2021 · 1 comment

Comments

@esrat
Copy link

esrat commented Apr 6, 2021

Hi,
at least the latest nightly build 20210105 is consuming huge amounts of CPU power in certain situations!
My system (Windows 7 Professional) is pretty much done concerning the firewall configuration. Only some unnecessary system services are poping-up a message here and there, because they can’t be blocked cleanly. So, WFN should not have much to do.
But sometimes, when there are some events to show within the Notifier-window, the Notifier.exe does consume huge amounts of processing power, e.g. it collected 23 CPU hours within a much smaller runtime. Maybe this has something to do with the service detection? At least it was only happening when some service-connection was blocked. Maybe it is due to the VPN connection I have to use a lot? (It remaps all IP address spaces for new connections, even local address spaces. This can't be changed.)
I saw this several times. It always used 6 or 7 CPU cores to the fullest (and several kWh of energy until I realised the permanent utilisation of my quite silent PC).
I switched back to the 2.5 Beta and could not reproduce the problem. After 3.5 d of runtime (but mostly without VPN) and several times looking at and skipping the same events as with the nightly build, it had only accumulated some CPU minutes.

Sadly, I have no verbose log. I just started one when I switched back to the nightly build, some minutes ago.
But is it really logging something? I don't see a single line since I started the process using the Task Planer.

The old log (not verbose; when I tried the current nightly build the first time) does only show "errors" like this:

2021-03-31 01:37:55,156 ERROR [  1] - Unable to determine GeoLocation from IP address. Using default location.
System.Exception: Cannot retrieve connection location for public ip - connection may be blocked by the firewall. 
You may need to create a rule for WFN in the Notifier to unblock it.
   at Wokhan.WindowsFirewallNotifier.Console.ViewModels.GeoConnection2.get_CurrentCoordinates() in D:\a\WFN\WFN\Console\ViewModels\GeoConnection2.cs:line 43
   at Wokhan.WindowsFirewallNotifier.Console.UI.Controls.Map.Map_Loaded(Object sender, RoutedEventArgs e) in D:\a\WFN\WFN\Console\UI\Controls\Map.xaml.cs:line 113

In my opinion this is no error (#130). The rest of the log is just filled with lots of warnings:

[...]
2021-03-31 02:08:26,343 WARN  [ 33] - Unknown protocol type: 0
2021-03-31 02:08:26,366 WARN  [ 11] - Unknown protocol type: 0
2021-03-31 02:08:26,368 WARN  [ 18] - Unknown protocol type: 0
[...]

I don't think these are related to the CPU issue which only occures when the Notifier is showing some captured events.

Another hint, maybe unrelated:
Until now, I only saw this bug when I had the security log open (even if the WFN.exe is not producing the problem).

@esrat
Copy link
Author

esrat commented Apr 7, 2021

I really was able to reproduce the problem again. Right now, I'm looking at a process with more than 124.5 CPU hours, started only 1.5 d ago. It was using 6 full CPU cores, just until I skipped the captures events.
This time I had no additional WFN.exe running.
Sadly, the WFN.log hasn't changed a bit, despite the verbose logging setting!

Does the logging work as expected within the current nightly build and in portable mode?

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

1 participant