How to Detect a Memory Leak on Windows (And Find Which App Is Leaking)

Memory leaks are the slowest hardware-shaped failure on Windows. Nothing breaks. Sensors stay normal. CPU temperature is fine. Then, four hours into the workday, the PC freezes for thirty seconds, the page file thrashes, an app crashes, and Windows finally pops up a low-memory warning that names the wrong process. By the time you open Task Manager, the leaking application has already restarted itself or released the allocation in a panic, and the live snapshot looks innocent.

This is the gap that catches most users. The Windows tools that ship in the box assume you are looking at the leak as it happens. Real leaks build over hours, sometimes days, and the diagnostic moment you need is the one minute before the crash — which Task Manager has no memory of.

This guide covers what a memory leak actually is, the four classes of leak we see most often, why Task Manager and Resource Monitor misdiagnose them, and the per-process working-set tracking that catches a leak before it triggers a freeze. For broader context on why a PC slows down, see our 10 reasons your PC is slow guide.

What a Memory Leak Actually Is

A memory leak is allocated RAM that is no longer referenced by anything but has not been released back to the system. Every modern application asks Windows for memory in chunks ("working set") and is expected to return it when finished. A leak happens when the application asks for memory, uses it, abandons the reference, and never tells Windows it is done with the allocation. The memory stays reserved — from Windows' perspective, that application still needs it.

For C++ and unmanaged code, leaks are usually a missed delete or free. For .NET, Java, JavaScript, and other garbage-collected runtimes, leaks happen when a reference is held longer than intended — an event handler that never unsubscribes, a cache that grows without bound, a closure that captures a large object. The runtime cannot collect what is still referenced, even if nothing useful will ever read it again.

The practical consequence is the same in every case: the process's working set grows over time without ever shrinking back to a baseline. A normally healthy Outlook process might sit at 800 MB. A leaking one drifts up to 3 GB across an 8-hour workday and never comes back down without a restart.

The Four Classes of Leak We See Most

Across 500+ workstations we monitor, four leak patterns recur. They look identical in Task Manager ("a process using a lot of RAM"), but the cause and the fix are completely different.

1. Browser tab and extension leaks

A browser process can grow from 200 MB to 6 GB across a workday because of a single misbehaving tab or extension. The browser is the suspect; the actual culprit is one tab you opened in the morning and forgot about. Common offenders: ad-heavy news sites, dashboard apps that poll APIs every second, video players left paused, extensions that accumulate state instead of releasing it.

Diagnostic shortcut: Chrome and Edge have a built-in task manager (Shift + Esc) that breaks the browser process down by tab and extension. Opera and Firefox have similar tools. If one tab shows 1+ GB and others show 50-200 MB, that tab is the leak.

2. Office plugin and add-in leaks

Outlook, Excel, Word, and Teams accept third-party add-ins for CRM connectors, security tools, accessibility helpers, and compliance scanners. Many of these plugins allocate memory aggressively (parsing email bodies, indexing attachments, scanning workbooks) and rely on the host application to clean up. Some host implementations do not. The result: Outlook starts at 600 MB, climbs by ~150 MB per hour, and is at 2.5 GB by lunch.

Diagnostic test: launch the application in safe mode (outlook.exe /safe, hold Ctrl while launching Excel) which loads no plugins. If memory usage stays flat across an hour of normal use, a plugin is responsible. Disable plugins one at a time to find the offender.

3. Background sync runaway

OneDrive, Dropbox, and Google Drive can enter a re-sync loop after a brief connectivity blip and consume CPU plus RAM indefinitely. The agent is supposed to compare local file hashes with cloud state, find the deltas, and stop. When the comparison fails partway through, the agent restarts from scratch — over and over — holding the file index in memory each time.

Signature: high disk I/O and climbing RAM on the sync process specifically. Pause sync for thirty minutes to confirm; if memory drops, the sync agent was the leak. Restart the agent or sign out and back in to reset its state.

4. Long-lived application leaks (the slow ones)

Creative apps (Premiere, Photoshop, DaVinci Resolve), IDEs (Visual Studio, IntelliJ), and game launchers (Steam, Epic, Battle.net background process) all have known leak patterns where memory grows steadily across days of uptime. They do not crash; they just make the system feel sluggish until the user reboots.

These are the hardest to catch with Task Manager because the rate is slow — maybe 50 MB per hour — but the application stays running for sixteen-hour days across a week. By Friday the process is at 8 GB, and the user blames "Windows" instead of the app. A weekly restart suffices for most workflows; for fleet machines, a scheduled nightly reboot prevents this entirely.

