Windows Agent | How to Use Sysmon to Identify Antivirus or EDR Interference with the Liongard Agent

Overview ✨

If the Liongard Agent behaves normally on a healthy reference machine but fails only on one endpoint, the cause is often local antivirus, endpoint detection and response (EDR), or security tooling interfering with the agent process. This article explains how to confirm that behavior using Microsoft Sysinternals Sysmon and how to gather the right evidence for remediation.

⚠️ Important: This guide focuses on identifying process interference on Windows endpoints. In many cases, the root cause is not a Liongard software defect, but a local or centrally managed security product stopping or monitoring the agent in a way that prevents normal operation.

Why this happens

The Windows Liongard Agent installation includes multiple components that work together. In environments with aggressive security controls, behavior such as service-spawned child processes, bundled libraries, background scanning activity, or network discovery functions can trigger antivirus or EDR heuristics.

When that happens, the service may appear to start normally, but the worker process may be terminated shortly after launch, prevented from writing logs, or blocked only when running under the Windows service context.

How the Liongard Agent works on Windows

The Liongard Agent installation directory is typically located at C:\Program Files (x86)\LiongardInc\LiongardAgent\.

LiongardAgentSVC.exe is the Windows service wrapper. It runs as the Liongard Agent service and launches the worker process.
LiongardAgent.exe is the primary worker process. It handles heartbeats, jobs, inventory activity, and other core agent functions.
AgentSVCLog.txt can provide useful service-side output even when the worker process does not fully initialize its own logs.
logs\agent.log and logs\error.log are created by the worker process during startup and runtime.

If security software interferes with the worker process, the wrapper may still appear healthy while the actual agent work never completes.

Common signs of AV or EDR interference

The logs folder does not appear after restarting the service.
The logs folder appears briefly and then stops updating.
AgentSVCLog.txt does not update after a service restart.
LiongardAgent.exe does not remain running, even though the service shows as running.
The agent runs manually from a shell, but not when launched by the Windows service.
The problem only occurs on one machine rather than across multiple systems.

Helpful clue 🕵️ : If a manual launch works but the service-launched process does not, that often points to interference tied to service context, process spawning, or behavior-based security controls rather than a damaged executable.

Before you start

Before using Sysmon, first confirm the installation is valid. This helps rule out broken registration or configuration issues that can look similar to security interference.

Check the configuration file

Open C:\Program Files (x86)\LiongardInc\LiongardAgent\appsettings-override.config and verify that the expected keys are present and populated with real values.

<appSettings>
  <add key="URL" value="usX.app.liongard.com" />
  <add key="EXEPATH" value="C:\Program Files (x86)\LiongardInc\LiongardAgent\LiongardAgent.exe" />
  <add key="AGENT_ID" value="######" />
  <add key="AGENT_NAME" value="HOSTNAME" />
  <add key="AGENT_TYPE" value="customer-on-prem" />
  <add key="AGENT_UID" value="..." />
  <add key="RESPONSE_QUEUE" value="https://..." />
  <add key="WORK_DIR" value="C:\Program Files (x86)\LiongardInc\LiongardAgent\" />
</appSettings>

If the file is missing, empty, or contains blank values, reinstall or re-register the agent before continuing. Sysmon will not help if the installation itself is incomplete.

Steps to Resolve

Step 1: Run a quick manual test

This test helps determine whether the executable itself can start outside the service context.

Stop-Service roaragent.exe
cd "C:\Program Files (x86)\LiongardInc\LiongardAgent"
.\LiongardAgent.exe

‼️ Important: A manual launch does not use the same environment variables or runtime context as the service. You may see errors such as missing URL or invalid agent identifiers. Those messages are expected during this test and do not automatically indicate a software defect.

What you are looking for is whether the process starts, whether it creates the logs directory, and whether it writes output before failing only on service-dependent or network-dependent actions. If it starts normally when run manually but fails when the service launches it, security interference becomes much more likely.

Step 2: Identify installed security software

Before collecting Sysmon events, inventory the security and monitoring tools on the endpoint. Some products clearly identify themselves, while others do not. This step is useful context, but it is not always conclusive on its own.

# Non-Microsoft services
Get-CimInstance Win32_Service | Where-Object { $_.PathName -and $_.PathName -notmatch 'Windows|Microsoft' } |
  Select-Object Name, DisplayName, State, PathName | Format-Table -AutoSize

# Registered antivirus products
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct -ErrorAction SilentlyContinue

