Skip to main content
Windows Agent 24.6.1401 (2024-02-22)
A
Written by Arick Disilva
Updated over a week ago

Improvements

Better Windows Event Logs Processing

We introduced a new behavior rule type, Windows Log Event in Platform Release 650. However, for this type of rule to work, the Agent would process the entire event log making this process slow and cumbersome. Especially, if you had multiple users on the same computer.

Now, we have made improvements so that the Agent will subscribe to the OS event channels (e.g., Authentication, Services, Process-Execution, Object-Manipulation, Sysmon, etc.) and listen to the Event IDs specified in the rule. This way, it will not have to scan the event log all the time. This should boost the performance and processing time significantly.

Notes:

Please note that there are some limitations to this approach. For example:

  • The current implementation monitors only specific channels that are retrieved from the registry. For this reason, it’s not a complete list of the channels and some of them (e.g. PrintService) might be skipped.

  • In some rare cases, the same Event ID may be used for different channels. In the example below, you can see that Event ID 1000 is being used by both Application Error and DummySource:

    In such a case, the Agent will trigger the rule for both events.

We expect to fix the limitations in a future version of the Windows Log Event rule.

Synchronized Updating of the Configuration File

Currently, the Agent Configuration file (config.cfg) is used by both the Agent and the services for reading and writing data. However, in rare situations, both of them might try to update the file at the same time causing a race condition. As a result, the file might get corrupted.

We have made changes to how the config file is handled so that any update/write to it will now be synchronized to avoid any race conditions.

Bug Fixes

Microsoft Teams Calendar Meetings would Appear on the Online Meetings Report

Due to a bug, MS Teams calendar meeting events would appear on the Monitoring > Online Meetings report even when the user didn't join the meeting.

For example:

  • Organizer created a calendar meeting with several participants including the current user, “Aymon Cousteau“

  • The Organizer started the meeting but Aymon didn't join.

  • The Organizer“ ended the meeting.

  • The meeting appears on the Online Meetings report of Aymon Cousteau.

The bug is fixed now so that unless a user joins the meeting, it will not be shown on their Online Meetings report.

Agent Process would Persist After the Agent Service Crashed

When the Agent Service (svc.exe for the Hidden Agent and tmagentsvc.exe for the Revealed Agent) is responsible for running services that monitor the user’s sessions and creates a new Agent Process (dwm.exe for the Hidden Agent and tmagent.exe for the Revealed Agent) for each session.

If the Agent Service is stopped, it closes the Agent Process and other support services and then restarts a fresh session.

However, due to a bug, if the Agent Service quit unexpectedly/crashed, it would leave the old Agent Process and other services running while also launching a new set of processes and services.

This would cause unexpected system behavior and might affect the monitoring and reporting on the Dashboard.

The bug is fixed now.

Did this answer your question?