Why Task Manager and Resource Monitor Miss Real Leaks

Task Manager shows you the live snapshot. That is what it is for. The Memory tab tells you which process is using the most RAM right now and how much of the system's RAM is committed.

Three limitations make this insufficient for leak detection:

1. No memory of the past. Task Manager cannot tell you what the working set was an hour ago, so you cannot see the climb. You see the current value and have to guess whether it is normal.
2. Spikes are invisible. A process that briefly hits 4 GB every few minutes during a sync cycle averages out by the time you check. The peak is the actual problem; the average is what you see.
3. The leak releases on close. When a leaking app crashes or is closed, its memory goes back to the system immediately. By the time you open Task Manager to investigate the freeze, the process you should be looking at is gone or smaller than it was.

Resource Monitor (resmon.exe) is slightly better. The Memory tab shows hard faults per second — a hard fault is when Windows had to fetch a memory page from the page file because RAM was full. Sustained hard faults above 10/sec on a desktop PC mean the system is paging actively, which is the symptom of being out of RAM. Useful, but still a snapshot.

For a real leak investigation you need three things Task Manager and Resource Monitor cannot give you: per-process working-set history over time, automatic detection of a process whose memory grows without releasing, and the context of what else was happening on the machine when the climb started.

How Per-Process Working-Set Tracking Works

A monitoring agent that captures a snapshot of every running process's working set every minute and writes it to a rolling 1-hour or 24-hour buffer can do something Task Manager fundamentally cannot: tell you that outlook.exe has gained 200 MB of RAM every hour for the past 6 hours, while every other process held steady. That is the textbook definition of a leak, and it is visible before the system runs out of memory.

This is exactly what GGFix's agent does on every monitored Windows machine. The collector samples the top 25 processes by memory and CPU every 60 seconds, records process name, working-set size, CPU percent, and window title, and feeds the time series to a per-process leak detector. The detector watches each process's working set across a sliding window and fires an alert when:

