Memory Compression High RAM: Find What Is Using Memory

Memory Compression using high RAM usually means Windows is fitting inactive memory pages into less space while another workload creates demand. It does not mean the whole “In use (Compressed)” number belongs to compression. Read the value in parentheses, then compare Available memory, Committed memory, and the apps or driver pools that grow when the slowdown starts. Leave compression enabled while you collect that evidence; turning it off can shift more work to the page file without fixing the cause.

If the PC is already freezing, save what you can and close a large app normally. Restart if needed, then collect a fresh baseline before reproducing the problem. Do not install a RAM cleaner or delete system files to make the graph look smaller.

Read “In use (Compressed)” correctly

In Task Manager, open Performance → Memory. The first figure beside In use (Compressed) is the physical memory in use; the parenthesized figure identifies compressed memory within that total. For example, 12.0 GB (1.5 GB) does not mean Windows is using 13.5 GB, and it does not mean compression alone is using 12 GB. Those are illustrative numbers, not measurements from a test PC.

Compression stores memory pages in a smaller form in RAM. It is different from compressing a ZIP archive or reserving space on an SSD. Microsoft’s original description explains why the compression store can grow while reducing the space required for other processes’ data. [1]

In the Microsoft example above, 6.8 GB (0 MB) is physical memory in use with no compressed store reported. Committed 6.8/37.7 GB is a different reading: current committed memory and its limit. It is not a display of 6.8 GB currently stored in the page file. A modern Windows 11 layout looks different, but these counter distinctions are the useful part of the example.

• Available: memory Windows can make available to workloads. A sustained fall alongside lag matters more than a high overall percentage by itself.
• Committed: the amount of memory the system has promised compared with its current limit. Approaching that limit can cause allocation failures, freezes, or crashes. [2]
• Paged pool and non-paged pool: kernel allocations. Track their growth if the visible app list does not explain the total.

There is no universal “bad” compressed-memory size. A percentage without the installed RAM, workload, trend, and symptoms cannot tell you whether a repair is needed. Also, Secure System and its VBS memory use are a separate diagnostic path; do not disable Memory Integrity to address a compression reading.

Take three snapshots of the same workload

Use a short comparison before changing settings. Note the Windows build, installed RAM, time since restart, and which applications are open. Keep updates, scans, and other changing workloads in mind when comparing results.

1. Before: after restarting and letting sign-in activity settle, record In use (Compressed), Available, Committed, both pool values, and the biggest apps in Task Manager.
2. During: open the application, project, game, or browser tabs that reproduce the slowdown. Record the same counters and the app’s memory use.
3. After: save and close that workload normally, then record what falls and what keeps growing. If the problem takes hours, extend the observation rather than expecting a short test to find it.

Do not expect every number to return immediately to its starting value. Windows and applications cache data. What matters is a reproducible relationship between the workload, a growing allocation, and the symptom. A restart clearing the problem gives you a useful reset point; it does not identify the faulty component.

Follow the reading that keeps growing

One application grows with the slowdown

Sort Task Manager’s Processes list by Memory. If the top entry is a browser, use its own task manager to identify a tab or extension. If it is an editor, game, or photo app, repeat the comparison with a smaller project, fewer assets, or a local folder instead of a cloud source.

For a closer comparison, open Resource Monitor with resmon and select Memory. Compare the application’s Commit, Working Set, and Private values before and during the problem. Working Set concerns memory resident in RAM; Commit is not the same thing as current physical use. A continually growing app allocation is a lead to investigate, especially if closing that app relieves the pressure.

Update or repair the identified application, then repeat the same workload. Change one variable at a time. If the busy program is specifically Photos, follow the Microsoft.Photos.exe memory-use checks before resetting its data. Record the app version and reproducing file or action if you need to report a suspected leak.

The app list does not explain the total

Adding the visible process rows does not produce a complete accounting of physical RAM. Microsoft Sysinternals RAMMap can separate allocation types, file-backed memory, process working sets, and other uses. Open Use Counts, save a baseline snapshot, and save another during the slowdown. Compare the categories that changed. [3]

A large standby list alone is not a reason to empty it. Likewise, a large Memory Compression entry tells you where compressed pages reside, not which original workload caused demand. Look for the growing category and relate it to the earlier app comparison.

