About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
The page file is one of the oldest settings on a Windows server, and one of the most argued about. Some administrators set it to 1.5 times the memory. Some remove it entirely on servers with plenty of RAM. Some never touch it. Microsoft's current guidance is clear that no fixed rule works: page file sizing is also unique to each system and can't be generalized.
What Microsoft does give is a method. The page file has two jobs: extend how much memory the server can promise to programs, and hold a crash dump if the server stops. Size it for whichever of those needs more space, measure, and leave it system-managed unless you have a reason not to.
Why it matters
When a Windows server runs out of memory it can promise, programs cannot get more. Microsoft warns that when this limit is reached, the system and processes might not get committed memory. This condition can cause freezing, crashing, and other malfunctions. On an application server that can mean a database engine, an application service and every Remote Desktop session failing at once, at the busiest time of the month.
The second risk is quieter. If the server crashes with a blue screen and the page file is too small or missing, no crash dump is written unless a correctly configured, sufficiently sized dedicated dump file supplies the required backing. Without a dump, diagnosing a recurring crash can be much harder.
How it works
The commit limit
Committed memory is memory for which Windows promises backing storage from RAM and paging files. Merely reserving virtual address space is different: it reserves addresses without allocating that backing. Microsoft's VirtualAlloc reference distinguishes MEM_RESERVE from MEM_COMMIT, which charges the commitment budget even before the program touches the pages. The total committed across the server is the commit charge. The maximum it can reach is the commit limit. Microsoft defines it: The system commit memory limit is the sum of physical memory and all page files combined.
That is why the page file matters even on a server with plenty of RAM. Programs often commit memory they never touch. That memory still counts against the limit. Without a page file, Microsoft notes, the system commit limit is slightly less than the physical memory that is installed. A server with 32 GB of RAM and no page file can promise a little under 32 GB in total, however much of it is actually in use.
What to measure
Microsoft names the counters to watch. The commit charge and limit can be measured on the Performance tab in Task Manager or by using the "\Memory\Committed Bytes" and "\Memory\Commit Limit" performance counters. A third counter, % Committed Bytes In Use, is the ratio between them.
What matters is the peak, not the average. Microsoft's sizing guidance says page file size depends on the peak usage or expected peak usage of the system commit charge. For a business application, the peak is usually month-end, payroll day or a large report run, not a quiet Tuesday. Record committed bytes across at least one full business cycle before deciding on a size.
Crash dumps need space
When Windows stops with a fatal error, it writes memory information to a dump file, backed by a suitably sized page file or a configured dedicated dump file. Microsoft's sizing guidance says that a page file or a dedicated dump file must exist and be large enough to back up the system crash dump setting. Otherwise, a system memory dump file isn't created.
How much space depends on the dump type:
| Dump setting | Backing-space guidance and limits |
|---|---|
| Small memory dump | Sources differ: the sizing page says 1 MB; the Server dump-options page says at least 2 MB on the boot volume. Do not select a minimum without exact-version validation |
| Kernel memory dump | Depends on kernel memory use |
| Automatic memory dump (the default) | Depends on kernel memory use |
| Complete memory dump | Size of RAM plus 257 MB |
The small-dump figures above come from the sizing page and the Windows Server dump-options page. Their discrepancy remains unresolved; this article does not prescribe either minimum. Confirm the dump type, backing file and exact Server version with vendor guidance and an authorised isolated validation before relying on a minimal configuration.
The automatic setting adjusts over time. Microsoft explains that it initially selects a small paging file size. Then, If the system crashes again within four weeks, the Automatic memory dump feature sets the page file size as either the RAM size or 32 GB, whichever is smaller.
For most investigations a kernel dump is enough. Microsoft's dump options page says of it: For most purposes, this dump file is the most useful. A complete dump may be requested by Microsoft or a vendor for a specific problem. Note also that a complete dump may contain data from processes that were running when the memory dump was collected. On a server holding business data, treat dump files as sensitive.
If you want crash dumps but not paging, Windows supports a dedicated dump file. It backs crash dumps only: it does not increase the commit limit and cannot substitute for paging capacity. Product requirements and peak commitment still have to be satisfied. Microsoft says: We recommend that you use a dedicated dump file if you want a system crash dump but you don't want a page file.
System-managed page files grow by themselves
By default, Windows manages the page file size. Microsoft describes how it grows: when the system commit charge is more than 90 percent of the system commit limit, the page file is increased to back it. The page's minimum/maximum table is explicitly for Windows 10 and Windows 11: it lists three times RAM or 4 GB, whichever is larger, capped at one-eighth of the volume, but allows growth to within 1 GB of free space when required for crash dumps. Do not turn that client-labelled table into an absolute Windows Server disk-use limit. The general commit and dump considerations apply to Server, but check configured limits and observed growth on the exact Server build, and reserve disk space for both workload peaks and the selected dump. On a small system drive, growth can still fail for lack of space.
Some server roles need a page file
Microsoft lists Windows Server roles that need a page file regardless of how much RAM is installed, including Windows Server domain controllers (DCs), DFS Replication servers and certificate servers. Their database engine relies on page file behaviour to release memory under pressure. Check the documentation of any other product on the server too. Microsoft's general advice is: Some products or services require a page file for various reasons. For specific information, check the product documentation.
What to choose and why
For most application servers: leave it system-managed
Unless you have measured a reason to change it, leave the page file system-managed on the system drive, and make sure that drive has room for it to grow. That gives Windows room to raise the commit limit under unexpected load and to keep a dump after a crash.
When to set a fixed size
A fixed size makes sense when the system drive is small, when you want predictable disk use, or when you have measured the peak. A reasonable method:
- Record peak \Memory\Committed Bytes over a full business cycle.
- Work out a target commit limit: that peak plus a margin justified by forecast workload growth and unexpected demand. For example, 25 per cent could be an illustrative planning assumption, not a Microsoft recommendation or a universal industry norm.
- Subtract installed RAM to estimate the paging capacity needed for commitment. Verify the actual resulting Commit Limit and headroom under representative peak load; the effective limit is not an exact promise based only on installed RAM.
- Separately check the selected dump's backing-space requirement. If the page file supports both uses, size for the larger requirement; a dedicated dump file covers only the dump requirement. Validate dump capability on the exact version in an authorised isolated test before relying on it.
If step 3 is negative, the arithmetic suggests RAM may cover the planned commitment target. Confirm the measured limit and product or server-role page-file requirements before reducing paging capacity; dump backing still needs its own provision.
Do not remove the page file to "save disk"
Removing the page file lowers the commit limit to slightly under the RAM size and prevents crash dumps unless a correctly configured, sufficiently sized dedicated dump file supplies their backing. Those consequences may only become obvious at peak load or during a crash. If disk space is the constraint, assess moving paging capacity to a suitable volume while separately checking the dump configuration. A dedicated dump file can meet the dump requirement, but does not replace any paging capacity the workload or server role requires.
Watch for real paging, not just page file size
A large page file does not mean the server is paging heavily. Paging that hurts performance shows up as sustained hard page faults and slow disk response on the page file's volume. Microsoft's guidance is to monitor the disk performance of the logical disks that host a page file in correlation with these counters. If the server is genuinely short of RAM, add RAM. A bigger page file prevents failures but does not make a memory-starved server fast.
Risks and limits
- Microsoft's sizing pages extend general commit and dump considerations to Windows Server, but label their system-managed minimum/maximum table Windows 10 and Windows 11. Validate exact Server build behaviour rather than adopting that table as a Server guarantee.
- One-eighth of a volume is not an unconditional disk-space ceiling. The client table allows growth to within 1 GB of free space for crash-dump requirements; Server free-space planning must use verified configuration and observed demand.
- SQL Server, Exchange and some other products have their own memory guidance. A server running SQL Server needs its memory cap set correctly as well; that is a separate setting.
- Changing the dump type or page file requires a restart. Microsoft notes that you must restart Windows for dump settings to take effect.
- No commands are given. Page file and dump settings are changed in System Properties. Test on a non-production server first.
Sources
Opened 14 November 2026.
- Microsoft Learn: How to determine the appropriate page file size for 64-bit versions of Windows, dated 2026-02-12.
- Microsoft Learn: Introduction to the page file, dated 2026-02-12.
- Microsoft Learn: VirtualAlloc, MEM_RESERVE versus MEM_COMMIT, displayed date 2024-02-05.
- Microsoft Learn: Memory dump file options, dated 2026-02-12, updated 2026-06-11.
Related service: Managed support.
Related future topics
- Reading a kernel crash dump: what an administrator can learn before calling the vendor.
- SQL Server memory settings on a hosted virtual machine.
- Sizing a business application server from measurements.
Learning notes
- The commit limit is RAM plus all page files; reaching it causes freezes and crashes.
- Size the page file from the peak commit charge over a business cycle, not from a ratio of RAM.
- A crash dump needs page file or dedicated dump file space, or no dump is written.
- Domain controllers, DFS Replication and certificate servers need a page file whatever their RAM.
- Leave the page file system-managed unless you have measured a reason to change it.
This article was originally published on .