Process Lasso Documentation

The Parts of Process Lasso

Process Lasso consists of a core engine and a user interface. The two are separated so that users can completely close the user interface while keeping Process Lasso active, managing processes. The core engine is run as ProcessGovernor.exe, while the user interface is ProcessLasso.exe. Running only the core engine results in memory usage of a mere 1-3MB (typically) and almost no CPU use.

When the user interface, ProcessLasso.exe, is launched it automatically launches an instance of the ProcessGovernor.exe core engine if one isn’t already running for the current user, or as a service. When you close the user interface, you are asked whether you want to keep the core engine running or not.

By default, each user session has their own instance of ProcessLasso.exe and ProcessGovernor.exe. An alternate popular configuration would be to run the governor as a service and the GUI as-necessary.

Component	Filename	Description
Process Lasso Graphical User Interface	ProcessLasso.exe	This the graphical user interface that serves the purposes of configuring the product, manually managing processes, and displaying current activity by Process Lasso in real time. It also provides a graph to view current CPU usage and system responsiveness. This component is optional and does not need to be installed or running for proper operation of Process Lasso’s core engine (Process Governor). For usage documentation, click here.
Process Governor Core Engine	ProcessGovernor.exe	This is the core engine that applies process management rules. This can run by itself for minimal resource consumption.
Configuration File	prolasso.ini	This configuration file holds the process rules and options for Process Lasso. It can actually be named anything, and be placed anywhere, including remote shares. You can change its location using the Process Lasso Management Console, supply command line parameters, or manually editing the registry (HKCU).
Log File	prolasso.log	This log file keeps a record of recent actions. You can disable it to save a little more system resources. Its size is automatically trimmed periodically in accordance with the logging configuration in the INI file. The log can be stored anywhere, including remote shares. You can change its location using the Process Lasso Management Console, supply command line parameters, or manually editing the registry (HKCU).

Main Window

The main window consists of a CPU utilization and system responsiveness graph, a list of running processes, and a list of recent actions (log). The configuration of Process Lasso is made easy to tweak through the menu system. In the main menu you’ll find all the general configuration options. Right-clicking on a process, or multiple processes, shows available operations on those process(es).

 

The Graph

The Process Lasso graph shows a calculation of system responsiveness and overall CPU utilization. The system responsiveness is calculated using a proprietary algorithm that measures the latency in the user interface (windowing) subsystem.

Highlighted portions of the graph indicate that a ProBalance process restraint occurred during that period. This can help you see the impact of Process Lasso on system responsiveness. Note that the highlighted areas of the graph may not be 100% accurate in their timing, but are somewhere very close. As future versions come the accuracy of the highlighted area will improve.

 

Highlighted ProBalance events

During periods when ProBalance takes action to ensure your system repsonsiveness remains high despite a spike in CPU use, the graph will be highlighted. The log can be referenced to see what actions were taken.

New in v4 – Hovering over a highlight even will show you the process(es) adjusted (in priority or CPU affinity) at that time.

CPU history of selected process(es)

With Process Lasso you can see the individual CPU history of process(es) you select in the process list. The CPU utilization history of all processes currently selected (highlighted) in the process list is drawn as a smaller white line on the graph. For example, the user below selected ‘devenv.exe’ and its CPU history was drawn onto the graph as a white line.

 

RAM Load Graph

New in v4 – A new RAM Load graph has been added to the right, even though the RAM load history is indicated on the main graph. This new graph is intended to give you a quick read on the RAM load. You can hide it by simply clicking it, or by using the View menu to toggle its visibility.

 

The All Processes Tab

The Process List shows running processes and allows for easy rule creation. You can right click on any process, or on multiple processes, to get a context menu of available options. Among many other things, the options include setting current priorities and affinities, as well as default priorities and affinities.

 

Single process context menu

The context menu when multiple processes are selected is different than when a single process is selected, since not all operations can be performed on multiple processes.

 

Multiple process context menu

As you can see, with Process Lasso you can select MULTIPLE processes at once and operate on them. Not all functions are available when multiple processes are selected, but most common ones are. This includes process rule creation.

 

Selecting which columns to show

You can select which columns you want visible by right-clicking on the ‘All processes’ tab, right-clicking on the list header, or using the ‘View / Select Process Columns’ menu. In addition, you can resize the columns (at their headers) and change the column ordering by dragging the column headers. These view changes will be remembered by Process Lasso. The same applies for the ‘Active processes’ tab. Note that right-clicking the ‘Active processes’ tab allows for setting process information shown in that column. Information in the ‘Active processes’ tab is more limited than information in the ‘All processes’ tab. However, double clicking on any process in the ‘Active processes’ tab will take you to its entry in hte ‘All processes’ tab.

 

