High memory pressure in Windows can turn smooth multitasking into lag, application freezes, and frequent disk activity when data gets pushed out of RAM. Spotting which processes consume memory and how the system is caching or paging helps explain slowdowns before they become crashes.
Windows memory usage is tracked as physical RAM (per-process Working Set) and committed virtual memory (per-process Commit) backed by RAM or the pagefile. Resource Monitor exposes these counters in one place, alongside graphs like Hard Faults/sec that reveal when the system is reading memory pages from disk.
Some readings are easy to misinterpret without context. A large Standby list is often healthy cache that can be reclaimed quickly, while high Commit does not always mean the same amount of physical RAM is currently in use. Process termination is not required for monitoring, and administrative privileges may be needed to see full details for protected processes.
Standby is cache that can be reclaimed quickly, while Modified must be written to disk before reuse.
Commit reflects virtual memory promised to a process (backed by RAM or the pagefile), while Working Set is the physical RAM currently in use.
Sorting by Working Set (KB) highlights immediate RAM usage, while sorting by Commit (KB) highlights allocation pressure over time.
A steady stream of hard faults often indicates the system is reading memory pages from disk instead of RAM.
Focusing on one process makes a steadily growing Commit value easier to spot when investigating a possible memory leak.