Should you delete or disable pagefile.sys?

If you landed here because pagefile.sys is eating 16 GB of an SSD: that is normal, it scales with RAM, and the interesting question is not whether you can delete it (you can) but whether you should. The honest answer is "usually no, sometimes yes, depending on whether you ever want to analyse a memory issue, a crash, or a security incident". This post is the practitioner view of that trade.

What pagefile.sys is actually for

Memory overflow. When physical RAM is exhausted the Memory Manager pages cold memory to disk. With no pagefile the kernel has nowhere to put overflow and processes start dying with STATUS_NO_PAGEFILE (0xC0000054) or out-of-memory failures from VirtualAlloc.
Crash dumps. When Windows blue-screens the dump writer (crashdmp.sys) cannot allocate new disk space. It writes the dump to the pagefile on the boot volume, then renames it to MEMORY.DMP on the next boot. No pagefile means no crash dump.
Modified-page list management. Even with plenty of RAM, Windows uses the pagefile to opportunistically flush infrequently-used modified pages so the freed RAM can serve as cache.
Forensic and IR evidence. The pagefile is one of the highest-yield artifacts during an incident, a record of what was in RAM and otherwise would not persist.

The configured paths and sizes are governed by HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PagingFiles and the PagingFiles REG_MULTI_SZ value inside. That is the registry key to read when you want to know what Windows is doing without booting.

How big does it need to be

Microsoft's guidance:

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

For desktops and laptops, leave it at "System managed size" and stop thinking about it. For servers, the answer depends on whether you want kernel crash dumps:

No crash dumps: 1 GB or less. 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, typically 10 to 800 MB.
Complete dump: RAM size + 1 MB.
Automatic memory dump (default on Windows 8 and later): Windows picks a size from observed crash history.

Why you might disable it

There are legitimate reasons:

Tiny SSDs in old laptops. A 64 GB SSD with 16 GB RAM is painful at 24 GB of pagefile.
Read-only kiosk or appliance systems where the workload memory footprint is known and bounded.
High-security systems where the same property that makes pagefile useful in forensics, plaintext copies of in-memory secrets, is a leak surface. A stolen laptop with a decrypted disk yields its pagefile to anyone with sector access. Mitigation in the next section.
Test environments that need deterministic memory behaviour.

That is roughly the entire defensible list. "I have lots of RAM" is not on it. The modified-page list still needs somewhere to go.

Better than disabling: encrypt it

Windows can encrypt the pagefile with a per-boot ephemeral AES key:

fsutil behavior set EncryptPagingFile 1

After reboot, the file is AES-encrypted with a key that dies at shutdown. From a forensic perspective the file is unrecoverable after a clean shutdown. From a live or crash acquisition you can still mine it because the key is in RAM. For security-sensitive systems, EncryptPagingFile = 1 plus BitLocker is the right combination: BitLocker handles the at-rest case, pagefile encryption handles the case where the host is running and 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, reboot to apply):

# 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()

Or write to the registry directly and reboot:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
    PagingFiles (REG_MULTI_SZ) = "C:\pagefile.sys 4096 8192"

An empty PagingFiles value disables pagefile entirely. The file is removed 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 fragments of PE images, registry hives, browser SQLite, MFT records.
Plaintext credentials that paged out of LSASS.
Crash dumps in MEMORY.DMP.

If you are hardening a fleet for incident response readiness, the right call is to keep pagefile, encrypt it with EncryptPagingFile, and combine with BitLocker. Not to disable.

If you are hardening against incident occurrence (less data on disk for an attacker or thief to take), and you accept the operational cost, disabling is defensible. Also explicitly turn off crash dumps in that case, or you will end up with a confusing failure mode where BSODs leave no diagnostics.

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 rating of a consumer NVMe is hundreds of TB. You will not exceed it by leaving pagefile on. The Windows installer has been making this choice since 2010 and the catastrophic SSD failures have not happened.

"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 to 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 between partitions on the same physical drive does nothing useful. Hosts with adequate RAM rarely page in steady state anyway.

"Deleting pagefile.sys frees the disk space immediately."

The file is locked by the kernel while Windows is running. You can delete the configuration, but the file removal happens on the next boot. Anyone who insists they del'd it from an admin prompt while Windows was up either rebooted in between or did not actually delete what they think they deleted.