Microsoft Defender for Endpoint (MDE) provides advanced endpoint protection, detection, and response capabilities for Linux systems. While the solution is designed to operate efficiently, administrators may occasionally experience performance issues such as high CPU utilization, excessive memory consumption, increased disk I/O, or application slowdowns.

A common issue is the performance impact experienced when installing and configuring Defender in active mode. By default, Defender for Endpoint on Linux operates in passive mode. When enabling the AV in block mode, there is sometimes a CPU increase and performance impact depending on the installed tools.

This blog focuses specifically on identifying, diagnosing, and resolving performance-related issues in Microsoft Defender for Endpoint on Linux.

What are the most common performance issues affecting Defender for Endpoint on Linux Performance issues are typically related in one or more of the following ways:

  • High CPU utilization by Defender processes
  • Increased memory consumption
  • Elevated disk I/O activity
  • Slow application startup times
  • Delayed file operations
  • Build pipeline or CI/CD job slowdowns
  • Container workload performance degradation

The Defender-related process most commonly associated with performance issues is wdavdaemon (more on this later).

Understanding the MDE Architecture on Linux

Before diving into troubleshooting, it’s helpful to understand the key components of Defender for Endpoint on Linux:

Before troubleshooting the performance issues, it is important to know which process is related to the CPU spikes. In most cases, the process responsible is wdavdaemon, which handles the core antimalware service and real-time scanning.

ProcessLocation
wdavdaemon
Core daemon (service). Uses FANotify for both antimalware and EDR purposes (TALPA on older RHEL).		/opt/microsoft/mdatp/sbin/
wdavdaemon enterprise
EDR engine. Used for enrichment.		/opt/microsoft/mdatp/sbin/
wdavdaemon unprivileged
Antivirus engine		/opt/microsoft/mdatp/sbin/
crashpad_handler
Collects crash dumps		/opt/microsoft/mdatp/sbin/
mdatp
Command line utility		/opt/microsoft/mdatp/sbin/Wdavdaemonclient
mde_netfilter
Packet filter for Network protection, also used for response capabilities		/opt/microsoft/mde_netfilter/sbin

Event provider

If the system reports auditd, switching to eBPF can significantly reduce event-processing overhead. eBPF is the default and most recommended event provider. New installations are running automatically on eBPF (when using the latest installer files)

Linux Auditd has long been the foundation for security auditing on Linux, providing a reliable way to capture security-relevant events for compliance, forensic investigations, and accountability. However, as Linux workloads have evolved to include containers, cloud-native applications, and large-scale distributed environments, eBPF has emerged as a more flexible approach to runtime observability.

Unlike Auditd’s rule-based auditing, eBPF enables lightweight, programmable instrumentation within the Linux kernel, allowing security solutions to collect richer context, filter events before they leave the kernel, and implement advanced detections with minimal performance overhead.

Since version 101.2408.0000 auditd is no longer supported as a supplementary event provider. Check whether eBPF is enabled can be checked via KQL:

DeviceTvmInfoGathering
| extend AF = parse_json(AdditionalFields)
| where AF.EBPFStatus == true

Which process

To view the process running on the system:

PS aux

To view the process running on the system:

PS aux | grep wdav

Before troubleshooting the performance issues, it is important to know which process is related to the CPU spikes. Common is wdavdaemon. Make the difference between AV and EDR first before analyzing the processes and data.

Troubleshoot performance issues using Real-time Protection Statistics

Real-time protection (RTP) is a feature of Defender for Endpoint on Linux that continuously monitors and protects your device against threats. It consists of file and process monitoring and other heuristics.

To find the applications that are triggering the most scans, you can use real-time statistics gathered by Defender for Endpoint on Linux.

Note: Linux version 100.90.70 or newer is required for the RTP protection statistics. This feature is enabled by default on the Dogfood and InsiderFast channels. If you’re using a different update channel, this feature can be enabled from the command line:

How to enable statistics?

mdatp config real-time-protection-statistics --value enabled

Collect current statistics:

To collect current statistics, run:

mdatp diagnostic real-time-protection-statistics --output json

For the top 20 contributors to performance issues:

mdatp diagnostic real-time-protection-statistics --sort --top 20

The output is a list of the top 20 contributors to performance issues. For example, the output of the command is something like the following:

As seen in the image, the first process with ID 755 is scanning 17 items and is active. The more scanned items in the total files scanned field, the more expected performance issues. This is useful to track where the resource is used as part of the RTP feature.

