Known errata and quirks

[RDMTECH]

Known errata and quirks:

    * Service mode and foreground detection: Foreground process detection will fail if service running in system user context. Users running the core engine as a system service should exclude commonly used applications from ProBalance restraint.
    * Service mode and balloon tips: System tray balloon tip notifications from Process Lasso will not work when running the core engine as a service
    * Highest rights, Vista UAC, and Windows Defender: When run with highest rights in Vista /w UAC, Windows Defender will block execution of Process Lasso at startup
    * Installer Language Selection and Vista UAC: The NSIS installer may ask you to select your language more than once in Vista /w UAC.

Could you please elaborate this point?  I'm using PL as a service and I depend on it to manage commonly used applications.

I'm still seeing PL errors in the event log, but I'm getting ready to upgrade the version 3.46.  Did you make any changes that would possibly fix this issue?

Thanks.

[Jeremy Collake]

Known errata and quirks:
    * Service mode and foreground detection: Foreground process detection will fail if service running in system user context. Users running the core engine as a system service should exclude commonly used applications from ProBalance restraint.

Could you please elaborate this point?  I'm using PL as a service and I depend on it to manage commonly used applications.

Yes, I am happy to elaborate on that. I don't believe it should be a matter of concern, as a lack of foreground exclusion shouldn't cause any adverse effects. In fact, I'm still debating whether I should, by default, exclude foreground processes from restraint or not. When restraint occurs on a foreground process, it doesn't hurt anything. On the other hand, when a foreground process is excluded from restraint, it may appear to the user that Process Lasso isn't working at all.

In the case of a ProBalance restraint on a foreground process, any other active processes would have also been lowered in priority, keeping the relative priority between the processes constant. With the standard Windows priority boost and longer time slice allocation to foreground threads, the foreground process will still perform just fine. The 'problem' is therefore only that this may decrease the effectiveness of ProBalance on occasions.

I'm still seeing PL errors in the event log, but I'm getting ready to upgrade the version 3.46.  Did you make any changes that would possibly fix this issue?

No, whatever has caused this, I don't think I've fixed it yet ;(

[Jeremy Collake]

I am adding a new warning about running the core engine as a service, regarding the foreground detection problem. Note that this really doesn't apply to servers that don't have user desktop sessions.

I would actually prefer that most people run the core engine as a normal process (the default). Each logged in user will have their own instance of the governor, and they can all share the same configuration and log if desired. This was the original design of Process Lasso, and everything works well in this mode.

As I said before, nothing catastrophic is going to happen when running the core engine as a service, but the effectiveness of ProBalance may be decreased in some situations due to the foreground detection problem. The core engine doesn't know which application is the foreground of an active user session, therefore some optimizations are negated.

When running the core engine as a service, I now recommend excluding commonly used foreground applications from restraint, decreasing the sensitivity of ProBalance, or disabling ProBalance. This, again, isn't mandatory.. but is preferred.

I doubt any users would actually notice any negative performance impacts, or that there would be many real-world negative performance impacts -- BUT, it could happen.

I don't mean to sound alarmist, as this really isn't a huge issue. All other features, except foreground boosting, should work fine.

I do have a planned solution. I am working on its implementation immediately.

Note to other users: This only applies to the Pro version of Process Lasso when running the core engine as a service (not the default config). If you used default settings during your install, you are not affected.

[RDMTECH]

I don't exclude foreground processes on the terminal servers that use PL.  So I'm assuming this warning doesn't apply to this scenario.

[Jeremy Collake]

I don't exclude foreground processes on the terminal servers that use PL.  So I'm assuming this warning doesn't apply to this scenario.

Right, the quirk has absolutely no impact in that scenario.

I really need to quit 'freaking out' about such issues. I just am very dedicated to ensuring that Process Lasso delivers exactly what it claims to, and that users are satisfied.

The warning I now added probably makes people scared to use the service support, and it actually is a little designed to scare home users away from that feature. Unless there is a need to run the core engine as a service, I want people to run it as a normal process.

[RDMTECH]

PL is your baby.  You don't want anything wrong with it.  We completely understand.