Why You Shouldn’t Disable pagefile.sys in Windows 10 & 11: Commit Limits, Crashes and Safe Settings

The pitch is seductive in its simplicity: solid-state drives and hard disks are slower than system RAM, and pagefile.sys eats up precious gigabytes on your main drive while generating background write operations. Therefore, if you have 16 GB, 24 GB, or 32 GB of physical memory, why not turn off virtual memory altogether and force Windows to keep everything in blistering-fast RAM?

In an October 14, 2026 cautionary column for XDA Developers, writer Kazim Alvi detailed what happened when he decided to test that exact theory on his own machine. While the system ran smoothly for the first few hours, opening a handful of applications and several active browser tabs quickly triggered unexpected tab crashes and prevented new apps from launching—even though Task Manager reported physical memory usage well within a normal range.

Why does a PC with plenty of free physical RAM start choking the moment pagefile.sys is taken away? When we look under the hood at Microsoft’s official memory-management architecture, the answer has everything to do with how Windows promises memory long before it actually uses it.

The "Plenty of Free RAM" Trap: Commit Charge vs. Physical Memory​

The single biggest misconception driving the no-page-file myth is the idea that pagefile.sys is nothing more than an emergency overflow tank that sits completely idle until your physical RAM hits 100% capacity.

In reality, Windows manages memory through a reservation system governed by two critical metrics defined in Microsoft Learn’s Windows Client documentation: the system commit limit and the system commit charge.

• System Commit Limit: The absolute ceiling of virtual memory the operating system can guarantee to back. Microsoft defines this limit as the sum of physical memory (RAM) plus the combined size of all active page files. If you disable the page file entirely, your system commit limit drops to slightly less than your installed physical RAM.
• System Commit Charge: The total amount of virtual memory that Windows has "promised" (committed) to all running processes and the operating system itself.

Here is the catch that trips up weekend tweakers: when modern applications launch, they frequently ask Windows to commit far more virtual memory than they intend to occupy in physical RAM right at that second. Because Windows is making a strict legal promise that this memory will be available if the application suddenly demands it, the operating system checks that request against the commit limit, not against your free physical RAM.

If your system commit charge hits the system commit limit—even while gigabytes of physical RAM are sitting completely empty—Windows refuses new memory allocation requests. As Microsoft Learn explicitly warns, reaching the commit limit means processes may fail to obtain committed memory, resulting in application freezes, crashes, launch failures, and system instability.

That explains the exact paradox Alvi described in XDA Developers: looking at the basic Memory graph in Task Manager and seeing "reasonable" RAM utilization while browser tabs crash and apps refuse to open. To see what is actually choking the system, you have to open Task Manager’s Performance tab, click Memory, and look at the Committed readout (which displays Committed Bytes / Commit Limit), or monitor the \Memory\Committed Bytes and \Memory\Commit Limit counters in Performance Monitor.

Summary: Memory Management Realities​

• Disabling pagefile.sys shrinks your system commit limit to slightly below your physical RAM size.
• Apps can exhaust your commit limit through memory reservations even when physical RAM appears half-empty.
• Hitting the commit ceiling causes immediate allocation failures, browser tab crashes, and app launch errors.

What pagefile.sys Actually Does All Day​

Beyond extending the commit limit, Microsoft Learn outlines three core operational roles for the page file that have nothing to do with "running out of RAM":

1. Evicting Modified, Inactive Pages: Not all memory is created equal. Code backed by files already on your drive (like .exe and .dll files) does not need to be written to the page file; if Windows needs that RAM back, it simply discards the code pages and re-reads the .exe from disk later. However, modified data that does not exist as a saved file on disk (such as unsaved application states or private process heaps) must be backed somewhere. The page file allows Windows to move infrequently accessed modified pages out of physical RAM so that fast DRAM can be repurposed for active workloads and disk caching. Without a page file, stale modified data is locked in physical RAM indefinitely.
2. Backing System Crash Dumps (Memory.dmp): When Windows encounters a bug check (Blue Screen of Death / Stop error), it writes diagnostic memory data to disk so administrators or troubleshooting tools can identify the faulty driver or hardware. According to Microsoft Learn, unless a system administrator has explicitly configured a separate dedicated dump file, Windows relies on pagefile.sys to stage that crash dump. If the page file is disabled or smaller than the required dump size, Windows cannot record the crash dump.
3. Hard Application and Service Dependencies: Microsoft notes that certain workloads and services explicitly expect a page file to exist. On the enterprise side, components using the Extensible Storage Engine (ESENT/ESE)—such as Windows Server domain controllers, DFS Replication, and Certificate servers—rely on page-file-related memory transition counters to release database cache memory properly. On the desktop side, heavy creative suites, modern games, and developer compilers routinely trigger sudden commit spikes that assume a page file is backing them up.

Debunking the SSD Lifespan and Speed Myths​

The two secondary arguments for disabling the page file—improving system speed and saving your SSD from premature death—fare no better under scrutiny.

