Why Your RAM Cleaner's "Freed" Number Is Lying to You

Pineapple — Mon, 17 Aug 2026 12:38:48 +0000

Quiesce is a Windows system cleaner I built in Go - single .exe, no installer, no background service. It clears out the usual junk (temp files, prefetch, error reports, Windows Update cache, logs, DNS cache) and includes a RAM optimizer I put more thought into than I expected to.

That RAM optimizer is actually where this whole post comes from. I noticed vendor tools like ASUS's Armoury Crate and CCleaner report freeing way more RAM than a "correct" implementation does - and figured out why, which changed how I built this part of Quiesce.

The setup

Windows memory cleanup, at the API level, comes down to four operations:

#	Operation	API
1	Purge standby list	`NtSetSystemInformation(80, 4)`
2	Flush modified list	`NtSetSystemInformation(80, 3)`
3	Trim every process's working set	`EmptyWorkingSet(hProcess)` per PID
4	Purge system file cache	`NtSetSystemInformation(80, 5)` / `SetSystemFileCacheSize(-1,-1,0)`

Vendor tools that report dramatically bigger numbers are almost always also doing #3 - and that's where things get interesting.

Where the big numbers actually come from

EmptyWorkingSet walks every running process and forcibly pages its private working set out to the pagefile/standby list. Task Manager's "In use" bar drops instantly, because those pages are no longer counted as in-use. Run a standby purge (#1) right after, and the memory genuinely reads as free.

Looks great visually. Here's the problem.

The honest caveat

The pages evicted by EmptyWorkingSet were live, working pages - memory the app was actively using. The moment you switch back to that app (alt-tab to Chrome, tab back into your game), Windows has to hard-fault every one of those pages back in from disk. You trade an impressive-looking graph for a burst of disk I/O and visible stutter.

Mark Russinovich has called these tools out for exactly this - memory that isn't "recovered," just displaced.

Standby-list purging (#1/#2), by contrast, is the defensible half: standby pages are already-clean cache, and dropping them costs nothing but a re-read if you happen to need that file again. No stutter, no real cost.

What I actually shipped

Given that tradeoff, I didn't want to just bolt on #3 as a silent "bigger number" toggle. Instead, Quiesce ships four separate, labeled options:

Sub-option	What it does	Default
Flush modified list	Writes dirty pages to disk so they can be freed	ON
Purge standby list	Frees the cached/standby page list	ON
System file cache	Drops the kernel's cached file data	OFF
Trim working sets	Pages out live app memory	OFF

The two safe operations are on by default. The two that can cause real, felt stutter are explicit, off-by-default opt-ins - and when working-set trimming does run, it always skips the current foreground process and protected system processes, so whatever you're actively using never gets gutted.

Does it actually work?

Ran the full cleaner (not just RAM optimization) on a friend's PC that hadn't been cleaned in a long time:

\Total items cleaned : 229277 [6] Windows Update Cache : 228364 items [10] RAM Optimization : 1880 MB freed (37.1% -> 25.6%, -11.5%) ran: trim, flush, file cache, standby [76 procs trimmed, 130 skipped] [11] Recycle Bin : 5.13 GB freed \\

7GB+ disk space reclaimed, over 200K stale update cache files gone, zero crashes across about 5 minutes of continuous operation.

The takeaway

If a cleaner tool shows you a big "memory freed" number, ask how. Standby/cache purging is real, free cleanup. Working-set trimming is a real technique too - but it has a genuine cost, and tools that apply it silently to everything (including whatever you're actively using) are trading your experience for a better-looking number. Quiesce lets you choose which trade you're making, instead of making it for you.

Source is public on GitHub if you want to see exactly what it does before giving it Administrator rights, or grab the latest release if you just want to try it.