PmAgentAssist.exe does not spawn in session

Version 1

    Verified Product Versions

    AppSense Performance Manager 8.3AppSense Performance Manager 8.2AppSense Performance Manager 8.1AppSense Performance Manager 8.0

    Introduction

    When a user logs on to an endpoint, an instance of PmAgentAssist.exe does not spawn in the session even though the Performance Manager Service has started.  Another symptom that proves the issue is if you attempt to stop the PmAgent service in the Services Control Panel then it times out whilst attempting to stop.

    Detail

    If you analyze the "Wait Chain" of PmAgent using Resource Monitor you should notice ~5 threads.

    The cause of this issue is due to a malformed Security Descriptor when using Custom Event Log security as per the following Microsoft KB article:

    If the syntax is incorrect it will cause Performance Manager to hang during the phase of trying to get access to the Event Log at startup.

    When logging is enabled for Performance Manager you will notice that the is a long gap between events after the following line:

    CAuditingDispatcher::ConfigurationHasChangedHelper

    An example of the gap is below:

    3 16153010720 5976 10101 CAuditingDispatcher::ConfigurationHasChangedHelper 3 16528488553 6940   140 CAOMTaskThreadPool<class SchedulingXML::Scheduling::CTaskBaseImplC,class SchedulingXML::Scheduling::CTaskExecutionContextBaseImplC,enum SchedulingXML::Scheduling::eSchedulingState,enum SchedulingXML::Scheduling::eSchedulingType,class SchedulingXML::Schedulin TASK: SCHEDULED: 81D482C8-EAB9-482C-962C-CC31BD760F5C

    You will notice that there is a large gap between 16153010720 and 16528488553 of the two log entries where Performance Manager is performing no activity.

    The fix to this issue is to resolve the problem in the Custom Security Descriptor.

    The string can be found in the "CustomSD" value for each Event Log where it has been configured.

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog

    The Security Descriptor is extremely sensitive and must be accurate. A misplaced 'space' character is all that is required to cause this to fail.

    Working Entry:

    (A;;0x1;;;S-1-5-21-3885728452-2575681008-4177648373-1104)

    Failing Entry:

    (A;; 0x1;;;S-1-5-21-3885728452-2575681008-4177648373-1104)

    Notice that the only difference between the two entries is the space at the beginning between the ';' and the '0'.

    A reboot is required following the change to fix the Security Descriptors.