First, turning off the page file does not make your storage drive faster or add a single megabyte of physical RAM. In fact, by forcing infrequently used modified pages to stay pinned in physical RAM, you leave less physical memory available for the Windows standby cache to pre-load frequently used files and applications.

Second, readers often see disk activity or "hard page faults" and assume pagefile.sys is thrashing their SSD. Microsoft Learn clarifies that hard page faults (\Memory\Page/sec and \Memory\Page Reads/sec) occur whenever Windows retrieves data from disk—including standard .dll files, .exe binaries, and memory-mapped files. Hard page faults are a completely normal function of the operating system, not proof that pagefile.sys is wearing out your drive. As Alvi rightly pointed out in his XDA Developers piece, modern SSDs are engineered to handle routine operating system reads and writes without breaking a sweat, and there are far safer ways to reclaim disk space or care for a drive than amputating virtual memory.

The Sizing Debate: Automatic vs. Custom Page Files​

If disabling the page file is a bad idea, how big should it be?

In his XDA Developers article, Alvi noted that on his 24 GB RAM machine, Windows had automatically reserved 1,536 MB (1.5 GB) for virtual memory. For users running low on storage who want to manually cap the file rather than let it grow, he suggested setting a custom size in the 4 GB to 8 GB range for PCs with 16 GB to 32 GB of RAM, arguing that the old-school formula of setting the Initial and Maximum sizes to 1.5x and 3x physical RAM is overkill on modern high-RAM systems.

While a 4 GB to 8 GB custom cap may work as a casual rule of thumb on a lightly loaded desktop, Microsoft’s official engineering guidance explicitly rejects any universal fixed number or flat RAM multiplier. According to Microsoft Learn, appropriate page file sizing cannot be generalized—even between two identical PCs—because it depends entirely on two system-specific variables:

1. Your peak system commit charge under your actual workload.
2. Your system crash dump settings.

The Rare Exception Where Manual Sizing Beats Automatic​

Interestingly, while leaving Windows on Automatically manage paging file size for all drives is the safest default for 99% of users—and is even listed by Microsoft Support as a standard verification step when troubleshooting stubborn File Explorer startup issues—there is one verified edge case where automatic management stumbles.

In Microsoft Learn troubleshooting article KB4055223 (Memory allocation errors can be caused by slow page file growth), Microsoft confirms a scenario in Windows 10 and Windows 11 where applications that allocate memory rapidly and frequently—such as the Microsoft Visual C++ compiler (cl.exe) throwing C1076 or C3859 fatal heap errors—can experience random "out-of-memory" failures.

Why? Because an automatically managed page file starts small (such as the 1,536 MB reservation Alvi observed) and grows on demand when the commit charge crosses 90% of the commit limit. If a heavy workload requests a massive block of committed memory faster than the storage I/O stack and file-system filters can expand pagefile.sys on disk, the allocation times out and fails. For those specific power-user workloads, Microsoft recommends setting a custom Initial size large enough that Windows never has to pause and grow the file mid-task.

How to Properly Check and Configure Virtual Memory in Windows 10 and 11​

If you previously followed an optimization guide and disabled your page file—or if you want to inspect your peak commit charge before setting a sensible custom size—follow this evidence-backed procedure:

Step 1: Check Your Actual Commit Limit and Peak Usage​

1. Press Ctrl + Shift + Esc to open Task Manager.
2. Click the Performance tab and select Memory.
3. Look at the Committed metric at the bottom. The first number is your current Commit Charge; the second number (after the slash) is your Commit Limit.
4. Observe this number during your heaviest daily workload (gaming, video editing, or running dozens of browser tabs). If you ever set a custom page file size, your Physical RAM + Custom Page File Size must comfortably exceed your peak committed bytes.

Step 2: Restore or Adjust Page File Settings​

1. Open the Start menu, search for View advanced system settings, and open it (or press Win + R, type sysdm.cpl, and press Enter).
2. On the Advanced tab, under the Performance section, click Settings.
3. In the Performance Options window, switch to the Advanced tab and click Change under Virtual memory.
4. For the safest everyday setup: Check the box labeled Automatically manage paging file size for all drives, click OK, apply your changes, and restart your PC.
5. If you must set a manual size: Uncheck Automatically manage paging file size for all drives, select your drive, choose Custom size, enter an Initial size (MB) and Maximum size (MB) that safely cover your observed peak commit charge and crash-dump needs, click Set, select OK, and restart your PC.

Summary: Actionable Takeaways for Windows Users​

• Leave it on Automatic: Unless you are diagnosing a specific allocation latency issue (like KB4055223) or managing an ultra-cramped boot drive, let Windows manage pagefile.sys automatically.
• Never set it to zero: Disabling the page file does not force "faster RAM usage"—it simply amputates your commit limit and breaks crash dumps.
• Reclaim storage safely: If your SSD is full, use Windows Storage Sense, run Disk Cleanup, uninstall bloated apps, or shrink hiberfil.sys if you never use Hibernation—just leave pagefile.sys alone to do its job.