Process Lasso is Windows process automation and optimization software. From tuning algorithms like ProBalance to user-created rules and persistent settings such as CPU affinities and priority classes, Process Lasso enables you full control over running applications!
Our famous ProBalance algorithm maintains system responsiveness during high CPU loads. This proprietary algorithm dynamically adjusts the priorities of running programs so that some are given higher priority access to the CPU(s) than others. With ProBalance, no longer will single, or multiple, processes be able to bring your system to a virtual stall. Process Lasso will let you keep interacting with your computer, even when it is under a heavy CPU load. Try our CPUEater Demo to experience ProBalance for yourself.
Process Lasso also allows users to automate and tweak how applications are run through a number of unique and helpful functions. These include persistent priority classes, persistent CPU affinities, disallowed processes, per-process power profiles, a process watchdog for advanced rules, process instance count limits, multiple instance balancing and much more! These features give you the ability to control how programs utilize your computer’s resources based on automatically applied settings. With Process Lasso, you can decide exactly how you want your processes to run.
Many additional functions such as power plan automation, a system responsiveness metric and process activity logging are also available.
For minimal resource use, all algorithms and process rules are enforced by a stand-alone background service called the Process Governor. The GUI is entirely optional.
OS Compatibility
Workstation edition: Windows 7, 8, 10
Server edition: Windows 2008, 2008/2, WHS, 2012, 2012R2, 2016, 2019
For Windows XP, 2003, and Vista see this version. For Windows 2000, go back to this version.
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
Graphical User Interface (GUI)
ProcessLasso.exe
This the graphical user interface that serves the purposes of configuring process rules, manually acting on processes, and displaying recent activity by Process Lasso’s core engine (governor). 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). This GUI is also called the ‘Management Console’.
Core Engine
ProcessGovernor.exe
This is the core engine that applies process rules and algorithms. It is also called the ‘Governor’ or ‘Process Governor’. This can run stand-alone (without the GUI) 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. It can be optionally be disabled. Its size is automatically trimmed. The log can be stored anywhere, including remote shares. The location can be changed using ‘Options / General settings / Reconfigure the way Process Lasso starts’, command line parameters, or by running the Process Lasso installer. This file is not in CSV format, but a CSV log can be emitted along side this one (see log options).
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).
Parked CPU cores shown in grey
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 responsiveness remains high despite a spike in CPU use, the graph will be highlighted. The log can be referenced to see what actions were taken.
Note these colors are now reversed!
Hovering over a highlight event 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.
Instance count limit of n, e.g. #2 for a limit of 2
d|D
Prevents sleep of PC, or PC and display, 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.
Active Processes Tab
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.
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.
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 one 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:
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.
Persistent CPU Priority Classes are available to keep applications running at specific priorities.
Note that use of above-normal priority classes is generally ineffectual at improving performance (it won’t make an app go faster). Instead, it is recommended to target problematic background processes with Below Normal and Idle priority classes to limit their impact on performance sensitive applications. This is what ProBalance does automatically.
Priority classes available in Windows are:
Real-Time
High
Above Normal
Normal
Below Normal
Idle
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 (advanced rules) allows for you to take an action on a process when it exceeds a certain amount of CPU or Memory. You can specify actions such as Restart, Terminate, Log, Execute (external), or Change Affinity. With both memory and CPU triggers, you can set a time the process must exceed this threshold before action is taken.
The Process Watchdog can be found at the menu item ‘Options / Control / Configure Process Watchdog …‘.
There are several actions and trigger types.
Triggers:
CPU
Memory
Actions:
Change CPU Affinity
Execute
Log Occurrence
Restart Process
Set CPU Priority Class
Set I/O Priority Class
Stop Processing Rules
Terminate Process
Trim Virtual Memory
Options:
Divide CPU % thresholds by system CPU count
Divide CPU thresholds by the total logical core count. For example, 3200% could be given, and when divided by 64 cores, would be a threshold of 50% of total CPU use. This allows for more precision on high core count systems.
The user 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
The user 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 option at ‘Options / Configure Keep running processes …’.
NOTE: Processes are always launched unelevated. You can change this behavior by creating a registry value in HKEY_LOCAL_MACHINE\Software\ProcessLasso named “AllowElevatedChildren” with a DWORD type and value of 1 (get .REG file here). By default, this registry key can only be written by elevated administrators. This will still not allow a process to be launched with rights in excess of the governor. Therefore, if the governor is running in a limited user context, any child process will inherit only that context. When the governor is running as a service, launches are prohibited, and the Keep Running function is disabled.
IdleSaver
IdleSaver allows the user to set a power plan for use when the system is Idle. This allows the user to run in a high performance power plan while active, but without completely sacrifice energy savings by switching to a more conservative power plan when the user is idle.
SmartTrim
SmartTrim is an intelligent memory management algorithm that can trim working sets on a per-process basis when thresholds are reached, and can also clear the system standby list (cache).
Performance Mode
The user can designate certain processes to ‘Induce Performance Mode’. This causes Process Lasso to enter a specific power profile, Bitsum Highest Performance by default, when those applications are run. In this way, it is similar to the ‘Application Power Profiles’ feature. However, Performance Mode also makes certain adjustments to ProBalance in an effort to ensure the performance-critical application runs without interference from background processes. Users designate a ‘High Performance’ process by right-clicking on a process and checking the ‘Induce Performance Mode’ menu item, or by using application menu option at ‘Options / Power / Performance Mode / Designate High Performance processes …’.
Induce Performance Mode process context menu item
Users can select an alternate power plan to use with Performance Mode, instead of the default of Bitsum Highest Performance.
Select alternate power plan for Performance Mode
Anti-sleep Processes
The user can prevent the PC and display from entering a sleep or hibernate state by adding them to the ‘anti-sleep’ list. This can be done by right-clicking on a process, using the ‘When running’ menu, or by using application menu option at ‘Options / Configure Anti-Sleep processes …’.
Persistent Application Power Profiles
The user 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 scheme 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.
Processor Group Extender
Process Lasso 9.7 adds the Processor Group Extender. This novel algorithm allows processor group unaware applications to make use of the full CPU. It accomplishes this by monitoring threads of target processes and dynamically assigning threads to supplemental processor groups as required.
Processor groups are only used on systems with more than 64 logical cores. Since Windows CPU affinities are represented as 64-bit bitmasks, processor groups were introduced to extend support to more than 64 logical cores. Thus, a CPU affinity applies to only a single processor group, and each process is assigned a default processor group when it launches. A process’s threads are restricted to that default group unless they are manually assigned to other processor groups. Typically, this thread assignment is done by the application itself. Applications that are able to assign their threads to other processor groups are group aware.
Group unaware applications will therefore be limited to a single processor group, leaving CPU cores in the other group(s) underutilized. Ideally, the application developer would update their software to be group aware, but for cases where that hasn’t happened, Bitsum now has a solution! We call it the Processor Group Extender. It monitors threads of target processes and assigns excess threads to supplemental processor groups.
Note that the Processor Group Extender is only necessary, and should only be used, in situations where an application needs additional CPU cores, but is not processor group aware. Unnecessary or inappropriate use may affect the performance characteristics of an application.
Processor Group Extender
Forced Mode
Forced Mode, available in the Options menu, is a toggle that causes rules to be continuously re-applied to running processes. This can be desirable in the case of a process that changes its own settings. Normally, Process Lasso would make a one-time adjustment to each new instance of a process, but Forced Mode causes it to evaluate whether the target settings (e.g. CPU affinity or priority class) were changed, and re-apply them if so.
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.
Remote Desktop Services
On a Remote Desktop or Terminal Servers 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’.
Users also have the option of allowing each user to have his or her own configuration file and log folder (config specific to user), or have all users share the same one (config specific to machine). This option is presented in the second configuration dialog during install. It is recommended to use a central configuration file, which will be presented as the default when the governor is deployed as a service.
Centralized Network Share for Config/Log
You have the option of installing Process Lasso on the workstations and server, or just on the server. The user can share a global log and configuration file with a mapped drive or UNC path. Remote paths are fine so long as the user has sufficient access. In this way a level of centralized management is possible.
Methods of Deployment
Towards the end of the install process, a set of two dialogs exposes settings relevant to how Process Lasso and its core engine (Governor) should start. In the first dialog, the administrator can choose whether the GUI should start for all users, the current admin user, or not auto-start. The GUI does not need to be running for rules to be enforced by the ‘Governor’, aka ‘the core engine’. The Governor is entirely non-interactive, runs in the background, and has no visible presence. The GUI hosts the system tray icon and main Process Lasso window.
For the Governor, there are two primary choices:
Per-session: Each user session gets an instance of the governor as a normal process. Each instance of the Governor manages the processes in its respective session. If a global configuration and log path is used, they will all share the same configuration. Otherwise, each user will have their own configuration and log.
Single instance: A single instance of the Governor manages all processes on the system.
Normal process – Governor runs as a normal process hosted in an administrative session, managing all processes on the system.
Service – Governor runs as a service, managing all processes on the system (recommended).
In the config and log path presented in the second dialog, you can choose to use a centralized network configuration and log store, a per-machine store, or a per-user store.
Option 1: Centralized config and log
In this mode, all workstation are configured to either (1) use a centralized configuration and log path hosted on a network share OR (2) use a machine local configuration and/or log path, but have a centralized INI configuration file pushed out to clients when changed, and the logs pulled from clients periodically.
If the INI config path is a network share, it is polled for changes at least once a minute. For local paths, file-system change events are used to get notification of changes, so no polling is required and changes will be picked up instantaneously.
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, each user have their own configuration, log, and instance(s) of ProcessLasso.exe and/or ProcessGovernor.exe. 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.
Pushing out configuration changes
When pushing Process Lasso configuration changes out to local machine storage, it is recommended to use a script or other automated means to copy the Process Lasso configuration file to the target machines. As soon as the configuration file is over-written, Process Lasso will adopt it (no app restart necessary).
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, also known as non-interactive or unattended. 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.
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.
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.
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 contexts the governor will be running in. If set to run as a normal process, this may mean all users. If set to run as a service, it should be writable by the service user (or SYSTEM user).
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 readable by all user contexts the governor will be running in, and writable by those who you wish to allow configuration changes.
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.
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.
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.
Command line arguments for the GUI and core engine are available. You can use them to over-ride the configuration and log paths, but this is not normally necessary or recommended. Changes to the configuration and log paths should instead be performed by the installer (preferred) or the InstallHelper application.
Switch
Description
Examples
/Tray
Causes the main window to not be immediately displayed.
ProcessLasso.exe /tray
/ConfigFolder=
Indicates the configuration folder that should be used. It is assumed that ‘prolasso.ini’ will exist in it. If not, it one be created with default values.
Invokes the Out-of-control Process Restraint configuration dialog. This is primarily only used by the installer. Note that this creates a separate instance of Process Lasso that displays the configuration dialog, then exits when the dialog is closed.
ProcessLasso.exe /config
/no_raise_existing
Start a new instance of ProcessLasso.exe only if it is not already running, but do not show the window of existing instance as would be the default behavior.
ProcessLasso.exe /no_raise_existing
/SetActiveProfile=name
Switch to active configuration profile to the indicated preexisting named profile. This command does not launch Process Lasso, it exits after changing the profile.
ProcessLasso.exe /SetActiveProfile=myprofile
/StartWithProfile=name
Switch to configuration profile, then launch Process Lasso. Requires v9.6.7+
ProcessLasso.exe /StartWithProfile=myprofile
ProcessGovernor.exe Command Line Parameters
Switch
Description
Examples
/ConfigFolder=
Indicates the configuration folder that should be used. It is assumed that ‘prolasso.ini’ will exist in it. If not, it one be created with default values.
When matching rules to processes, a match phrase is given by the user, often called the ‘process match’ in Process Lasso. This can be a simple process name, a string with wildcards, or even a Regular Expression checked against multiple process attributes (e.g. user and command line).
Traditional
Traditional process name matching uses a simple wildcard match, with ‘?’ indicating any single character and ‘*’ indicating a sequence of any character. It is case insensitive. The user name may be appended to the match string with a colon. Depending on the feature, after toggling on path or command line matching, those fields are also compared to the match phrase.
Examples (non-Regex):
chrome.exe
Match any process named chrome.exe
chrome*
Match any process that begins with 'chrome'
chrome.exe:bob
Match any process named chrome.exe running under user 'bob'
Regular Expressions
Process Lasso v9.5+ supports Regular Expression (RegEx) matching to multiple process attributes. This allows for the creation of complex rules that were not previously possible. For instance, a rule could act on Chrome.exe or Firefox.exe when user is Bob or Jeremy. Previously, this would require 4 different rules, and in the case of the Instance Balancer, combining them into a single group was not possible.
Features supporting RegEx:
CPU Limiter
Instance Balancer
Watchdog
ProBalance Exclusions
Persistent CPU Affinities (as of 9.5.7 beta)
Support for RegEx will be come to other features in future versions of Process Lasso.
What is a Regular Expression?
A Regular Expression is a language for pattern matching (and substitution). It has been in use for decades and enjoys widespread support.
A regular expression is a special text string for describing a search pattern. You can think of regular expressions as wildcards on steroids. You are probably familiar with wildcard notations such as *.txt to find all text files in a file manager. The regex equivalent is .*\.txt.
– RegexBuddy
When matching a RegEx, Process Lasso concatenates multiple fields about the process. The format of this consolidated process information string is:
PID,User,Process,Path,PPID,Parent,,,,CommandLine (always last)
Fields:
PID = process ID
User = user under which process is running
Process = basename of process
Path = file path of process image
PPID = parent ID
Parent = parent process name
CommandLine = process command line (this field is always last. Its index is subject to change!)
In this way, an expression can match to anything in the concatenated string, or only to specific fields, depending on how precise the expression is.
With Process Lasso, Regular Expressions are differentiated from traditional match phrases by encapsulation in forward slashes (e.g. ‘/myregex/’).
All matching is case insensitive. Embedded commas in a field (normally only in the command line field) are escaped with a backslash, so for precise rules this should be taken into account.
Examples
While RegEx allows for powerful matching on multiple patterns and fields, it can also be used in simple ways:
/firefox.exe/
Match 'firefox?exe' anywhere in any field. Note '.' is a wildcard in RegEx, but you can escape it like 'firefox\.exe' for more precision.
/,firefox\.exe/
Match only 'firefox.exe' at the start of a field (>0)
/,fire*.exe/
Match only 'fire*exe' at the start of a field (>0)
/,[fire*.exe|chr*.exe]/
Match only 'fire*exe' OR 'chr*exe' at the start of a field (>0)
/,bobsmith/
Match user 'bobsmith' at the start of a field (>0)
/,.*-type=renderer(^,)*$/
Match '-type=renderer' anywhere in last field (command line). Note starts with a comma, then ends before a new field occurs (see below for embedded commas).
/,.*-type=renderer[^(,)|(\\,)]*$/
Prior with handling of escaped embedded commas in the command line.
Advanced
To match specific fields, an expression such as this can be used to match specifically field 3 (the process name):
^([^,]*,){2}
Explanation:
^ = Starts at beginning of string
([^,]*,) = Not a comma repeated zero or more times, followed by a comma
{2} = Repeat prior match (a comma delimited field) 2 times
/^([^,]*,)(jeremy|bob),/
Match processes with username of jeremy or bob
/^([^,]*,){2}chrome\.exe,/
Match processes named chrome.exe
/^([^,]*,){2}.*chr.*,/
Match processes whose name contains with ‘chr’
/^([^,]*,){2}(chrome\.exe|firefox\.exe).*,/
Match processes whose name starts with ‘chrome.exe’ or 'firefox.exe'
/^([^,]*,){5}boinc\.exe.*,/
Match processes whose parent is ‘boinc.exe’
/^([^,]*,)(jeremy|bob),chrome\.exe/
Match processes whose name is chrome.exe under user of jeremy or bob.
/^([^,]*,){2}chrome.exe,.*,.*-type=renderer[^(,|\\,)]*$
Match process name ‘chrome.exe’ and has '-type=renderer' in the command line (last field)
/^([^,]*,){3}.*\\program files.*/
Match path containing ‘\Program Files\’ (matching is case insensitive).
How to test Regular Expressions
To test regular expression patterns, create a text file with rows simulating Process Lasso’s provided match string. Then use grep (WSL or Linux) or another tool to match RegEx. Note that the encapsulating forward slashes need to be removed. An example is:
