High Memory Usage
p>The High Memory Utilization insight identifies devices where memory consumption exceeds the configured threshold. Sustained high memory usage forces the operating system to use disk storage as temporary memory — a process called swapping — which significantly slows down applications and reduces overall device responsiveness.This insight helps administrators:
- Identify how many devices are affected and whether the issue is isolated or fleet-wide
- Pinpoint the application or process consuming the most memory
- Determine whether the issue is software-driven or a hardware capacity limitation
- Identify devices that can be upgraded with additional RAM versus those that need replacement
Note
This insight monitors device-level memory utilization. For a full per-device breakdown with timestamps, logged-on user details, and swap activity history, refer to the Memory Usage Report under DEX > Reports.
Trigger Conditions
The High Memory Utilization insight is generated when:
- Memory usage on a device exceeds the configured threshold.
- Default threshold: Memory usage greater than 75%.
- Threshold values can be customized based on organizational workload requirements.
Tip
75% memory utilization is a reasonable general threshold. However, devices running virtual machines, developer tools, or video editing software routinely operate above this level by design. Consider setting a higher threshold (85—90%) for those device groups to avoid alert noise, and a lower threshold (65%) for standard office workstations.
Accessing the Insight
- In Endpoint Central, click DEX in the top navigation bar.
- Select Insights from the left sidebar.
- Locate the insight: "Devices experiencing application slowdowns due to high Memory usage".
- Click the insight name to open the detail view.
Navigation
DEX > Insights > Devices experiencing application slowdowns due to high Memory usage
Note
The Insights page lists all active insights grouped by category. The High Memory Utilization insight appears under the Device Performance category. Use the Category filter at the top of the Insights list to narrow down if needed.
Interpreting the Insight Metrics
The insight details page provides information that helps determine whether the issue is driven by a specific application, concentrated in devices with a particular memory configuration, or linked to a specific hardware model.
| Metric | What it shows | How to use it |
|---|---|---|
| Total Impacted Devices | Number of devices currently exceeding the memory threshold (e.g., 14 out of 45 total) | Assess the scale. A large number affected simultaneously — especially after a software deployment or OS update — suggests a systemic cause. A gradual increase over time points to aging hardware or growing workloads. |
| Top Impacted Memory Size | The RAM configuration most commonly found among impacted devices (e.g., 16 GB) | Identifies whether devices with a specific amount of installed RAM are disproportionately affected. Click View More to open the Impacted Memory Sizes Summary, which shows: Memory Size, Total Devices in Memory Size, Affected Devices, % of Devices Affected, and Insight Contribution %. If 16 GB devices account for 71% of insight contribution, those devices may need a RAM upgrade — especially if they run memory-intensive workloads like Teams, Chrome with many tabs, or development tools. |
| Top Impacted Model | The device model most frequently associated with high memory usage (e.g., NoteBook H6580) | Identifies whether a specific hardware model is disproportionately affected. Click View More to open the Impacted Models Summary showing Model Name, Total Devices, Affected Devices, % of Devices Affected, and Insight Contribution %. If 100% of a specific model's devices are affected, that model may have a memory ceiling too low for current workloads. |
| Top Memory Process | The application consuming the most memory across impacted devices, shown with its usage percentage (e.g., ms-teams.exe 25.97%) | This is your primary investigation starting point. A single process appearing across multiple devices is the fastest path to root cause. Click View More to see a per-process breakdown of affected devices and contribution percentage. The percentage shown is that process's share of memory on the device where it is the top consumer — not a fleet-wide average. |
Tip
Start with Top Memory Process. If the same application appears across multiple devices, a single remediation action (update, policy, or restart schedule) can reduce memory pressure fleet-wide.
Analyzing Affected Devices
Below the summary cards, a device table lists every machine currently exceeding the memory threshold. This is where you move from insight to investigation.
Understanding the columns
| Column | What to look for | What it means for remediation |
|---|---|---|
| Memory Usage % | Devices above 90% are critically impacted (e.g., BerniceBlackwell at 91.63%) | Prioritize these immediately — the device is very likely already paging to disk, causing visible application slowdowns for the user. |
| Memory Spikes | A high count (5—6+) indicates persistent, recurring memory pressure — not a temporary burst | A low spike count may indicate a one-time workload peak. A high spike count (e.g., 6 spikes) means the device regularly exhausts its memory and requires active remediation. |
| Memory Swap Rate | How frequently the OS is moving data between RAM and disk (e.g., 2031.00 for AnneRoy) | A high swap rate is a critical signal — it means the device has already run out of usable RAM and is using the much slower disk as overflow. Performance will be significantly degraded. This device needs immediate attention. |
| Memory Swap Size | The total amount of data swapped between RAM and disk (e.g., 1803.4 TB, 3479 TB) | Indicates how much data the OS has had to move to disk due to insufficient RAM. Very large values confirm severe memory insufficiency. Note: These values may appear very large (TB range) due to cumulative measurement over the monitoring period — they represent total swap activity, not a single-point-in-time snapshot. |
| Top Memory Process | The specific application consuming the most memory on that device (e.g., ms-teams.exe, chrome.exe, winword.exe) | Different devices may have different top memory processes. Treat each device individually — the fleet-wide top process may not be the cause on every affected device. |
| RAM (GB) | The total physical memory installed on the device (e.g., 16 GB) | Provides hardware context. A device with 16 GB running Teams, Chrome, and Outlook simultaneously may legitimately need more RAM. Cross-reference with the Top Impacted Memory Size card. |
| Used Slots | The number of RAM slots currently occupied on the device (e.g., 1 slot used) | Critical for upgrade planning. A device showing 1 Used Slot means there is likely a free slot available — RAM can be added without replacing the existing module. A device with all slots used requires replacing existing RAM with higher-capacity modules. |
Sorting and filtering the table
- Click the Memory Usage % column header to sort descending and surface the most critically impacted devices first.
- Click the Memory Swap Rate column to sort by swap activity — devices with the highest swap rate need the most urgent attention.
- Use the search icon above the table to find a specific device by name.
- Use the filter icon to scope the table by device group, OS version, or branch office.
Root Cause Investigation
Use the following sequence to move from observation to a specific, confident root cause before taking action.
Step 1 — Identify the process
Review the Top Memory Process summary card and the Top Memory Process column in the device table. Ask:
- Is the same process appearing across most impacted devices? If yes, this is an application-level issue addressable at scale.
- Are different devices showing different top processes? If yes, the issue may be workload-specific — investigate device by device.
- Is the process unfamiliar? Validate the executable path and publisher before taking action. An unrecognized process consuming high memory could indicate unauthorized software or a memory leak.
Common memory-intensive processes and their usual causes:
| Process | Likely Cause | First Action |
|---|---|---|
| ms-teams.exe | Microsoft Teams holds significant memory — especially when multiple meetings, chats, and channels are open simultaneously | Advise users to fully close Teams when not in use (not just minimize to tray). Check for a pending Teams update via Software Deployment. Consider deploying a policy to limit Teams background activity. |
| chrome.exe | Each Chrome tab runs as a separate process and consumes its own memory allocation. Multiple tabs and extensions compound this rapidly | Advise users to close unused tabs. Audit and restrict memory-heavy extensions via a Configurations policy. Consider enabling Chrome's Memory Saver feature through a browser policy. |
| winword.exe / excel.exe / powerpnt.exe | Office applications with many large files open simultaneously, or documents with embedded content | Advise users to close documents when not in use. If this appears on many devices, check whether a recent Office update changed memory behavior. |
| outlook.exe | Large mailboxes, many open email folders, or a large number of calendar items | Check if the user's mailbox is unusually large. Consider an Outlook profile repair or enabling cached exchange mode with a limited sync window. |
Step 2 — Check memory size and model drill-downs
Click View More under Top Impacted Memory Size to open the Impacted Memory Sizes Summary. This breakdown shows:
- Memory Size — the RAM capacity (e.g., 16 GB, 32 GB)
- Total Devices in Memory Size — how many managed devices have this RAM configuration
- Affected Devices — how many are currently exceeding the threshold
- % of Devices Affected — proportion of devices with that RAM currently impacted
- Insight Contribution % — how much this memory tier contributes to the overall insight
Click View More under Top Impacted Model to see model-level breakdown. If a specific hardware model (e.g., NoteBook H6580) accounts for 71% of contribution and shows 100% devices affected, that model's standard memory configuration may be too low for the applications deployed to it.
Step 3 — Assess swap activity
Devices showing a high Memory Swap Rate or large Memory Swap Size have already exhausted their physical RAM. The OS is compensating by using disk storage — which is significantly slower than RAM. This is where users experience the most visible performance impact.
These devices should be treated as the highest priority regardless of their Memory Usage % rank, because they are actively degraded — not just approaching a threshold.
Step 4 — Validate with the Memory Usage Report
For historical context, click View Memory Usage Report at the top right of the device table. This report provides:
- Logged On User — correlates memory spikes with the specific user's activity or workflow
- Collected Time — enables identification of time-of-day patterns (e.g., memory pressure peaks every morning during startup sync)
- Full device metrics — Memory Usage %, Swap Rate, Swap Size, Top Memory Process, RAM (GB), Used Slots
Navigation
DEX > Reports > Memory Usage Report
Tip
If multiple devices show memory spikes at the same timestamp, cross-reference with scheduled tasks or software deployments. A mass Teams update enabling new background features, or a backup agent running at a fixed time, may be the trigger.
Remediation
Use the table below to match what you observe to the right remediation path. Always verify the issue has resolved using the Memory Usage Report after taking action.
| If you see this... | Do this |
|---|---|
| ms-teams.exe or chrome.exe is the Top Memory Process across 5+ devices | This is an application-level issue. Advise users to close the app completely when not in use, and close unused browser tabs. Check for a pending update for the application. Deploy a Configurations policy to restrict background memory usage if the problem persists. |
| High Memory Swap Rate and large Memory Swap Size on a device | The device has exhausted its physical RAM and is actively degraded. First: restart the device to clear accumulated swap. Then check the RAM (GB) and Used Slots columns — if the device has a free slot, escalate to IT for a RAM upgrade. If all slots are used, the device needs higher-capacity RAM modules or full hardware replacement. |
| 16 GB devices account for 70%+ of insight contribution | Devices with 16 GB RAM are insufficient for the current workload profile. Review the Used Slots column in the device table. Devices with 1 Used Slot can be upgraded immediately by adding a second RAM module. Create a hardware upgrade plan for these devices and prioritize by Memory Swap Rate severity. |
| Top Impacted Model shows 100% devices affected for a specific model | The standard memory configuration shipped with that model is too low for the applications deployed to it. Compare the model's default RAM against the memory requirements of the top processes running on those devices. Escalate to hardware refresh planning. |
| Memory Spikes count is consistently high (5—6) with the same Collected Time across devices | A scheduled task, sync operation, or application auto-update may be running at that time and consuming a memory burst. Cross-reference the timestamp in the Memory Usage Report with scheduled tasks and Software Deployment history. |
| An unfamiliar process appears as the Top Memory Process | Do not terminate it immediately. Validate first: right-click the device > Remote Actions > Open Command Prompt, then run: wmic process where name='<process>' get executablepath,description. Verify publisher and path. An unrecognized process in AppData or Temp is suspicious and should be escalated to your security team. |
| A single user's device has persistently high memory while similar devices do not | Check whether the user runs a specific combination of applications that others do not (e.g., Teams + multiple Chrome windows + Outlook + Excel simultaneously). Connect via Remote Actions > Remote Desktop to observe active memory usage in real time. Assess whether a RAM upgrade is the most practical solution. |
| Device count increases significantly within a short period | A software deployment, OS update, or new policy may have introduced a memory-heavy change. Navigate to Software Deployment and filter by recent activity. If a deployment correlates with the increase, review or roll back the package. |
Post-Remediation Monitoring
After taking corrective action, confirm the issue is resolved before closing the investigation.
- Return to DEX > Insights. The device count on the High Memory Utilization insight should have decreased. If it has not, the root cause has not been addressed.
- Open DEX > Reports > Memory Usage Report and filter by the previously impacted devices. Confirm Memory Usage % has returned to expected levels and Memory Swap Rate has dropped to near zero.
- If a specific process was identified as the cause, verify it no longer appears as the Top Memory Process on those devices.
- Set up an Alert (DEX > Alerts) targeting the affected devices with a memory threshold notification so you are informed immediately if the issue recurs.
Important
If the same devices reappear in this insight within 48 hours of remediation — especially with high swap activity — the hardware is likely the root cause and software remediation alone will not resolve it. Escalate to hardware upgrade planning. If the issue persists, contact support.
