[Mystery solved?] Processes excluded from ProBalance, but still changed

[Scott]

I'm now running 3.27 beta 6 (on WinXP SP3).  I reported this same issue quite awhile ago, but the post has been removed.

Some processes I've excluded from ProBalance have their priority altered anyway.  The latest example is foobar2000.exe.  This process is repeatedly set to priority class 6 even though it is supposed to be excluded.

I'm not sure what other info to provide.

[Jeremy Collake]

Thanks.

As I've mentioned before, this could occur if the core engine is getting out of sync with the GUI, or perhaps even utilizing a different INI file than the GUI. Towards this end, I'll add a new log message to beta 7 that indicates what INI file the governor is using. That way, we can determine if that's the problem or not.

I am considering opening up the source code to the world. I'm very proud of the quality of Process Lasso, and I'd like to show it off. This would help bolster confidence in it. Then people can see for themselves what is going on within Process Lasso. The core engine in particular is so sweet and elegant.

[Scott]

When I run the GUI and look at the settings, they're all in place.  For example, if I check the list of OOC exclusions, foobar2000.exe is there.  Or if I right click foobar2000.exe in the PL GUI, the context menu settings shows that it's excluded as well.

I feel bad reporting problems, but this is not something I'm imagining or making up.  I may start making videos of these things happening just to help prove as much...

[Scott]

I wasn't paying enough attention.  There's the INI used by the GUI, and (potentially) the INI used by the engine.  I get it.  Sorry.

[Scott]

I THINK I finally may know what's going on with this!  If I'm right, it probably explains both (1) my complaints about processes whose priority is (apparently) changed even when excluded; and (2) processes whose priority is (again, apparently) changed to "below normal", and never changed back.

Warning: You may want to punch me in the nuts after reading this.

You know how child processes inherit priority class from their parent?  I think what happens sometimes is that Explorer.exe has its priority lowered, and while running at priority class 6, is used as the parent for other processes.  Thus, those processes inherit the "below normal" priority, and they stay that way.

I have not fully confirmed this, but I really think that's what is going on.  Just now I booted (insomnia sucks), ran the PL GUI, and noticed that a slew of processes were running at priority class 6.  There were no log entries for them.  But--Hey, what's this?--the log did show that Explorer.exe was reduced in priority during the boot process!

Please don't kill me.  We live only about 240 miles apart so it is feasible if you want to.   

[Jeremy Collake]

Hehe, thanks for the updates man. I'll read them closer later this morning and see what's going on.

I'm sorry about my whining, btw.. some days just seem like they'll never end. The SiteAdvisor problem really has me so upset. McAfee apparently has a policy to ignore false alarm reports, so they can deny they knew about them in court. Ok, that's my theory.. but it seems to be the case, from my own dealings with them, and others who have tried to get them to fix false alarms. They even return postal mail. Enough of that though, I'm not going to let it get to me today.

[Scott]

^ You told me via email.  (Wasn't sure you knew who I was...)

[Jeremy Collake]

Ok, I read your response this time .

Nice discovery! I did some quick tests to confirm that would be the behavior, and it is. That explains so much. I will see what I can do to mitigate the possibility of that happening. Now we know why I couldn't imagine how it could occur.. my imagination didn't cover the case of the root shell process (explorer) passing its temporarily lowered priority class on to its child processes. Thanks!

[Jeremy Collake]

I removed my apology about the identity confusion, but just to consolidate this message. I am sorry about that. Well, I guess I have one friend instead of two .

As for resolution of this problem. What I plan to do is not restrain explorer during the boot process. I could exclude explorer completely, but haven't decided if that's something I want to do or not.

The next beta will fix this. I am so happy to finally know what in the heck was going on. I really would have never guessed that .. of course, it was a difficult leap to make from the bug reports. Sometimes, there is no replacing first hand access to the affected computer.

Thanks!

[Scott]

As for resolution of this problem. What I plan to do is not restrain explorer during the boot process. I could exclude explorer completely, but haven't decided if that's something I want to do or not.

Well the problem I saw most often was with firefox.exe being of a lowered priority.  Assuming that was because of Explorer.exe inheritance, that wasn't happening during boot, it was happening at any given time, while Explorer.exe was being restrained.

I am not sure why it always seemed to be firefox.exe that was "erroneously" set to priority class 6.  My guess is it's because Firefox is what I launch/close more than anything else on my system.

I'm excluding Explorer.exe completely, I can tell you that much!  (Funny thing is, for a long time I had Explorer.exe excluded, and only recently removed that exclusion.)

[Jeremy Collake]

You're quite right, the problem extends beyond boot time.. and actually extends to other processes besides explorer (any process that launches another). This is something I was just considering while reviewing code changes here. I may do a more comprehensive fix for the problem, but will likely end up excluding at least the first instance of explorer per user session. Secondary instances of explorer have a tendency to hang and crash, hence my hesitancy to completely exclude all instances of explorer.. unless I end up having to.

[Scott]

Yeah, I'm surprised it took me this long to realize the problem, since I've known about this sort of thing for the longest time.  This could happen with archivers (e.g. WinRAR), third-party file managers (e.g. Directory Opus), just about anything.  I'm considering setting a default priority for all of my regular processes...

[Scott]

In my opinion, it might be a good idea to totally exclude (by default) services.exe.  This process becomes parent to all the system services, native and third-party.  It could be a problem if a service launched and inherited a 6 or 4 priority class from services.exe.

It looks like services.exe eats a lot of CPU overall, but it seems to do so steadily.  I don't know if it would ever be likely to spike enough to be restrained, but then again that would depend on how PL was configured.

Services.exe also runs at priority class 9 (Normal+) by default, which might prevent PL from changing it (by default).  I'm not sure.

There are other important processes (e.g. winlogon.exe), but I don't know that they parent any processes after PL would have a chance to alter their priority.

Just a thought.

[Jeremy Collake]

You're right, services.exe is actually excluded by default because it has a non-normal priority. I, too, am not certain the scenario you describe would occur, but to be safe I will add services.exe to the list of hard-coded exclusions, which also includes other system processes like winlogon.exe.

I have a big fix for this priority propagation problem coming down the pipe. In the meantime, I've completely excluded explorer.exe from restraint. I plan to go final with this new build soon. With so many changes, I'll likely spend the day testing and reviewing code.

Thanks

[Jeremy Collake]

I've done preliminary testing and code review. There are some lingering minor issues I want to resolve, but nothing that didn't already exist in the last final, v3.26. Therefore, especially due to the important updates to this build, I am going ahead with the final release. I'll likely update it a few times in the days to follow with minor changes and fixes.

Your bug reports have served this project very well. I believe your discovery also explains why some users reported interoperability problems with programs like Picasa. This build should do a lot better for many people .