The ‘Rules’ column of the GUI gives a summary of rules that match each process.

Rules

Format: [X][L][_][x][W][g][K][#n][n|d|D][e][p][Mx][R][s][iX][<..<<<<][RHANBI][0-63]

Character(s)	Meaning
X	Excluded from ProBalance
L	CPU Limited (9.3+)
_	Instance Balanced (9.1+)
W	A watchdog rule is set
g	Process induces Performance Mode
K	Keep running (restart if terminates)
#n	Instance count limit of n, e.g. #2 for a limit of 2
n|d|D	Prevents sleep of PC, display, or both, respectively
x	Excluded from foreground boosting
e	IdleSaver is disabled when this process is running
p	Process will cause the PC to enter a particular Power Profile
Mx	Where ‘x’ is the default memory priority set for this process.
R	Default priority class: Real time
H	Default priority class: Highest
A	Default priority class: Above normal
N	Default priority class: Normal
B	Default priority class: Below normal
I	Default priority class: Idle
ih	Default I/O priority class: High
in	Default I/O priority class: Normal
il	Default I/O priority class: Low
ib	Default I/O priority class: Very Low (background)
0-63	Default CPU affinity, i.e. ‘0-2,3,5’ for cores 0,1,2,3,5
<	Hard Throttle level lowest
<<	Hard Throttle level low
<<<	Hard Throttle level moderate
<<<<	Hard Throttle level high

 

The Active Processes Tab

 

Selecting which columns to show

You can select which columns you want visible in the ‘Active Processes’ tab the same way you can in the ‘All Processes’ tab. by right-clicking on the ‘Active processes’ tab or by right-clicking on the list header. In addition, you can resize the columns (at their headers) and change the column ordering by dragging the column headers. These view changes will be remembered by Process Lasso. Double clicking on any process in the ‘Active processes’ tab will take you to its entry in the ‘All processes’ tab, where additional information is available.

The Active Processes tab shows only processes that are actively utilizing the system CPU(s). It displays basic information about them, and a horizontal bar graph to visually depict their active CPU utilization.

Right clicking on one or more of the processes in the ‘Active Processes’ list show the same context menu as found in the ‘All Processes’ tab.
Double clicking on a process in the ‘Active Processes’ list will find the corresponding process in the ‘All Processes’ tab and make it visible.

Screenshot of the ‘Active Processes’ view:

 

Double clicking a process in the active processes view

You can double click a process in the ‘Active processes’ tab to go to that process in the ‘All processes’ tab, where extended information is available.

 

Single process context menu

Right-clicking on a process in the ‘Active Processes’ tab shows the same context menu as in the ‘All processes’ tab. You can perform any available operation on the process.

The context menu when multiple processes are selected is different than when a single process is selected, since not all operations can be performed on multiple processes.

 

Multiple process context menu

Just as in the ‘All processes’ tab, you can select multiple processes and right-click on them to perform an operation on all of them.

 

Keyboard Shortcuts

DEL

Terminate selected processes (forcible)

CTRL+A

Select All processes in current view

Configuration Dialogs

• CPU Limiter
• Instance Balancer
• ProBalance Options
• ProBalance Exclusions
• Default Priorities
• Persistent CPU Affinities
• Auto-Terminate List
• Process Watchdog
• Instance count limits
• Keep running processes
• Gaming processes
• Anti-sleep processes
• Application Power Profiles

CPU Limiter

First, it is important to note that the CPU Limiter is not a magic bullet to reduce CPU utilization without consequence. CPU utilization occurs because an application or service is doing something. If you are able, you should address the cause of the CPU utilization, rather than arbitrarily limiting it. Our ProBalance technology does wonders for system responsiveness during high loads without actually reducing CPU use.

However, in some circumstances, it is desirable to reduce a process’s CPU use to achieve more fair access to system resources. This is common in Remote Desktop Services (RDS) environments, or when non-critical background processes are consuming too large a share of system resources. In those cases, the CPU Limiter is a great option.

The CPU Limiter can dynamically reduce the CPU use of running processes by temporarily constraining their CPU affinity. For instance, on a 4 CPU core system, constraining the CPU affinity by 1 core limits the total possible CPU utilization of that process to 75%.

The user creates rules telling the CPU Limiter which processes to act on, and when. When a process match exceeds a threshold over some period, it is limited for the configured duration. Like other rules in Process Lasso, process matches can include wildcards and user names.

The CPU cores removed from a process’s CPU affinity are selected randomly from the set of its original CPU affinity. Once the act-for duration elapses, the original CPU affinity is restored.

While you could accomplish a similar function with a combination of Watchdog rules, the CPU Limiter is easier to use. Using the Watchdog for the same effect would require two rules, one to constrain the CPU affinity when over threshold, and another to restore the original CPU affinity. Finally, the Watchdog rules are limited to statically defined CPU affinities.

The act-for duration can be set to 0 to indicate an indefinite change to a process’s CPU affinity.

Example Use Case

Let’s say you have an issue with Chrome sometimes consuming all available CPU cycles, and you don’t want to set a static CPU affinity that restricts it from short bursts of 100% utilization. You might create a CPU Limiter rule such as:

chrome.exe, after 15 seconds over 30%, restrict by 2 cores for 30 seconds

If a specific user is problematic, you can append that user name to the process match:

chrome.exe:johnny

Wildcards are also supported in process and user names, such as:

 fire*.exe:user*

If no user is specified, then any user matches.

Instance Balancer

The Instance Balancer allows you to indicate how CPU cores should be assigned to an application with multiple instances. You can evenly spread the instances across the CPU cores, or set a specific CPU core count for each instance. When there are more instances than allotted CPU cores, instances are ‘stacked’ in a round-robin manner. When the instance count of managed applications changes by new process creation or termination, a re-balance occurs.

ProBalance Options

ProBalance Exclusions

Persistent Priority Classes

Persistent CPU Affinities

Auto-Terminate List

The processes listed here will get terminated when they are found to be running. Process Lasso can not (at present) actually prevent them from trying to start up, it just immediately terminates them when it finds them running.

 

Process Watchdog

The process watchdog allows for you to take an action on a process when it exceeds a certain amount of CPU or Memory. You can specify actions of Restart, Terminate, or Change Affinity. You can choose commit size of working set size if using a memory trigger. With both memory and CPU triggers, you can set a time the process must exceed this threshold before action is taken.

 

Instance Count Limits

You can limit the number of instances of a process allowed to be running at the same time (per user session) with this dialog. New instances of processes will be terminated if they match a pattern here and the number of instances is already equal to, or greater than, the instance count limit.

 

Keep Running Processes

You can ensure certain processes are kept running by entering in this dialog. This way, they can restart on crash, or restart if they become unresponsive. You can set this by right-clicking on a process, using the ‘Keep process running’, or by using application menu opion at ‘Options / Configure Keep running processes …’.

 

Performance Mode Processes

You can designate certain proceses to ‘Induce Performance Mode’. This causes Process Lasso to induce the Bitsum Highest Performance power profile and make certain adjustments to ProBalance in an effort to ensure all available CPU cycles go to the game. This mode should ONLY be used for games or other very CPU intensive applications that need every bit of processing power. You designate a performance process by right-clicking on a process and checking the ‘Induce Performance Mode’ menu item, or by using application menu opion at ‘Options / Power / Configure Performance Mode processes …’.

 

Anti-sleep Processes

You can prevent the PC and display from entering a sleep or hibernate state by adding them to the ‘anti-sleep’ list. You can do this by right-clicking on a process, using the ‘When running’ menu, or by using application menu opion at ‘Options / Configure Anti-Sleep processes …’.

 

Persistent Application Power Profiles

You can set certain processes to cause the system to enter the chosen Power Profile each time they are run. When they terminate, the system is returned to the previous power scheme. This lets you boost your PC’s performance automatically when you need it, and save energy when you don’t. You can do this by right-clicking on a process, using the ‘When running’ menu, or by using application menu option at ‘Options / Configure High Performance Power processes …’. Entering this power scheume will disable CPU frequency scaling, giving you maximum performance. It will, however, drain the battery life of laptops, netbooks, and other portable computers faster than typical. When all ‘High Performance’ power mode processes end, the Power Profile is reset back to whatever it originally was.

Main Menu Options

Process Lasso’s extensive menu system allows for configuration tweaks and other operations. The menus available are:

• The application main menu 
  Provides ability to to toggle numerous settings and more. These menu options are described below.
• The process context menu (right-click) 
  This menu lets you set specific options for a process.
• The multi-process context menu (right-click) 
  This menu lets you set specific options for several processes.

Enterprise

Deployment on Servers

Process Lasso works wonders on Windows Servers, including Remote Desktop Services (Terminal Services). It can prevent a single user or process from monopolizing the server’s CPU resources, improve responsiveness, and allow for full control of running processes.

The fact that the core engine (governor) is separate from the GUI makes it easy to install without it being visible to the end user.

For Servers, the distinct Server Edition of Process Lasso, with a 30-day free trial available. See this page for more information.

On RDS / TS

On a RDS / TS we recommend configuring the core engine to run as a system service. This option is available in the first configuration dialog during install, or after install by way of ‘Options / General settings / Reconfigure the way Process Lasso starts’.

You also have the option of allowing each user to have his or her own configuration file and log folder, or have all users share the same ones. This option is presented in the second configuration dialog during install.

On distributed networks

Here you have the option of installing Process Lasso on the workstations and server, or just on the server.  You can share a global log and configuration file with a mapped drive or UNC path if you choose. UNC paths are fine so long as the user has access. In this way a level of centralized management is possible.

Methods of Deployment

During the install process, towards the end a little config wizard pops up that will ask you questions relevant to how Process Lasso and its core engine should start. First, know that the core engine is totally in the background and has no visible presence. The system tray icon is part of the GUI. You have two basic choices:

1. Each user gets their own instance of the silent background core engine when they log in (normal process)
2. A single instance of the core engine manages all user processes (service)

You can choose to use a centralized network configuration and log store, a per-machine store, or a per-user store.

Option 1: Centralized configuration and log

In this mode, all workstation are configured to use the same configuration file and log folder. These can be on network shares, or can be pushed out to workstations through alternate methods.

Option 2: Per-workstation configuration file and log

In this mode, you’d install Process Lasso on each workstation and use a common configuration and log path that every user of the workstation would access.

Option 3: Per-user configuration file and log

In this mode, you’d install Process Lasso on each workstation and let each user have their own configuration and log. This is the default behavior of Process Lasso. If you don’t need or want to make changes to the configuration or modify the log files, this is a good way to run Process Lasso.

Option 4: Some combination of the above, or an alternate method

In the end, you can utilize Process Lasso just about however you want. You could have workstations launch it from a network share, for instance, without ever having to install Process Lasso on those workstations. The prerequisites to running Process Lasso are very few. Older systems (XP before SP2) will require Microsoft’s GDIPLUS.DLL to be installed before the Process Lasso GUI can run. However, the core engine does not require the GDIPLUS library to be present. There are no other pre-requisites. This makes for simplistic portable use or launching from a network path.

Silent Installation

Process Lasso supports silent/unattended installation. For more information, see the command line switches documentation.

More help?

If you have any questions about getting Process Lasso up and running in your enterprise, please contact us. Customized solutions are also available.

Command Line Arguments

Installer Command Line

Switch (defaults in bold)	Description	Examples
/S (case sensitive)	Performs a silent installation. Since no configuration dialogs will be shown during install, you should compliment this switch with others (listed below) to specify how you would like Process Lasso configured.	ProcessLassoSetup.exe /S
/language=[English] English (1033) German (1031 Russian (1049) Polish (1045) Italian (1040) Serbian (3098) Japanese (1041) Dutch (1043) TradChinese (1028) SimpChinese (2052) ..(others)..	This indicates the language to use. If this value is not supplied, it defaults to English. Do not try to use unsupported languages, and be sure your language name is spelled as listed here (i.e. SimpChinese). Some languages become unavailable if the translator or regional reseller does not update them, and new languages may be added not listed here. Alternatively, you can specify the language’s code page number.	ProcessLassoSetup.exe /S /language=English ProcessLassoSetup.exe /S /language=1033  ProcessLassoSetup.exe /S /language=German ProcessLassoSetup.exe /S /language=1031  ProcessLassoSetup.exe /S /language=Serbian  ProcessLassoSetup.exe /S /language=Italian  ProcessLassoSetup.exe /S /language=SimpChinese
/key=[numerickey]	This sets the offline activation code, which is NOT the standard activation code. It is a number, given to the user as ‘#12345678’. The can include the ‘#’ prefix character, though this optional on the command line. It is mandatory when using offline activation codes in the GUI. Offline activation keys are granted to Server, Site, and Multi-Site license customers only.	ProcessLassoSetup.exe /S /key=1234567892781
/gui_start_type=[all|current|manual][,uac]	This indicates whether to start the GUI at login for ALL users (all), for only the current user (current), or neither (manual). The current user is the user context in which the installer is running. Add ‘UAC’ anywhere to this parameter to indicate that it should launch the governor with elevated permissions in Vista, Windows 7, Windows Server 2008, and above.	ProcessLassoSetup.exe /S /gui_start_type=all  ProcessLassoSetup.exe /S /gui_start_type=current  ProcessLassoSetup.exe /S /gui_start_type=manual  ProcessLassoSetup.exe /S /gui_start_type=all,UAC
/governor_start_type=[all|current|service|manual][,uac]	This indicates whether to start the core engine (processgovernor) at login for ALL users (all), for only the current user (current), as a service, or neither (manual). The current user is the user context in which the installer is running. When /governor_start_type=service, the /username and /password switches can be used as modifiers to indicate in what user context the service should run. If a username and password isn’t supplied, it will run in the system context. Add ‘UAC’ anywhere to this parameter to indicate that it should launch the governor with elevated permissions in Vista, Windows 7, Windows Server 2008, and above.	ProcessLassoSetup.exe /S /governor_start_type=all  ProcessLassoSetup.exe /S /governor_start_type=current  ProcessLassoSetup.exe /S /governor_start_type=service  ProcessLassoSetup.exe /S /governor_start_type=service /username=myuser /password=mypass  ProcessLassoSetup.exe /S /governor_start_type=all,UAC /username=myuser /password=mypass
/logfolder=[folder]	This indicates to use a global log folder for ALL users on the system. By default, each user has his or her own log folder in their respective application data directory. However, it is sometimes desirable to consolidate all log events into a single log folder. Be sure that this log folder is writable by all users on the system. When using a user-defined config and log path, we recommend storing the config in a sub-folder, e.g. “C:\ProcessLasso\Config” and the logs in another sub-folder “C:\ProcessLasso\Logs”. This is now the default for users who don’t specify a static path for either (except it uses %appdata% of course). The reason we suggest this is because, otherwise, every time the log is written to, it will trigger a file system change notification event on that folder and cause the configuration file to be checked to see if it changed. It won’t be reloaded, so not much overhead, but a little. The granularity of file system change notifications in Windows is limited to folders, thus putting the config in it’s own folder makes sure that only writes to it cause a change notification event.	ProcessLassoSetup.exe /S /logfolder=c:\systemlogs  ProcessLassoSetup.exe /S /logfolder=c:\systemlogs
/configfolder=[folder]	This indicates to use a global configuration folder for ALL users on the system. By default, each user has his or her own configuration in their respective application data directory. However,it is sometimes desirable to use the same configuration for all users, and is required when the governor is run as a service. Be sure that this configuration folder is at least readable by all users, and writable by those who you wish to allow configuration changes. When using a user-defined config and log path, we recommend storing the config in a sub-folder, e.g. “C:\ProcessLasso\Config” and the logs in another sub-folder “C:\ProcessLasso\Logs”. This is now the default for users who don’t specify a static path for either (except it uses %appdata% of course). The reason we suggest this is because, otherwise, every time the log is written to, it will trigger a file system change notification event on that folder and cause the configuration file to be checked to see if it changed. It won’t be reloaded, so not much overhead, but a little. The granularity of file system change notifications in Windows is limited to folders, thus putting the config in it’s own folder makes sure that only writes to it cause a change notification event.	ProcessLassoSetup.exe /S /configfolder=c:\pl_config  ProcessLassoSetup.exe /S /configfolder=c:\pl_config
/launch_gui=[true|false]	This indicates whether or not to launch the GUI after installation. Even when the GUI is launched, it remains minimized to the system tray.	ProcessLassoSetup.exe /S /launch_gui=true
/importconfigfrom=[path]	This indicates to import the configuration from the file you’ve specified. This should be used in conjunction with /configfolder. The file you specify here will be the initial configuration for Process Lasso. You can specify only a folder OR a specific filename here. If you specify only a folder, “prolasso.ini” will simply be appended to the path name.	ProcessLassoSetup.exe /S /configfolder=c:\pl_config /importconfigfrom=c:\temp  ProcessLassoSetup.exe /S /configfolder=c:\pl_config /importconfigfrom=c:\temp\my_default_config.ini
/username=[user] /password=[pass]	When running the core engine as a service (/governor_start_type=service), these switches can be used to indicate under which user you should start the service. The user MUST have permission to ‘logon as a service’ (see our FAQ for info on allowing that). If a specific user is not supplied, the core engine will run in the system context. Please remember that the Windows user password is case sensitive.	ProcessLassoSetup.exe /S /governor_start_type=service /username=myuser /password=mypass
/configpw=[password]	This sets the configuration password. This password is required for by the GUI when a user tries to make a change to the configuration file. Use this parameter without a value to remove any existing password.	ProcessLassoSetup.exe /S /configpw=somepassword

 

Other Documentation Pages