• The working set has grown for at least 30 minutes without any release event
• The growth is monotonic (no dips) past a configurable threshold (default: 500 MB above the process's recent baseline)
• The total system memory pressure crosses 80% — the leak is now actively hurting performance

When all three conditions hit, the agent emits a ram/memory_leak alert with the leaking process name, the growth rate, the time the climb started, and the top window title at the moment of detection. That alert reaches the user (Telegram or email) before Windows shows a low-memory warning, before the freeze, and — critically — before the process is killed and the evidence vanishes.

The AI layer adds the explanation. Instead of "high memory usage on chrome.exe," the user gets "Chrome has gained 3.2 GB of RAM in the last 4 hours, almost all of it on the tab Real-time Order Dashboard. Closing that tab will recover the memory." For most users, that single sentence is the difference between rebooting blindly and fixing the actual problem.

Manual Detection: What You Can Do Without an Agent

If you do not have a monitoring agent installed, the manual diagnostic flow takes longer but works. Here is the sequence:

1. Note the baseline. Reboot the machine, open the apps you normally use, and note each process's RAM in Task Manager. Write it down. This is your reference.
2. Check again at intervals. After 1 hour of normal use, check the same processes. Any that have grown by more than 30% are candidates.
3. Sort by trend, not size. A process that grew from 100 MB to 800 MB is more interesting than one that started and stayed at 1.5 GB. The growth is what matters.
4. Use Windows Performance Recorder for the hard cases. The free Windows Performance Toolkit records detailed memory allocation traces. WPR is overkill for most users but indispensable when you need to identify which call stack inside an app is leaking. Run a 5-10 minute trace covering the suspected leak window, then open in Windows Performance Analyzer and look at the Heap Allocations table.
5. Confirm with a restart. Close the suspected process. If system available memory jumps significantly, you found it.

This works once. For machines that leak repeatedly, or for fleets where you cannot watch each one personally, this manual flow is impractical — which is the case for continuous per-process monitoring.

Memory Leaks vs. Just Needing More RAM

These two are easy to confuse. Both feel like "my PC is out of memory."

Symptom	Memory leak	Insufficient RAM
Memory usage grows over hours	Yes	No
Releases on app restart	Yes	No
Process working set climbs unchecked	Yes (one specific process)	No (all processes proportional to load)
Closing an app frees significant RAM	Yes	Only the closed app's portion
Adding more RAM solves it	Temporarily, then leak fills new RAM too	Yes, permanently
Hard faults per second	Spikes after hours of use	Constant during normal use

If adding RAM "made the problem go away for a week" before returning, you have a leak — the new headroom just delays the wall. If the system has been at consistent 90% memory commit since day one across all workloads, you genuinely need more RAM.

When a Leak Is Not the Application's Fault

Not every memory climb is a software bug. Three hardware-adjacent causes can look exactly like a leak:

• Failing RAM modules — a stick that develops bit errors causes Windows to mark allocations as bad and reissue them, gradually consuming the available memory pool. The signature is correctable WHEA errors in Event Viewer climbing in parallel with memory pressure. Run MemTest86 to confirm. Our Windows Event Viewer hardware diagnostics guide covers the WHEA event IDs to look for.
• Driver leaks (paged pool) — some kernel-mode drivers leak paged or non-paged pool memory. The signature is the System process or the kernel pool growing without any user app being responsible. RAMMap from Sysinternals shows pool usage; large Paged Pool or Nonpaged Pool values point to a driver. Update or roll back recently changed drivers.
• Page file exhaustion masquerading as RAM exhaustion — Windows commits memory beyond physical RAM by backing it with the page file. If the page file is small (or set to system-managed on a near-full SSD), the machine can run out of commit before it runs out of physical RAM. Symptoms look identical to a leak. Increase page file size or free SSD space.

Frequently Asked Questions

Q: How do I tell which app is leaking memory on Windows?

Task Manager shows the live snapshot, which is rarely enough — leaks build over hours and the leaking process often releases its memory the moment it is closed. The reliable answer requires per-process working-set history captured every minute. Continuous monitoring agents that record the top 25 processes by RAM each minute can show exactly which process climbed and when. Without an agent, take a baseline immediately after reboot, recheck the same processes every hour, and sort by growth percentage rather than current size — the process that gained the most is your candidate.

Q: What does a memory leak look like in Task Manager?

A leaking process shows steadily climbing memory usage over hours without ever dropping back to its baseline. The process keeps growing even when you are not actively using it. In contrast, normal memory usage rises and falls with workload. The hardest leaks to spot are slow ones — 50 to 200 MB per hour — because the per-snapshot change is too small to notice. You only see the impact after a full workday when the process is at 4 GB and the system is paging.

Q: Can a memory leak crash my PC?

Indirectly, yes. Windows itself is robust against memory exhaustion — it pages aggressively to disk and starts terminating processes before the kernel runs out. The crash usually shows as the leaking app being force-closed by the system, an unrelated app crashing because no memory was available when it asked, or a complete freeze while the page file thrashes. On machines with limited RAM (8 GB or less), a major leak can also trigger Event ID 41 unexpected shutdowns when the page file fills the SSD.

Q: How do I fix a memory leak on Windows?

Identify the leaking process first — there is no generic "fix" because the cause depends on which app. For browsers, find and close the leaking tab or extension (Shift + Esc in Chrome and Edge). For Office apps, launch in safe mode and disable plugins one at a time. For sync agents (OneDrive, Dropbox), pause sync and restart the agent. For long-lived creative apps and IDEs, schedule a daily restart. If the leak is in a kernel driver or the System process, update or roll back recently installed drivers. If multiple apps grow in parallel and WHEA errors climb in parallel, suspect failing RAM and run MemTest86.

Q: Why does my PC slow down after a few hours of use?

The most common cause is a memory leak in one of the apps you keep open all day — typically your browser, an Office app with plugins, or a sync agent. As the leaking process grows, Windows starts paging memory to disk to keep the system running. Disk is 10–100x slower than RAM, so every operation slows down. The fix is finding the leaking process, not adding more RAM — a leak will fill any amount of RAM you give it.

Q: Is there a memory leak detector for Windows?

Windows has no built-in memory leak detector for end users. The Windows Performance Toolkit (WPR/WPA) is a powerful free trace tool from Microsoft, but it requires technical knowledge and is meant for developers, not users. Continuous monitoring tools designed for IT and home use track per-process working sets over time and detect leaks automatically — GGFix monitors the top 25 processes every minute, fires an alert when one grows monotonically without releasing, and uses AI to name the exact tab, plugin, or sync source responsible. That converts a multi-hour debugging session into a one-line notification.

Q: How can I tell the difference between a memory leak and just needing more RAM?

Memory leaks grow one specific process's working set over hours and release the memory when that process is closed or restarted. Insufficient RAM shows constant high memory commit across all processes from the moment you start your normal workload, with steady hard faults per second. The fastest test: close the suspected leaking app and check whether available RAM jumps significantly. If yes, it is a leak; if no, you need more memory or a smaller workload.