The Ubiquitous Pagefile

Windows works with virtual memory - the sum of physical RAM installed and the current size of the pagefile(s) in use.

The Memory Manager is constantly checking that the working sets of the processes on the system, the kernel and paged pool allocations have been recently used - if they have not then they can be considered as taking up space that could be used by something else.

The "something else" could be a request for dynamic memory from a driver or a process, or it could be Superfetch preloading file sections based on usage patterns - increasing the memory used by the system cache.

This is in an effort to reduce the intermittent disk I/Os when memory is suddenly needed (paging on demand) and to use idle time to have data that might be requested (including .EXE, .DLL, .SYS images) already ready for provision by the Cache Manager.

Least Recently Used (LRU) pages consuming physical memory pages go to the pagefile, by default this is C:\PAGEFILE.SYS and is dynamically sized (also reset to the minimum size at system startup).

There have been many recommendations about the location and size of the pagefile(s), and even questions about if it should be present at all.

Size... is it important?

The classic "pagefile should be 1.5x the amount of physical RAM installed" statement is from many years ago and makes no sense given the amount of memory available in machines today (even workstations) - in fact the more RAM you have, the less need you have for the pagefile to be huge.

However, this is still the default "recommendation" seen from within the virtual memory configuration in Windows - as it can't determine what you are going to use the system for in order to calculate the most appropriate size for the pagefile.

Location, location, location

It is argued that moving the pagefile to a separate physical disk, or placing onto a striped RAID set will dramatically improve performance.

In my opinion, if you notice a significant change by relocating the pagefile this way, then you are using that pagefile way more than you ought to be, implying you need more RAM.

Firstly, if the pagefile is being accessed due to a demand for more physical memory by a running process, then the disk I/O is unavoidable and it makes no difference where it is located.

If the demand for physical memory comes from a disk read operation, then there will be a slight improvement by having the disk read and paging operations able to work concurrently because they are on separate devices (ideally separate channels too).
However, this performance gain will be for the duration of the disk read, it won't affect the performance of the applications or OS (unless the application is designed to do intensive disk I/O, in which case it will be down to its design to utilize its memory correctly - such as bypassing the cache if it is just scanning data).

"I have loads of RAM - can I run without any pagefile at all?"

Windows can operate without a pagefile configured, but then virtual memory == physical memory so once it is all committed (and not by the cache) then you will run into problems.

Also, some applications will check for the presence of a pagefile and refuse to launch without one.

"What is the downside of not having a pagefile, or changing the defaults?"

If your system bugchecks, you NEED:
1. a pagefile on the boot drive with a minimum size at least as large as RAM+50MB
2. the same amount of free disk space on the boot drive

If you don't have this, you get no dump file generated.

The bugcheck procedure is as follows:

1. A bugcheck occurs (KeBugCheckEx is invoked)
> This could be a critical process terminating, a memory access violation in kernel mode, an NMI button press, etc.

2. Processor IRQL is raised to the highest level (31 on x86, 15 on x64)
> This prevents every thread from executing and masks out all other possible interrupts, bar NMIs (hence disabling ASR is essential)

3. The dump settings are read from the registry to determine the level of debugging information to attempt to write
> HKLM\System\CurrentControlSet\Control\CrashControl\CrashDumpEnabled (REG_DWORD)

4. Disk subsystem drivers are bypassed and the pagefile.sys has the relevant populated physical pages written to it
> CrashDumpEnabled==1 - complete memory dump this is every valid page in RAM, so includes user-mode
> CrashDumpEnabled==2 - kernel dump, just pages mapped by the kernel
> This is why you need the boot volume pagefile minimum size to be large enough to hold all the relevant valid pages, and a little extra for a header

[As the disk is being written to without any optimized drivers, this process can take a while and if it is interrupted, the dump is corrupted]

5. A registry value (REG_DWORD) is set
> This records the fact that a bugcheck occurred so that it can be handled during the next startup

6. HKLM\System\CurrentControlSet\Control\CrashControl\AutoReboot (REG_DWORD) is checked - if this is 1 then the system restarts
> This is a warm boot, not a graceful system shutdown

7. During startup, the boot manager checks to see if the pagefile was cleanly closed at the end of the previous session - if not, the boot menu is presented
> This covers the situations where Windows is crashing during startup, bugchecking during operation or simply has the power pulled

8. If the pagefile on the boot volume contains a valid memory dump, it is renamed and a new pagefile reinitialized

9. winlogon.exe reads the registry value written in (5) and starts process savedump.exe to extract the memory contents from the renamed pagefile to a temporary file (DUMPxxxx.tmp) on the same drive
> This is why you need enough free disk space on the boot drive to create this temporary file

10. Once the dump is extracted, the temporary file is moved to the final destination specified in the registry (default is %systemroot%\MEMORY.DMP)
> HKLM\System\CurrentControlSet\Control\CrashControl\DumpFile (REG_EXPAND_SZ)

11. The registry value set in (5) is deleted
> This avoids checking the pagefile for a dump file on the next startup

12. An event is logged in the System event log (once the service starts) to indicate the dump file was saved following the bugcheck

13. If the tickbox is checked, an administrative alert is sent

14. The boot process continues

“What about ReadyBoost?”

ReadyBoost is purely an extension for system cache, it is not a replacement for, or addition to the pagefile – nor is it “extra RAM”.

It is used to contain file sections that have been read from disk (slow) into RAM (fastest) to store in a cache that is accessible over a fast, independent bus (USB 2.0) without going back to disk (pagefile or re-read from original location).

As USB devices can be removed without warning (“surprise removal”), we cannot have those devices holding data that has not been committed or does not exist elsewhere – so ReadyBoost cannot be used for paging out memory contents.

If the ReadyBoost device is removed, there is no data loss as the original copy of the data is still available – the disk.

In short, cache memory should be treated as volatile and should cause no unrecoverable error if it gets flushed.

To sum up:
- if you tune the pagefile for performance, you may lose the option to get troubleshooting data
- if you have plenty of RAM and much of it is just being used as system cache, you might benefit from using ReadyBoost and reducing the pagefile to a much smaller size
- if you experience bugchecks, or want to create a manual dump for analysis, you will need to ensure the pagefile settings can accommodate you

References:

RAM, Virtual Memory, Pagefile and all that stuff
https://support.microsoft.com/kb/555223

What to consider when you configure a new location for memory dump files in Windows Server 2003
https://support.microsoft.com/kb/886429

How to determine the appropriate page file size for 64-bit versions of Windows Server 2003 or Windows XP
https://support.microsoft.com/kb/889654