How to Use Resource Monitor to Find a Memory Leak on Windows 11

Quick fix: Open Resource Monitor (search Start menu or run resmon). Switch to the Memory tab. Sort by Commit (KB) column — the process whose Commit grows steadily over hours is leaking. Watch Hard Faults/sec: persistent non-zero values indicate the leak is forcing swap.

Your PC’s RAM usage climbs from 4 GB at boot to 14 GB after a day. You don’t have 14 GB of work open. Something is leaking. Task Manager shows totals but not history; Resource Monitor lets you watch Commit values per process over time to identify which app is the culprit.

What causes this

A memory leak occurs when an app requests memory but doesn’t release it after use. Over hours or days, leaked memory accumulates — the process consumes more and more RAM until Windows starts paging to disk (slowdown) or the process crashes. Common causes: browsers with many tabs, Electron-based apps (Slack, Discord, Teams, VS Code), background sync utilities, and certain antivirus products.

To identify, you need to observe Commit (committed bytes) over time. Commit is the memory the process has actually allocated, not just reserved. Steady Commit growth = leak.

Method 1: Identify the leaking process with Resource Monitor

The standard route. Built into Windows.

1. Press Win + R, type resmon, press Enter.
2. Switch to the Memory tab.
3. The top section shows all processes with these columns: Image, PID, Hard Faults/sec, Commit (KB), Working Set (KB), Shareable (KB), Private (KB).
4. Click the Commit (KB) column header to sort descending. The biggest memory consumers are at the top.
5. Note the top 5 processes’ Commit values. Wait 1–4 hours. Return to Resource Monitor.
6. Compare the Commit values now vs. earlier. Processes whose Commit increased significantly without doing more work are leaking.
7. For automated long-term tracking: use Performance Monitor (perfmon). Add counter Process → Working Set → (process name). Configure to log to a file over 24 hours.
8. Watch the Hard Faults/sec column: if a process consistently shows non-zero values, it’s being forced to page memory in/out. Sign of memory pressure.

This is the diagnostic step. Identifying which process leaks is half the battle.

Method 2: Use Process Explorer for deeper analysis

For more detail than Resource Monitor provides.

1. Download Process Explorer from Microsoft Sysinternals (free).
2. Run as administrator. The interface shows all processes in a tree.
3. Right-click any column header → Select Columns → Process Memory tab. Tick Private Bytes, Working Set, Virtual Size.
4. Sort by Private Bytes. This is the most reliable measure of a process’s memory commitment.
5. Right-click a suspect process → Properties → Performance Graph tab. Shows real-time and historical memory usage for that process.
6. For deepest analysis: right-click process → Properties → Performance tab. Watch Page Faults Delta and Working Set Delta. Sudden large increases indicate active allocation.
7. For Electron-based apps (multiple child processes): right-click the top-level process → Process Tree. Sum the child processes’ memory — this is the app’s total footprint.

Process Explorer is the right tool when you need to understand where in a complex app the leak is.

Method 3: Use Windows Performance Toolkit for kernel-level memory tracing

For developers and advanced users investigating non-obvious leaks.

1. Install Windows Performance Toolkit (WPT): part of Windows Assessment and Deployment Kit (ADK), free from Microsoft.
2. Launch Windows Performance Recorder (WPR).
3. Select profile: General → Heap usage. This traces all heap allocations.
4. Click Start. Use the PC normally for 1–4 hours. The longer, the more useful.
5. Click Save to capture the trace. WPR writes an ETL file.
6. Open the trace in Windows Performance Analyzer (WPA). Navigate to Memory → Heap Snapshot.
7. The analyzer shows heap allocations per process. Look for unfreed allocations growing over time — these are the leaks.
8. For .NET apps: use dotnet-counters or PerfView for managed-heap analysis. .NET leaks often hide behind references to GC roots; standard tools miss them.

This is the deep diagnostic path. Use for development or when standard tools don’t identify the leaking app.

How to verify the fix worked

• After restarting the suspect process, memory usage should drop sharply.
• Over the next few hours, the process’s Commit value should stay relatively flat — not climbing 100MB+/hour.
• Total system memory pressure should reduce: Task Manager → Performance → Memory — In Use stays stable rather than climbing.

If none of these work

If you’ve identified the leaking app but can’t fix it (it’s third-party, no update available), workarounds. Auto-restart the app daily: schedule a Task Scheduler task that kills and restarts the app at 3 AM. The leak resets to baseline each day. Browser-specific: Edge and Chrome have built-in memory savers. Edge: Settings → System → Memory saver → toggle on. Sleeping tabs reduce memory by hours of inactivity. For Electron apps (Slack, Discord, VS Code): use the web version in browser instead. Web versions often have better memory management because they share a browser process. For driver-level leaks (rare but possible): check Reliability Monitor (search Start). System leaks show up as “System” process growing — usually driver-level. Update or roll back drivers. For PCs with persistent unexplained memory pressure: malware can leak deliberately. Run a full Windows Defender scan and Malwarebytes scan. Last resort: increase virtual memory (page file) to defer slowdown, then attack the root cause when you have time.

Bottom line: Resource Monitor → Memory tab → sort by Commit. Note values, wait hours, compare. The growing process is the leak. For deeper analysis, Process Explorer’s Performance Graph shows the time series per process.