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

100s of duplicate processes

description

in WFN 2.0.6280.24566

file attachments

comments

DanielPharos wrote Mar 15 at 6:22 PM

This happens when Notifier crashes, but then you'd also see a lot of wer*.exe's. The only other case I'm aware of is when a program tries to open hundreds of connections, even though they're being blocked. Try to figure out what program is doing that, and create an allow or block rule for it manually.

rotorb wrote Mar 15 at 7:59 PM

Thanks for the fast response! It appears to be "C:\Program Files (x86)\TeamViewer\TeamViewer.exe"

I looked through every tab and can't find any way to create an allow rule manually. I also couldn't find any documentation online. Than

DanielPharos wrote Mar 16 at 5:59 PM

topher217 wrote Mar 30 at 9:29 AM

First off thank you for this software. Its a really useful tool!

I wanted to chime in and note that I also experienced this same situation a few times with the recent update and one time it even caused my system to crash. Its also very difficult to escape this situation once it starts to snowball; I am unable to stop all the processes manually within the Task Manager before my memory fills up and the system crashes.

Is there a way to contain all requests within a single process for future developments or does that seem impossible for some reason? Maybe a temporary fix would be to add a max limit of 20 processes or something , generate a message box warning of the situation, at which point block all connections until the issue is resolved. This would at least keep the system from crashing and allow the user to close all processes and make the manual firewall entry prior to the memory leak snowballing.

Let me know if you need any further details.

gscaglia wrote May 24 at 1:19 PM

I second topher217 suggestion.

The notification process could simply, as soon as it starts, count how many instances of itself are already open and exit immediately if there are more than a given limit.

As it is now, WFN notifications become quite literally a fork bomb in the system if any application retries the connection after it is denied. Mind you, that's not uncommon or wrong per se, so it's not on those applications to change that; If any applications are wrong those are the ones that silently give up after being denied once.

wrote May 24 at 1:20 PM

DanielPharos wrote May 24 at 3:22 PM

As it is now, WFN notifications become quite literally a fork bomb in the system if any application retries the connection after it is denied.
True, but adding a check will only make the situation slightly less worse; it won't fix it. The entire .NET framework still has to load, and I suspect that's the heaviest bit, not what WFN does. But I agree, it certainly is worth a try!
Mind you, that's not uncommon or wrong per se, so it's not on those applications to change that;
I would argue that if, after a thousand connection attempts failed, the application tries again, it's the application doing something bad. Even the TCP-protocol itself gives up after 3 tries, which is generally seen as the industry best-practice. After three consecutive failed attempts one can quite reasonably assume further attempts are futile. Trying until either it work on attempt <insert large number here> or until something breaks is just bad programming. Not "wrong per se", but still bad.
If any applications are wrong those are the ones that silently give up after being denied once.
Sure, I wholly agree with you there!