If non-paged pool keeps increasing under a repeatable workload, investigate a driver or kernel component. Record recent driver, VPN, security-software, peripheral, or virtualization changes. A support technician can use Microsoft’s PoolMon to identify growing pool tags over time. A pool tag narrows the investigation; it is not permission to delete a driver file. [4]

Update or roll back a specifically implicated driver through the PC/device vendor’s supported route, then retest. Avoid blanket driver-updater utilities and random registry fixes. For freezes that do not track memory growth, use the broader Windows freezing diagnosis to check storage, temperature, and driver errors.

Committed memory approaches its limit

Physical RAM pressure and commit exhaustion overlap, but they are not interchangeable. A system can run into its commit limit even when some physical RAM is available. The page file contributes to that limit and can also support crash dumps. [2]

Save your work, close the growing workload, and check whether a tuning tool disabled or tightly capped the page file. For ordinary home-PC diagnosis, restore automatic page-file management and leave adequate free space on its drive. On a managed PC, ask IT before changing it. Increasing headroom may stop immediate allocation failures, but it does not repair an app or driver that keeps allocating memory.

Growth follows sleep, a device, or a long session

Write down the trigger: resume from sleep, connect a dock, start a VPN, launch a VM, or leave an application open overnight. Repeat that sequence after a fresh restart and compare the same counters. If removing one optional device or closing one workload changes the pattern, take that evidence to its vendor. “It happens after sleep” is much more useful than “RAM is always high.”

Should you disable Memory Compression?

Keep it enabled as the starting point. Consider an off/on comparison only after the measurements above, when the same workload repeatedly stalls and you have enough memory headroom. Installed RAM capacity alone cannot predict a benefit, and there is no universal FPS improvement to claim. A restart by itself can temporarily clear a leak, so compare both settings from an equally fresh restart.

On your own PC, open Windows PowerShell as administrator. First run Get-MMAgent and record the MemoryCompression setting. If the command is unavailable, verify that you are in Windows PowerShell; do not replace missing cmdlets with an unknown downloaded script.

For a temporary comparison when the original setting is enabled, use:

Disable-MMAgent -MemoryCompression

Save work, restart, and repeat the same workload. Compare responsiveness, CPU activity, Available memory, and Committed memory—not just whether the compressed value disappeared. The parameter changes the memory-management feature; it does not remove the workload using memory. [5]

Restore the original enabled setting after the test, particularly if nothing improves or memory pressure gets worse:

Enable-MMAgent -MemoryCompression

Restart and confirm the setting with Get-MMAgent. [6] Keep your before/after notes. Do not combine this test with disabling SysMain, the page file, security features, and startup programs at once: you would lose the ability to tell which change mattered.

When to investigate an unwanted app

High RAM or the Memory Compression label alone is not a malware diagnosis. Investigate a security angle when the slowdown began after an unknown installer, comes with redirects or recurring security alerts, or an unwanted process returns through Startup, a service, or Task Scheduler. Keep a flagged file quarantined while checking its origin.

Removing the visible app may leave an associated startup entry or bundled component. In that situation, run a full Gridinsoft Anti-Malware scan, review detections, reboot, and check whether the unwanted activity returns. A scan can help find malicious or unwanted components; it does not fix an ordinary application’s memory leak or prove that a PC was never compromised.

What to keep if the problem returns

Keep the three counter snapshots, the app/driver versions, the exact workload or sleep sequence, and the setting before each test. Share only the relevant, redacted screenshots with support. A useful result is a repeatable trigger and a measured response to one change—not an empty RAM graph.

References

1. Aul, Gabe. “Announcing Windows 10 Insider Preview Build 10525,” Memory Manager Improvements. Microsoft Windows Insider Blog, August 18, 2015; accessed September 10, 2026. Compression-store design.
2. Microsoft. “Introduction to page files.” Microsoft Learn, updated February 12, 2026; accessed September 10, 2026. Committed memory and page files.
3. Russinovich, Mark. “RAMMap v1.63.” Microsoft Sysinternals, March 26, 2026; accessed September 10, 2026. RAMMap allocation views.
4. Microsoft. “Use PoolMon to find a kernel-mode memory leak.” Microsoft Learn, updated July 23, 2025; accessed September 10, 2026. Pool-tag investigation.
5. Microsoft. “Disable-MMAgent.” Microsoft Learn PowerShell reference; accessed September 10, 2026. Disable command syntax.
6. Microsoft. “Enable-MMAgent.” Microsoft Learn PowerShell reference; accessed September 10, 2026. Restore command syntax.