WFN icon indicating copy to clipboard operation
WFN copied to clipboard

[Bug] WFN is hoarding CPU cores in certain situations

Open esrat opened this issue 3 years ago • 1 comments

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 avatar Apr 06 '21 11:04 esrat

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?

esrat avatar Apr 07 '21 22:04 esrat