Startup/Login Condition Expression Syntax

The startup and login timing conditions are configured using condition expressions. You enter them in the Startup and Login Reporting section of the Agent Configuration Group Settings.

Conditions are used for the following settings:

Setting	Controls	Default value
Startup Condition	When the computer startup measurement ends	`<PROCESS; winlogon; started> and <SERVICE; GUARDagent; started; "PremiTech Performance Guard Agent">`
Login Start Condition	When the user login measurement starts	`<SESSION; logon>`
Login End Condition	When the user login measurement ends	`<PROCESS; GUARDagent; started> and <PROCESS; explorer; started> and <CPU; explorer; below; 10>`

Timing of computer startup is controlled by measuring the time between the moment when the first parts of the operating system start and the moment when the Startup Condition becomes true. If the condition doesn’t become true within Startup Timeout In Seconds (default 1200 seconds), the startup measurement fails.

The login time is the period between the moment when the Login Start Condition becomes true until the moment when the Login End Condition becomes true.

Expression structure

A condition expression consists of condition terms combined with logical operators. Supported logical operators are:

and
or
not

You can use parentheses ( ... ) to control the order of evaluation.

The following types of condition terms are available:

WINVERSION
PROCESS
CPU, MEM and IO
SERVICE
SESSION

Condition terms are not case sensitive, and they are enclosed in angle brackets < ... >.

Example:

( (<WINVERSION; WIN7> or <WINVERSION; WIN2008R2>) and <PROCESS; wdm; started> ) or ( (<WINVERSION; VISTA> or <WINVERSION; WIN2008>) and <PROCESS; explorer; started> )

This expression becomes true when wdm.exe starts on Windows 7 or Windows Server 2008 R2, but on Windows Vista or Windows Server 2008 it becomes true when the explorer process starts.

Condition term overview

Condition term	Parameters	Description	Example
`WINVERSION`	Windows version ID	True on computers that run the specified Windows version. See WINVERSION condition terms.	`<WINVERSION; WIN10>`
`PROCESS`	Process name; `started` or `stopped`	True when the process has started or stopped.	`<PROCESS; winlogon; started>` `<PROCESS; init.exe; stopped>`
`CPU`	Process name; `above` or `below`; value	Process CPU usage above or below the value, in percent.	`<CPU; dwm; above; 10>` `<CPU; dwm; below; 3>`
`MEM`	Process name; `above` or `below`; value	Process memory usage above or below the value, in KB.	`<MEM; csrss; above; 200000>`
`IO`	Process name; `above` or `below`; value	Process combined read/write I/O average rate above or below the value.	`<IO; system; below; 1500>`
`SERVICE`	Process name; `started`; service name	True when the service is registered as started within the process.	`<SERVICE; svchost; started; EventSystem>`
`SESSION`	Session event	True when the session event happens. See SESSION condition terms.	`<SESSION; logon>`

When specified process names are compared to running processes, extensions are removed and comparison is case-insensitive. This means that it’s optional whether you specify, for example, the .exe extension.

WINVERSION condition terms

WINVERSION terms are used to make a single condition behave differently depending on the operating system on the target computer. This way you can deploy a single condition expression throughout an entire organization, even if different Windows versions are used. The term is always true on a computer that runs the specified Windows version.

Version ID	Windows version
`XP`	Windows XP
`XP64`	Windows XP 64-bit
`WIN2003`	Windows Server 2003
`VISTA`	Windows Vista
`WIN2008`	Windows Server 2008
`WIN7` or `WINDOWS7`	Windows 7
`WIN2008R2`	Windows Server 2008 R2
`WIN8` or `WINDOWS8`	Windows 8
`WIN2012`	Windows Server 2012 and Windows Server 2012 R2
`WIN81` or `WINDOWS8.1`	Windows 8.1
`WIN10` or `WINDOWS10`	Windows 10 and all later Windows versions, including Windows 11 and Windows Server 2016 and later

PROCESS, CPU, MEM and IO condition terms

The process condition terms take a number of different forms. You can use a term to check if a named process has been started or stopped, or you can use it to check the CPU, memory or I/O usage of a named process.

If multiple instances of the specified process are running, the term is attached to all instances. For example, <CPU; svchost; above; 10> becomes true if any of the running instances use more than 10% CPU.

SERVICE condition terms

The service condition term is used to check if a particular service is running.

The term <SERVICE; svchost; started; EventSystem> becomes true when the EventSystem service is registered as started with the Service Control Manager within svchost. Note that the names of services may be different depending on the locale of the operating system. The name that you supply for the service is compared with the service names registered for the given process. If the specified name appears as part of the name, the term evaluates to true. If you specify TCP as the service name, it matches any service that contains TCP in its name.

SESSION condition terms

The session condition terms change values when user sessions change state:

Term	Becomes true when
`<SESSION; connect>`	A session is connected, at the console or remotely.
`<SESSION; disconnect>`	A session is disconnected.
`<SESSION; logon>`	A user logs in to the session.
`<SESSION; logoff>`	A user logs off the session.
`<SESSION; lock>`	The session is locked.
`<SESSION; unlock>`	The session is unlocked.

Label expressions

When you specify expressions for the login start and end conditions, PerformanceGuard by default generates labeled values. This is used to ensure that PerformanceGuard is able to handle asynchronous logins correctly. Multiple asynchronous logins can be an issue on multi-user Windows computers, typically servers running as application servers or Citrix servers.

Expression labeling is supported for the SESSION, PROCESS, CPU, MEM and IO terms.

If required, you can disable labeling for a term by appending [-]. Examples:

<SESSION; connect[-]>
<SESSION; logon[-]>
<SESSION; lock[-]>
<PROCESS; guardagent[-]; started>
<PROCESS; winlogon[-]; stopped>
<CPU; guardagent[-]; above; 10>
<MEM; explorer[-]; above; 10>
<IO; explorer[-]; below; 10>

When labeled expressions are used, PerformanceGuard is able to distinguish between events generated by different users, and match labels in the start and end conditions correctly. It’s fine to mix labeled and unlabeled expressions. In such cases an unlabeled expression is treated as if it was generated simultaneously by all possible labels.

BNF for condition terms

condition-term          ::= metric-condition | process-condition | version-condition | service-condition | session-condition
metric-condition        ::= '<' metric ';' process ';' operatorc ';' threshold '>'
process-condition       ::= '<' 'PROCESS' ';' process ';' operatorp '>'
service-condition       ::= '<' 'SERVICE' ';' process ';' 'started' ';' service-name '>'
session-condition       ::= '<' 'SESSION' ';' session-event ['[-]'] '>'
version-condition       ::= '<' 'WINVERSION' ';' versionid '>'
metric                  ::= 'CPU' | 'MEM' | 'IO'
versionid               ::= 'xp' | 'xp64' | 'win2003' | 'vista' | 'win2008' | 'win7' | 'windows7' | 'win2008R2'
                          | 'win8' | 'windows8' | 'win2012' | 'win81' | 'windows8.1' | 'win10' | 'windows10'
operatorp               ::= 'started' | 'stopped'
operatorc               ::= 'below' | 'above'
threshold               ::= integer ['%']
session-event           ::= 'connect' | 'disconnect' | 'logon' | 'logoff' | 'lock' | 'unlock'
process                 ::= identifier ['[-]']
service-name            ::= identifier
identifier              ::= alfa [alfa-digit]*
alfa                    ::= 'a' | 'b' ... 'z' | 'A' | 'B' ... 'Z' | '_' | '.' | '-'
alfa-digit              ::= alfa | digit
integer                 ::= [digit]+
digit                   ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'