# Installed programs matching common security or RMM vendors
Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*, `
  HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* |
  Select-Object DisplayName, Publisher |
  Where-Object DisplayName -match 'CrowdStrike|SentinelOne|ThreatLocker|Huntress|Sophos|Cylance|Carbon Black|Cortex|Trend|Webroot|Bitdefender|ESET|Malwarebytes|Datto|Continuum|ConnectWise|VIPRE|Defender'

# Minifilter drivers
fltmc filters

Even if nothing obvious appears, continue with Sysmon. Many EDR products do not register in the standard antivirus inventory locations.

Step 3: Install Sysmon with a targeted configuration

Download Sysmon64.exe from the official Sysinternals site and place it on the affected machine. Then create a configuration file named sysmon-liongard.xml with the following content:

<Sysmon schemaversion="4.90">
  <EventFiltering>
    <ProcessCreate onmatch="include">
      <Image condition="contains">LiongardAgent</Image>
    </ProcessCreate>
    <ProcessTerminate onmatch="include">
      <Image condition="contains">LiongardAgent</Image>
    </ProcessTerminate>
    <ProcessAccess onmatch="include">
      <TargetImage condition="contains">LiongardAgent</TargetImage>
      <GrantedAccess condition="contains">1</GrantedAccess>
    </ProcessAccess>
  </EventFiltering>
</Sysmon>

Install Sysmon from an elevated command prompt or PowerShell session:

cd C:\Tools
Sysmon64.exe -accepteula -i sysmon-liongard.xml

Why use a targeted configuration?

Restricting the event scope to Liongard-related activity keeps the event log easier to review and makes process-kill patterns easier to identify.

Step 4: Reproduce the issue

Restart the Liongard Agent service to generate a fresh event sequence.

sc stop roaragent.exe
sc start roaragent.exe

Wait a few seconds, then review the latest Sysmon events:

wevtutil qe "Microsoft-Windows-Sysmon/Operational" /f:text /rd:true /c:20

You can also review the same data in Event Viewer under Applications and Services Logs > Microsoft > Windows > Sysmon > Operational.

Step 5: Understand the key Sysmon events

Event ID	Meaning	What to check
1	Process Create	Confirms that LiongardAgent.exe launched. Review the process ID and verify the parent process is the Liongard service wrapper.
10	Process Access	Shows that another process opened a handle to the Liongard process. Pay close attention to the access mask. A value that includes terminate rights is more suspicious than read-only monitoring.
5	Process Terminate	Confirms that the process exited or was terminated. Compare the timestamp to any Event ID 10 activity that happened just before it.

The strongest pattern is usually: the worker starts, another process accesses it, and then the worker terminates almost immediately afterward.

Special case: WmiPrvSE.exe appears in the event

If the accessing process shown in Sysmon is WmiPrvSE.exe, do not assume WMI itself is the root cause. That process often acts as a proxy for another security tool that requested the action through WMI.

To investigate further, check the WMI activity log around the same timestamp:

wevtutil qe "Microsoft-Windows-WMI-Activity/Operational" /f:text /rd:true /c:30

Look for entries that include a client process ID or a method call such as Win32_Process::Terminate. That client process is often the real source of the action.

Why this matters: Some security tools terminate processes indirectly through WMI. In those cases, Sysmon may show the WMI provider host as the actor, while the real vendor process appears in the WMI activity log.

Step 6: Identify the security product

Once you have the process name that accessed or terminated the Liongard Agent, determine which vendor owns it. You can do this by checking installed software, service paths, or the file signature.

Get-AuthenticodeSignature "C:\path\to\file.exe"

If the process name is unfamiliar, search for the executable name along with terms such as vendor, security agent, or RMM process. Confirm ownership before moving to remediation.

Step 7: Remediate with the security vendor policy

If you confirm interference from antivirus, EDR, or an RMM-managed security tool, exclusions usually need to be applied in the product's management console. Local exceptions on the endpoint are often overwritten by central policy.

Request or apply exclusions for the following items:

Folder: C:\Program Files (x86)\LiongardInc\LiongardAgent\
Processes: LiongardAgent.exe, LiongardAgentSVC.exe, LiongardAgentUpdater.exe
Module-level exception, if supported: nmap.dll

⭐️ Best practice: If the security tool supports both path-based and process-based exclusions, use both where appropriate. This reduces the chance of recurring false positives after updates or policy changes.

Step 8: Validate the fix

After the updated policy is applied, restart the Liongard Agent service and confirm the endpoint behaves normally.

Verify that LiongardAgent.exe remains running after several minutes.
Confirm the logs directory exists and updates normally.
Review error.log and agent.log for successful heartbeats and normal runtime activity.
Confirm the agent communicates with the correct Liongard platform URL.

Step 9: Clean up diagnostic tooling

After the issue is confirmed resolved, uninstall Sysmon from the endpoint.

Sysmon64.exe -u

Removing temporary diagnostic tooling helps keep customer endpoints clean and reduces unnecessary background logging.

Quick reference commands

Task	Command
Check service status	sc query roaragent.exe
Check service configuration	sc qc roaragent.exe
Review folder permissions	icacls "C:\Program Files (x86)\LiongardInc\LiongardAgent"
Test outbound connectivity	Test-NetConnection your-liongard-url -Port 443
Check file signature	Get-AuthenticodeSignature "C:\path\to\file.exe"

When to contact support 🦁

Contact Liongard Support if you have completed the steps in this article and one of the following is true:

No security process appears in Sysmon or WMI logs, but the agent still terminates unexpectedly.
The agent does not run manually and appears to fail before any normal startup activity.
The configuration is valid, connectivity is confirmed, and exclusions have already been applied centrally.

FAQ's

Does a successful manual launch prove the service is healthy?

No. A manual launch only proves the executable can start outside the normal service context. It is still possible for the service-launched process to be blocked or terminated by security software.

Why is nmap.dll specifically worth excluding?

Some security products flag network scanning or discovery-related behavior. Because that library supports scanning functionality used by the agent, it can be a common trigger for false positives in tightly controlled environments.

Can I leave Sysmon installed after troubleshooting?

It is better to remove it when you are done unless there is a clear operational reason to keep it. This article recommends using it as a targeted troubleshooting tool, not as a permanent customer-endpoint component.