To improve the performance of Defender for Endpoint on Linux, locate the one with the highest number under the Total files scanned row and add an antivirus exclusion for it (carefully evaluate if it’s safe to exclude. Never exclude paths without any risk calculation, since processes are by design calculated with a high number of files scanned.

Troubleshoot performance issues using Hot Event Source

Applies to: Performance issues in files and executables that are consuming most CPU cycles in the entire filesystem.

Hot event sources are a feature that is able to identify which process or directory is responsible for high resource consumption. To investigate which process/executable is generating the most noise, follow these steps.

Before starting with Hot Event Sources troubleshooting, the log level needs to be changed from info to debug.

mdatp health --field log_level

If it’s not on “debug” you need to change it for a detailed report regarding hot files/executables.

sudo mdatp log level set --level debug

For collecting events use the following commands:

sudo mdatp diagnostic hot-event-sources files

Cancel the trace after some time; as a result, there will be a hot_event_source JSON file. This file can be used for further investigation and performance research.

Once you’ve finished the investigation, you can change the log level back to “info”.

sudo mdatp log level set --level info

Troubleshoot performance issues using eBPF Statistics

Applies to: All file/ process events, including system call-based performance issues.

The eBPF (extended Berkeley Packet Filter) statistics command provides insights into the top event/process generating the most file events, along with their syscall IDs. When system calls are made from the system, a high amount of workload is generated on your system. eBPF statistics can be used to identify such issues.

To collect current statistics using eBPF statistics, run:

mdatp diagnostic ebpf-statistics

The diagnostic ebpf statistics timeframe will run for 20 seconds and capture the eBPF statistics component.

How to read the files?

Many logging tools generate output in JSON or TXT format. While these formats are excellent for storing detailed information, they quickly become difficult to work with when log files grow to thousands or even millions of entries. Finding the events that matter most, such as those responsible for high CPU utilization, can become a time-consuming task.

If you’ve ever had to explain why Microsoft Defender for Endpoint is using 40% CPU on a Linux server, you’ve probably found yourself doing something like this:

mdatp diagnostic real-time-protection-statistics --output json | jq '.counters | sort_by(-(.totalScanTime | tonumber))' | head -50

And then squinting at raw JSON while trying to remember whether totalScanTime was in nanoseconds or milliseconds. And then doing math in your head to figure out which of the 130 process entries account for 80% of the load. And then repeating that whole exercise for the behavior monitor JSON, the hot event sources JSON, and eBPF statistics files.

One effective way to simplify analysis is to focus on the most significant event sources rather than reviewing every log entry. For real-time protection scenarios, filtering the results to display only the top 20 files by CPU usage provides a much clearer view of system activity.

MDE reader

Currently, I am testing/ developing a new web-based application (HTML) where the files can be analyzed locally with more visual options to filter and highlight top events.

It’s a single HTML file. You open it in a browser, drag your diagnostic files into the sidebar, and everything renders locally. All analysis is performed locally in your browser. No files are uploaded, and the application doesn’t make any network requests. The tool never makes a network request.

As part of the analyzer, you can upload the files (locally), and the analyzer visualizes the performance and items. It tracks the following:

  • Realtime diagnostics
  • Behavior monitor
  • Hot event sources
  • eBPF stats

Step 1: Collect the files via the commands as explained above and collect the JSON/txt files.

Step 2: Upload the output files to the locally hosted application.

Step 3: Review the overview and specific output

When the files are uploaded, the following overview is visible. From the direct overview, you can see the top process by scan time in a visual widget. From the total scan time of 74.07s, filebeat is the most common process.

The first thing you see after loading files is a summary that tries to answer the questions you actually have:

  • How much total scan time is being spent? Where does it go?
  • Which processes dominate? Is one of them responsible for most of it?
  • Are there anomalies – processes with weird scan patterns like one file taking 800ms?
  • Any unidentified processes I should care about?

The findings section calls out patterns automatically. If one process is responsible for more than 50% of scan time, that shows up as a red flag. If the same process dominates both antivirus scanning and EDR event volume, that’s flagged separately because it’s a stronger signal that a single exclusion would have double impact.

When digging deeper into the individual views, you can see the path/ scan time and additional information:

Realtime Stats: sortable table of every process with scan time, file count, max per file, and status.

Behavior Monitor: same idea but for EDR event volume. This is a separate dimension from scan time. A process that generates 8,000 EDR events per minute is a different kind of load than one that spends 60 seconds scanning files, and reducing one doesn’t necessarily reduce the other.

Hot Events: top file paths and directories by auth event count. Useful for identifying candidates for folder exclusions when a specific application writes to a lot of files in a known location.

eBPF Stats: combines multiple 20-second capture runs, showing initiator paths and file paths with R1/R2/R3 badges indicating which patterns are consistent across runs versus one-off spikes. Kernel-level view, so it catches things that don’t show up in the userspace realtime data.

On a recent Linux server, I was investigating slow application performance. Loaded the realtime.json into the tool and immediately saw:

filebeat  67.67s, 91.4% of total scan time, 5,454 files scanned, active

That’s a 91% concentration in one process. Filebeat is a log shipper; its whole job is to read log files continuously and forward them somewhere. Every read triggers Defender’s real-time protection. On a busy server, this can significantly increase CPU utilization and overall resource consumption:

Then I loaded the behavior.json:

filebeat  8,234 EDR events, 27.8% of total events sent

Would I have found this by reading raw JSON? Yes, eventually. But the tool made it a 30-second observation instead of a 20-minute analysis. This gives some more context as part of the investigations.

Is this always needed?

The short answer is no. Enabling this does not reduce security by itself; it simply makes the output files easier to read and helps identify the individual processes or paths that are responsible for most issues, including performance bottlenecks.

That said, every exclusion introduces a potential coverage gap and should be carefully reviewed to ensure it is justified and does not create unnecessary risk.

Where to find it?

This tool is currently under active development and testing. If you’re interested in learning more, discussing potential use cases, or early testing, feel free to reach out via email or send me a message on LinkedIn.

Sources

Microsoft: Troubleshoot performance issues for Microsoft Defender for Endpoint on Linux