What Is pagefile.sys? Should You Delete or Resize It

Windows Explorer shows a hidden 12 GB file on C: and the disk-cleanup instinct kicks in. The file is Windows memory management doing its job, and its size follows rules Microsoft publishes rather than a bug. This guide answers the question behind the search, what is pagefile.sys, and then the practical ones: why it grows, when to resize or move it, and why deleting it costs more than the space it frees.

What pagefile.sys Is

pagefile.sys is the Windows page file: a hidden system file, normally on the root of C:, that the memory manager uses as an overflow for RAM. Microsoft's introduction to page files (updated February 2026) describes it as a physical extension of RAM. Windows moves modified pages that haven't been touched in a while out to the file, so physical memory stays free for the pages that are in use.

Two numbers explain almost everything about it. The commit charge is the memory every process has been promised. The commit limit is RAM plus all page files combined. When the charge reaches the limit, allocations start failing, and Microsoft's words for the result are "freezing, crashing, and other malfunctions." The page file exists to keep the limit above the charge.

It has two siblings on the same drive. swapfile.sys is a small file that holds suspended Store and packaged apps. hiberfil.sys holds the RAM snapshot for hibernation and Fast Startup, and it is often the bigger of the three. Deleting one doesn't touch the others, so check which file is eating the disk before changing anything.

The page file also backs the crash dump. When Windows hits a stop error, it writes memory out through the page file on the boot volume before the reboot. That is where the Memory.dmp behind every blue screen analysis comes from. No page file on C:, no dump.

Why It Gets So Big

The size follows rules, not whims. By default the file is system managed, and Microsoft's page file sizing article (February 2026) sets the bounds. The starting size varies with RAM and crash dump settings, up to RAM divided by 8, capped at 32 GB. When the commit charge passes 90% of the commit limit, Windows grows the file, up to three times RAM or 4 GB, whichever is larger, and never more than one eighth of the volume.

So a laptop with 16 GB of RAM can carry a 2 GB page file for months and then show 48 GB after one week of heavy use. Nothing is wrong. Something asked for memory, Windows made room, and it kept the room.

Crashes add a second rule. The default dump type is Automatic memory dump, which starts small. If the machine crashes a second time within four weeks, Windows resets the page file to the size of RAM or 32 GB, whichever is smaller, so the next dump has space. The timestamp sits in the registry under CrashControl\LastCrashTime, and the larger size stays for four weeks before it shrinks again.

That is the usual answer to "pagefile.sys huge": one of two triggers fired. Either the commit charge ran hot, which points at the workload, or the machine blue-screened twice, which points at a driver. A memory diagnostic run is the next step for the second case, not a smaller page file.

Can You Delete pagefile.sys?

Not while Windows is running. The kernel holds the file open, and Explorer refuses. The only way to remove it is to turn the page file off: System Properties, Advanced, Performance Settings, Advanced, Virtual memory, then "No paging file" and a reboot. The file disappears on the next start.

What you give up is less visible than the free space. Microsoft's memory dump options page (February 2026) states the minimums: a complete memory dump needs a page file of RAM plus 257 MB on a local volume, a kernel dump needs enough for kernel memory, and even the small dump needs a page file on the boot volume. Turn the file off and the next blue screen leaves nothing to analyze.

The second cost is the commit limit. Without a page file, the limit is slightly less than installed RAM. The machine can have gigabytes of physical memory free and still refuse an allocation, because commit is about promises, not use. The error that follows is "The paging file is too small for this operation to complete", with Event ID 2004 from the Resource Exhaustion Detector in the System log.

An r/sysadmin post from July 2025 shows the shape of it. A domain controller with 4 GB of RAM fell over mid-update, Defender for Endpoint alone had 12.7 GB committed, and the page file sat on an 8 GB D: partition. The top reply corrected one detail, an initial and maximum size of 0 in WMI means system managed rather than zero, but the box still had single-digit gigabytes to page into:

Ask Leo's answer to the delete question lands in the same place, and the video is short enough to send to the person asking:

If disk space is the problem, trim hiberfil.sys first (powercfg /h off removes it entirely), then move or cap the page file. Deleting it is the last resort, and on some servers it isn't an option at all: Microsoft lists domain controllers, DFS Replication servers, certificate servers and ADAM/LDS servers as requiring a page file, because their ESENT database cache depends on one to release memory.

