After a RAM Upgrade: Pagefile and Cache Settings to Revisit

First, confirm Windows actually sees the new RAM

Open Task Manager → Performance → Memory and read the numbers before touching anything: Total should match the modules you installed, and "Hardware reserved" should stay in megabytes, not gigabytes. If several gigabytes sit in Hardware reserved, there are two usual suspects: the integrated GPU claiming a chunk in BIOS/UEFI, and the Maximum memory checkbox left enabled in msconfig — uncheck it and reboot. While you are there, check Speed: without the XMP or EXPO profile enabled, DDR4 sticks quietly run at 2133 MT/s and DDR5 at 4800, and Task Manager will tell on them.

Then stress the new configuration before you trust it: a mixed kit of old and new modules is the classic source of rare, maddening crashes, and memtest86 overnight catches what a quick boot does not. Matched pairs in the right slots matter too — two sticks in single-channel slots instead of the paired ones cost you real bandwidth. Verify first, tune second; half of the "RAM upgrade made my PC slower" stories are misconfigured kits, not Windows settings.

The pagefile: leave it automatic, or size it deliberately

Disabling the pagefile does not make Windows "use only RAM" — it makes the commit limit equal physical RAM. Windows grants every process a commit allowance (reserved address space it may write to), and programs reserve far more than they use; with no pagefile, all those reservations count against your sticks simultaneously. Heavy committers — Chrome with dozens of tabs, After Effects, VMs, modern games with overlays — start getting allocation failures, which arrive as crashes, not warnings. And a full memory dump still requires a pagefile roughly the size of your RAM on the boot volume; without one, a bluescreen writes nothing and you debug blind.

The right setting for most people is the one that was already there: "Automatically manage paging file size for all drives". With 32 GB or more, a system-managed pagefile typically stays small, because almost nothing actually pages out — the file exists as commit headroom and crash-dump space, not as evidence of a problem.

• Task Manager → Performance → Memory — Total, Speed and "Hardware reserved" tell you more than any guide
• Virtual memory dialog (sysdm.cpl → Advanced → Performance → Settings → Advanced) — keep the automatic checkbox on
• "No paging file" is the one option never worth it: the commit limit drops to physical RAM and dumps stop being written
• Manual sizing, if you insist: a few fixed GB are plenty; the multipliers from the HDD era are folklore now that the file sits on an SSD
• Put it on the fastest SSD you have, but on the boot volume — otherwise there is no dump to read after a crash

Cache behavior changes — and that is the point

Expect standby memory to sit higher than before and do not panic: freed RAM becomes file cache, and Windows hands it back the instant anything asks. "Cached" in Task Manager is memory doing a job, not memory being wasted; the machine that shows almost no cache after an upgrade is the one with the problem. Memory compression also changes character: with 16 GB it worked constantly, with 32 GB or more it often never engages, because compressing is only worth it when pressure exists.

Retire the old tweaks while you are at it. ReadyBoost was a flash cache for HDD systems with too little RAM — on an SSD with 32 GB it does literally nothing. Registry hacks like DisablePagingExecutive belonged to 32-bit Windows and change nothing measurable today. SysMain is worth leaving alone: on an HDD machine it genuinely helps launch times, and on an SSD its cost is so low that disabling it is a ritual, not a fix. The upgrade gave you headroom; the best tweak is to stop paying the tweakers' tax on it.

Questions and Answers

Read next