0 Replies Latest reply on Apr 28, 2014 9:37 AM by richardk

    Performance considerations of process start triggers

    richardk Apprentice
      Since Environment Manager 8.0 was introduced, we've had extra triggers for Process Start / Stop under both the User and Computer nodes.
      One great advantage of this is the ability to run actions here that would normally be run at logon, but are not required until post-logon (note, Environment Manager 8.5 will introduce a new post-logon trigger specifically for this scenario), although this does require a process to trigger from. The benefit of this is not just reducing the logon time, but also the overhead of peak logon times.

      These are utilised in a number of ways:
      - Launching a dummy executable as part of the logon trigger, and run other actions based off of the process start of this dummy application. This tree of actions then run, but do not hold up the completion of logon (and subsequently when the shell is released / refreshed etc)
      - Using a (user) process start of Explorer.exe, or another application which will always start post-logon, such as a program launched via the Run key (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run).
      - Configure application specific settings on process start of the relevant application, such as Office, Internet Explorer etc.

      One possible downside to this approach is that as the number of process start nodes increases, a small delay is added to the start of every process that launches. This can be processes within the user session (unless excluded via the AsVfxLdr exceptions), where all User Process Start conditions are evaluated, or within Session 0 (unless excluded via ProcessWhiteList) where all Computer Process Start conditions are evaluated.

      As an example, take a configuration with 100 (User) Process Start nodes – not a common scenario, but at the same time not unheard of.
      For every executable that launches within the users session, Environment Manager will launch numerous threads to check against each node, and run the child actions/conditions as required.

      Using a single core Windows 7 virtual machine with 1GB ram, from the EM Debug logs I could see each node took on average 47ms to evaluate – or 4.7s in total (0.047 * 100) – if all nodes were a simple “match”, the delay is much less, but in this case a handful used regular expressions, meaning every process that executed caused Environment Manager to evaluate every regular expression each time.

      It’s also a little known fact that the process details (full path / filename) are propagated to all child nodes of a process start node, allowing us to base further conditions from the same process path/name. Although the console doesn’t allow you to create a process start node within another process start node, you can drag/drop or cut/copy/paste them.

      Using this method, I created a process start node using a regular expression:
      \c:\\progra.*\\.*
      I then called this node “Started in Program Files (Regex)”

      Note, Environment Manager uses the ATL Regular Expression library, so the \c: is not the C: drive, but an abbreviation for any single alphabetical character (see http://msdn.microsoft.com/en-us/library/k3zs4axe%28v=vs.80%29.aspx for more information). I also found that some processes were passing the 8.3 path name format (typically when using Start > Run), and some languages used Programme instead of Program Files.

      I then created some further process start nodes to handle specific vendors, then moved the original nodes to become child nodes of the these, ie:

      Regex: .*\\Adobe\\.*
      Node Name: “Started in Adobe (Regex)”

      Regex: .*\\micros.*\\.*
      Node Name: “Started within Microsoft”

      I've attached a screenshot to this post showing a sample of how this kind of approach is laid out in the console.

      The benefit may not seem apparent at first, but consider the 4.7s delay we added to every process start using 100 separate nodes. Assuming all of these processes live somewhere within Program Files (or Programme, Program Files (x86), etc) we now only have a single regex to check. If a common windows process, such as cmd.exe or SearchProtocolHost.exe is launched, the single regex isn’t matched and so we never enter the evaluation of the child nodes.

      Bear in mind, in the case where an executable is launched from here, the layers of regular expressions are evaluated synchronously rather than asynchronously, so if you only have two or three process start nodes (or only use basic “match” conditions which evaluate almost instantly) this approach may actually be slower, but for anything more complex, you’re likely to see an improvement in process startup time, and certainly a lower CPU overhead from EmUser.exe (or EmSystem.exe if this is for Computer Process Start actions).

      There are other areas of code that we also enter on process start notifications, such as checking if a process is managed under User Personalization, or checking if a refresh is required. The overhead of these can be reduced further using these exclusions - also bear in mind that from Environment Manager 8.3.232 onwards, they also accept full filepaths and folders, as well as filenames, for example:

      C:\ExcludedApps
      C:\Windows\notepad.exe
      calc.exe
      \\server\share\app\file.exe

      More information on the exclusions can be found on myAppsense:
      AsVfxLdr.sys Exceptions (EmUser):
      https://www.myappsense.com/Knowledgebase/TN-150952.aspx

      EmDriver.sys ProcessWhiteList (EmSystem):
      https://www.myappsense.com/Knowledgebase/TN-150953.aspx