Skip to content
Pagefile.sys Parser
← Back to the blog

Should you delete or disable pagefile.sys?

5/20/2026 · 5 min read

If you got here because pagefile.sys is eating 16 GB of your SSD — first, this is normal. It scales with RAM. The interesting question isn't "can I delete it?" (yes, you can) — it's "should I?". The honest answer is "usually no, but sometimes yes, and it depends on whether you ever want to analyze a memory issue, a crash, or — relevant to this site — a security incident."

What pagefile.sys is for

  1. Memory overflow. When physical RAM is exhausted, the Memory Manager pages cold memory to disk. Without a page file, the kernel has nowhere to put overflow — apps start dying with out-of-memory errors.
  2. Crash dumps. When Windows blue-screens, the dump writer (crashdmp.sys) cannot allocate new disk space — it writes the crash dump to the page file on the boot volume, then renames it to MEMORY.DMP on the next boot. No pagefile = no crash dump.
  3. Modified-page list management. Even when you have plenty of RAM, Windows uses the pagefile to opportunistically write out infrequently used modified pages so the freed RAM can be used for I/O cache.
  4. Forensic / IR evidence. As this site documents, the pagefile is one of the most valuable artifacts on disk during an incident — a record of what was in RAM that wouldn't otherwise persist.

How big does it need to be?

Microsoft's own guidance:

Set the maximum size to three times the installed RAM or 4 GB, whichever is larger.

For typical desktop / laptop use, leave it at "System managed size". Windows will grow it dynamically.

For servers, the answer depends on whether you want kernel crash dumps:

  • No crash dumps: 1 GB or less is fine; Windows still needs some pagefile for the modified-page list.
  • Small kernel dump: 256 KB.
  • Kernel dump: roughly the size of kernel-mode memory in use (~10–800 MB typical).
  • Complete dump: RAM size + 1 MB.
  • Automatic memory dump (default on Windows 8+): Windows picks a size based on observed crash history.

Why you might disable it

There are legitimate reasons:

  • Tiny SSDs in old laptops. If you have 16 GB RAM and a 64 GB SSD, the 24 GB pagefile is painful.
  • Read-only / kiosk / appliance systems. If the workload's memory needs are known and bounded, you can run without paging.
  • High-security systems. The same property that makes pagefile forensically useful — that it holds plaintext copies of in-memory secrets — makes it a leak surface. A laptop that's lost or stolen with its disk decrypted yields its pagefile to anyone who reads the raw sectors. (Mitigation: see the next section.)
  • Test environments, where you want deterministic memory behavior.

Better than disabling: encrypt it

Windows has a setting that encrypts the pagefile with a per-boot ephemeral key:

fsutil behavior set EncryptPagingFile 1

After reboot, the contents of pagefile.sys are encrypted with a key that's destroyed on shutdown. For forensic analysis: the file is unrecoverable after a clean shutdown (intentionally — that's the whole point). For a live or crash acquisition, you can still mine it because the key is in RAM.

For security-sensitive systems, EncryptPagingFile = 1 plus BitLocker full-disk encryption is the right combination: BitLocker handles at-rest; pagefile encryption handles the case where the host is running but somehow loses physical custody. See the encrypting pagefile.sys post for the full setup.

How to actually disable / resize / move it

Through the UI:

System → Advanced system settings → Performance → Settings → Advanced → Virtual memory → Change

Through PowerShell (one-shot, requires reboot):

# Take Windows out of "System managed"
$cs = Get-WmiObject Win32_ComputerSystem -EnableAllPrivileges
$cs.AutomaticManagedPagefile = $false
$cs.Put()

# Set explicit size on C:
$pf = Get-WmiObject Win32_PageFileSetting -Filter "Name='C:\\pagefile.sys'"
$pf.InitialSize = 4096    # MB
$pf.MaximumSize = 8192    # MB
$pf.Put()

# Or remove pagefile entirely:
$pf.Delete()

Then reboot. The file is removed (or resized) at next boot.

The IR / forensic view

Disabling pagefile makes a host less informative during incident response. You lose:

  • Paged-out command lines, payloads, decoded strings.
  • Carved file fragments (PE, registry, browser DBs).
  • Plaintext credentials that paged out of LSASS.
  • Crash dumps in MEMORY.DMP.

If you're hardening a fleet for incident response readiness, the right call is to keep pagefile.sys, encrypt it with EncryptPagingFile, and combine with BitLocker — not to disable it.

If you're hardening a fleet against incident occurrence (less data on disk for a thief to take), and you accept the operational cost, disabling is defensible — but then also turn off crash dumps explicitly or you'll have a confusing failure mode.

Common myths

"pagefile.sys causes SSD wear."

Negligible on modern SSDs. Pagefile writes are tiny compared to general file-system writes on a typical desktop. The TBW (terabytes written) rating of a consumer NVMe SSD is hundreds of TB; you will not exceed it by leaving pagefile on.

"I have 64 GB of RAM, I don't need a pagefile."

You still want one — at least a small one — for crash dumps and modified page list management. Set it to 1–4 GB explicitly.

"Moving pagefile to another drive makes Windows faster."

True only if you have two physically separate disks and your workload is actually paging. Moving pagefile from one partition to another on the same physical drive does nothing useful. Modern systems with enough RAM rarely page anyway.

Related