Fixing High Memory Usage from Memory Compression and the System Process

Seeing “Memory Compression” or the “System” process consuming a large amount of memory in Task Manager alarms a lot of Windows users into believing something is malfunctioning, when in a substantial number of cases, this is Windows working exactly as designed — distinguishing the normal case from a genuine problem requires understanding what these specific entries actually represent.

What Memory Compression actually is

Introduced with Windows 10, Memory Compression is a legitimate, by-design Windows mechanism that compresses infrequently-used memory pages in RAM rather than immediately writing them out to the much slower page file on disk. This lets Windows keep more effective working data in fast RAM (in compressed form) before resorting to disk-based paging, which is a genuine performance improvement over older behavior — seeing a non-trivial amount of memory attributed to “Memory Compression” in Task Manager is not, by itself, evidence of a problem; it’s evidence the mechanism is actively doing its job.

When Memory Compression usage is actually worth investigating

The signal worth paying attention to isn’t the memory attributed to compression itself, but whether the system as a whole is under genuine, sustained memory pressure despite it — visible as consistently high overall memory usage combined with actual performance degradation (sluggish application switching, disk activity spiking as the page file is used heavily despite compression). If overall system responsiveness is fine and only the Memory Compression figure itself looks large, that’s very likely the mechanism working correctly rather than a problem needing a fix.

The “System” process and non-paged pool memory

Separately, the “System” process showing elevated memory usage in Task Manager typically reflects kernel-mode memory consumption — non-paged pool memory used by drivers and kernel components. Unlike Memory Compression, sustained, continuously growing System process memory usage genuinely can indicate a problem: specifically, a driver with a memory leak in kernel-mode memory, which is a more serious category of leak than an ordinary application-level leak, since kernel memory isn’t as straightforwardly reclaimable as a misbehaving user-mode application’s memory would be (which can simply be closed to reclaim its memory).

Identifying a leaking driver using poolmon

poolmon.exe

(available via the Windows Driver Kit, or downloadable as a standalone tool) shows a live, per-tag breakdown of kernel pool memory allocations, sorted by consumption — a specific pool tag consuming an unusually large and continuously growing amount of memory points at the specific driver subsystem responsible, since each tag corresponds to a specific driver or kernel component’s allocations.

Mapping a pool tag back to the responsible driver

Once a specific, suspicious pool tag is identified from poolmon, mapping it to the actual driver responsible:

findstr /m "tag_name" %systemroot%\System32\drivers\*.sys

This searches driver binaries for the specific tag string, which — while not always a perfectly precise match — usually narrows down the responsible driver enough to identify whether it’s a specific piece of third-party hardware’s driver (worth checking for an update from that manufacturer specifically) or a Windows-internal component (worth checking Windows Update for a fix, or reporting through Feedback Hub if genuinely novel).

Checking Task Manager’s own memory breakdown carefully

For ordinary application-level memory concerns (as opposed to kernel/System process memory), Task Manager’s Details tab, with the Memory column added, sorted descending, identifies which specific user-mode process is actually consuming the most memory — worth checking directly rather than assuming based on the simplified default Processes tab view, which doesn’t always surface every relevant process clearly.

When it’s simply too many memory-intensive applications running at once

As with any operating system, sometimes elevated memory usage isn’t a leak or malfunction at all — it’s the legitimate aggregate demand of several genuinely memory-intensive applications (browsers with many tabs, virtual machines, large development environments) running simultaneously. In this case, closing some concurrently running applications, or considering a memory upgrade if this is a recurring pattern rather than an occasional peak, is the accurate response rather than searching for a bug that isn’t actually present.

Why understanding Memory Compression specifically prevents wasted troubleshooting effort

A meaningful amount of “Windows is using too much memory” concern traces directly back to not understanding that Memory Compression’s reported figure is by-design behavior, not a leak — recognizing this distinction upfront avoids spending troubleshooting effort chasing a “problem” that’s actually just Windows’s memory manager functioning correctly, and redirects that effort toward the cases (sustained System process growth, genuine application-level leaks) that actually warrant it.