When to Resize or Move It

Microsoft's own position is that sizing "can't be generalized": the right size depends on the peak commit charge and the dump setting of that specific machine. Three counters settle it. In Performance Monitor, compare \Memory\Committed Bytes against \Memory\Commit Limit at peak. If the charge sits near the limit, the page file is too small or the box needs RAM. Then check \Paging File(*)% Usage and \Memory\Modified Page List Bytes: when the file is over 90% used and the modified list holds a lot of memory, add space.

A fixed size is fine when you know the peak. Set initial and maximum to the same value so the file never grows mid-day, and keep it at or above the dump minimum. For the common case, Microsoft's answer is still the default: leave it system managed and let the rules above do the work.

Moving it to another volume is where the mistake usually hides. The dump is written through the page file on the boot volume, so if the whole file moves to D:, you need a dedicated dump file on C: (a page file that is never used for paging) or you lose crash dumps. Microsoft recommends exactly that combination when you want a dump but not a page file on C:. Moving it to a temporary disk on a cloud VM, as the DC above did, adds the risk that the disk is smaller than the file wants to be.

The April 2026 r/sysadmin thread on VM page files is a good temperature check. Reply after reply had left the setting alone for years, and the detail worth keeping is that Windows registers the page file in the FilesNotToBackup key, so backup software skips it without an extra exclusion:

How to Check It Across a Fleet

One machine is a dialog box. A fleet is a script. Two CIM classes give the whole picture: Win32_PageFileSetting holds the configured sizes (0 and 0 means system managed), and Win32_PageFileUsage reports the current size and peak use.

powershell
Get-CimInstance Win32_PageFileSetting | Select-Object Name, InitialSize, MaximumSize
Get-CimInstance Win32_PageFileUsage | Select-Object Name, AllocatedBaseSize, CurrentUsage, PeakUsage
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' | Select-Object CrashDumpEnabled, LastCrashTime

Run it across the estate and three groups fall out: machines with the file disabled, machines whose peak use sits near the allocated size, and machines with a LastCrashTime in the last four weeks, which are the ones with a driver problem to find. OpenFrame runs a script like this across a client's devices and collects the output per machine, so the three lists come back without a remote session to each box. The PowerShell commands guide covers the cmdlets used here.

CrashDumpEnabled decodes as 7 for Automatic (the default), 2 for kernel, 1 for complete, 3 for small and 0 for none. A fleet that shows 0 has had its dumps switched off somewhere along the way, usually by a disk-space script, and that is worth reversing before the next blue screen.

Short Version

pagefile.sys is the overflow for RAM and the landing zone for crash dumps. It is big because Windows grew it after memory pressure or a crash, and both are worth knowing about. Resize it when the counters say so, move it only with a dedicated dump file left behind on C:, and remove hiberfil.sys before you touch it. The next read is how to read a blue screen, which is the thing the file is protecting.

FAQ

Is it safe to delete pagefile.sys?

Not directly, and not usually. Windows holds the file open, so it can only be removed by disabling the page file and rebooting. That removes crash dumps and lowers the commit limit to just under installed RAM, which is why Microsoft's sizing guidance assumes a page file or a dedicated dump file is present.

Why is pagefile.sys 16 GB, 32 GB or larger?

System-managed page files grow when the commit charge passes 90% of the commit limit, up to three times RAM or 4 GB, whichever is larger. After a second crash within four weeks, Windows also resets the file to the size of RAM (capped at 32 GB) so a dump fits. Both are normal; the second means a driver is worth finding.

What size should the page file be?

Microsoft says it can't be generalized. Keep it at least the minimum for your dump setting (RAM plus 257 MB for a complete dump) and large enough that Committed Bytes never reaches Commit Limit at peak. For the common case, system managed is the answer.

Does the page file wear out an SSD?

Windows places the page file on the boot volume by default whatever the drive type, and modern SSDs handle its writes without special treatment. Heavy page file traffic, hundreds of hard faults a second in Performance Monitor, is a sign the machine needs RAM rather than a different drive.