pagefile.sys from a Windows boot SSD to a second drive is a real, supported configuration change—not a universally beneficial optimization. It can be sensible on a carefully understood PC, especially where the boot volume is constrained and a suitable secondary drive has ample free space. But the usual promise that the boot SSD will simply stop doing needless work leaves out the questions that decide whether the change is useful, neutral, or harmful: how much committed memory the machine actually reaches, whether paging I/O is occurring under pressure, whether a disk is saturated, and which crash dump Windows is expected to capture.
The key point for Windows users is that installed RAM alone does not answer those questions. A computer with 32 GB of memory can still have an important page-file requirement, while a computer with less memory may never create enough paging activity for relocating the file to matter. Treat page-file placement as a measured configuration decision, not a default SSD-maintenance ritual.
What the Windows page file actually does
The page file has three important roles in Windows memory management.
First, it can support the eviction of modified memory pages that have not been accessed recently. Second, it contributes to the system's commit limit: the maximum amount of memory Windows can commit for the system and applications. Microsoft describes that limit as the combination of physical memory and all page files. Third, a paging file can support crash-dump collection after a serious system failure.
That second role is the one most often missed in casual advice. The fact that a PC has abundant physical RAM does not mean that applications can safely commit unlimited memory. If the system's commit charge reaches its commit limit, Windows and applications may be unable to obtain further committed memory. The practical symptoms can include application failures, instability, freezes, or crashes.
This is why disabling the page file—or relocating all of it without considering capacity—is not just a storage preference. It changes the headroom available to committed memory. It can also change what diagnostic information Windows is able to preserve when the system crashes.
Why a second drive is not automatically faster
The intuition behind moving the file is straightforward: if Windows has to use the page file, putting its I/O on a different drive should leave the boot disk freer to handle Windows and application activity. That can be a reasonable hypothesis, but it is not proof of a benefit.
Microsoft's guidance makes the limiting condition clear: page-file placement between fast and slow storage matters when the page file is frequently accessed and the disk hosting it is overwhelmed. Without those conditions, the move may have no material effect. There is no supplied before-and-after evidence showing that a particular boot SSD had substantial page-file traffic, that it was saturated, or that it became less busy after relocation.
Drive letters also reveal less than many users assume. A secondary disk might have different latency, random-I/O performance, available space, reliability characteristics, or a shared hardware bottleneck. Those details are unknown in a generic two-drive recommendation. Therefore, the claim that a second physical drive inherently provides useful separation is too broad.
A move from one SSD to another might be an acceptable experiment on a specific system, but the dossier does not establish a universal performance result for any particular interface pairing. Likewise, it does not establish that moving the file to a hard disk is always inadvisable. What is established is narrower and more useful: page-file location should be evaluated against actual access frequency and storage pressure, rather than a rule based solely on the existence of a spare drive.
The crash-dump trade-off can be decisive
The most significant consequence of removing every paging file from the boot volume is diagnostic, not day-to-day speed.
Microsoft states that capturing a complete memory dump requires an adequately sized paging file on the boot volume, even when the final dump is configured to be written to another local disk. In other words, placing a page file only on a secondary drive can prevent the collection of a complete dump after a system crash.
For many PCs, a complete dump may not be a priority. For others—development workstations, machines being investigated for repeated blue screens, or systems with difficult driver and stability problems—it can be highly valuable. A complete dump preserves far more diagnostic state than a configuration that cannot capture one. The appropriate page-file design therefore depends partly on the dump type Windows is configured to use and on how important post-crash investigation is for that PC.
This does not mean every system must retain a large page file on its OS drive. It means the move is not consequence-free. Before removing the boot-volume file, users should identify their current crash-dump setting and decide whether losing complete-dump capability is acceptable. The supplied record does not reveal the crash-dump configuration of any specific example system, so no conclusion can be made about whether its relocation preserved the required diagnostic coverage.
Why RAM capacity is a poor universal rule
Advice often uses a fixed RAM threshold—such as 32 GB—to suggest that page-file relocation is unlikely to matter. That rule is attractive because it is simple, but it is not reliable.
Microsoft says page-file sizing depends on the system's peak committed-memory use and crash-dump requirements. Both are unique to the machine. RAM capacity contributes to the available commit limit, but it does not disclose the peak commitment created by the applications, workloads, background tasks, or virtualized environments a user runs.
A lightly used PC with ample RAM might show little page-file activity, making a relocation mostly irrelevant. Another PC with the same installed RAM could run workloads that approach its commit limit, making page-file capacity important. Neither case can be inferred solely from a number printed on a memory module.
The better question is not, “Do I have enough RAM to move the page file?” It is, “What is my peak committed-memory demand, what is my current commit headroom, and what dump capability do I require?” That reframes the decision around Windows' actual constraints instead of a broad hardware stereotype.
System-managed does not mean unlimited
Leaving a page file system-managed is often presented as a way to avoid manual sizing problems. It remains a useful option, but it has boundaries.
Microsoft documents that a system-managed page file can grow to three times installed RAM or 4 GB, whichever is larger. However, that growth is not an unconditional reserve that Windows creates at will. Automatic expansion occurs when the system commit charge reaches 90% of the commit limit, requires adequate free space, and is limited in relation to the volume hosting the page file.
Those conditions matter when selecting a target drive. A large-looking secondary volume that is nearly full is not necessarily a dependable place to rely on automatic expansion. Conversely, moving the page file merely to free some space on the system drive can be reasonable if the target volume has sufficient capacity and the change does not undermine the desired crash-dump configuration.
Manual page-file sizes have their own risk: a size that seems generous during ordinary use can still prove inadequate during an exceptional workload or a crash scenario. The dossier supports no universal custom-size formula, so users should not substitute a generic fixed number for the system's observed needs.
What to check before changing anything
A sensible page-file move starts with observation.
First, examine committed-memory usage over the workloads that matter: the applications that cause the highest memory demand, not just an idle desktop. The goal is to understand how close the system gets to its commit limit and whether there is comfortable headroom.
Second, examine page-file use and page-write or page-output activity alongside disk activity. If the boot drive is not handling meaningful page-file I/O or is not saturated, there is little evidence that moving pagefile.sys will improve responsiveness. Also avoid treating hard faults as automatic proof that the page file is being actively used. The useful test is whether page-file activity and storage saturation occur together in the workload where a performance problem is visible.
Third, verify the free space and suitability of the prospective target volume. Because automatic expansion needs free space and is bounded by the hosting volume, this is a reliability requirement, not a cosmetic storage check.
Finally, inspect the Windows crash-dump setting. If complete dumps are required, ensure the boot volume retains an adequately sized paging file. This requirement can outweigh any speculative desire to shift background I/O elsewhere.
How Windows supports the relocation
Windows provides a native graphical method through its Virtual Memory settings. The documented pattern is to select the OS disk and choose No paging file, then select the target drive and choose System managed size. Applying the configuration can require a restart.
That is the mechanics, not a recommendation to make the change blindly. A cautious approach is to record the existing configuration and dump setting first, make one change at a time, then restart and test the workloads that motivated the change. Watch committed-memory headroom, page-file activity, and disk behavior afterward rather than assuming that a quieter-looking boot disk represents a meaningful overall gain.
If stability issues, commitment warnings, or unexpected application failures appear after the change, the prior configuration is an important fallback. If crash diagnosis is the goal, restoring or retaining an appropriately sized boot-volume page file may be necessary for complete-dump capture.
A practical decision framework
Relocation is most defensible when it solves a demonstrated problem: the boot volume lacks space, Windows is generating significant page-file I/O during a real workload, the hosting disk is overwhelmed, and the secondary volume is an appropriate, sufficiently free target. Even then, crash-dump requirements must be designed into the configuration.
It is less compelling when the only rationale is that a PC has two drives, a large amount of RAM, or a desire to reduce alleged SSD “work.” No evidence in the supplied record shows that merely relocating the page file makes a boot SSD perform less unnecessary work, because it does not establish that the work was occurring, unnecessary, or a bottleneck in the first place.
For typical Windows users, the conservative conclusion is straightforward: retain a system-managed configuration unless measurements or space constraints identify a reason to change it. If you do relocate pagefile.sys, validate commit capacity, storage headroom, observed I/O, and crash-dump consequences. The page file is not obsolete clutter on an SSD; it is part of Windows' memory and recovery design, and its best location depends on the behavior of the individual machine.