Editing Memory paging (section)

===Microsoft Windows===
====Windows 3.x and Windows 9x====
Paging has been a feature of [[Microsoft Windows]] since [[Windows 3.0]] in 1990.  Windows 3.x creates a [[hidden file]] named <code>386SPART.PAR</code> or <code>WIN386.SWP</code> for use as a swap file. It is generally found in the [[root directory]], but it may appear elsewhere (typically in the WINDOWS directory). Its size depends on how much swap space the system has (a setting selected by the user under [[Windows Control Panel|Control Panel]] → Enhanced under "Virtual Memory"). If the user moves or deletes this file, a [[Blue Screen of Death|blue screen]] will appear the next time Windows is started, with the [[error message]] "The permanent swap file is corrupt". The user will be prompted to choose whether or not to delete the file (even if it does not exist).

[[Windows 95]], [[Windows 98]] and [[Windows Me]] use a similar file, and the settings for it are located under Control Panel → System → Performance tab → Virtual Memory. Windows automatically sets the size of the page file to start at 1.5× the size of physical memory, and expand up to 3× physical memory if necessary. If a user runs memory-intensive applications on a system with low physical memory, it is preferable to manually set these sizes to a value higher than default.

===={{Anchor|PAGEFILE-SYS}}Windows NT====
The file used for paging in the [[Windows NT]] family is <code>pagefile.sys</code>. The default location of the page file is in the root directory of the partition where Windows is installed. Windows can be configured to use free space on any available drives for page files.  It is required, however, for the boot partition (i.e., the drive containing the Windows directory) to have a page file on it if the system is configured to write either kernel or full memory dumps after a [[Blue Screen of Death]]. Windows uses the paging file as temporary storage for the memory dump. When the system is rebooted, Windows copies the memory dump from the page file to a separate file and frees the space that was used in the page file.<ref>{{cite web|last=Tsigkogiannis|first=Ilias|date=December 11, 2006|title=Crash Dump Analysis|url=https://docs.microsoft.com/en-us/archive/blogs/iliast/crash-dump-analysis|url-status=live|archive-url=https://web.archive.org/web/20081007215138/http://blogs.msdn.com/iliast/archive/2006/12/11/crash-dump-analysis.aspx|archive-date=October 7, 2008|access-date=2008-07-22|work=driver writing !{{=}} bus driving|publisher=[[Microsoft]]}}</ref>

====Fragmentation====
{{update|section|date=July 2014}}
In the default configuration of Windows, the page file is allowed to expand beyond its initial allocation when necessary. If this happens gradually, it can become heavily [[file system fragmentation|fragmented]] which can potentially cause performance problems.<ref>{{cite web
|url         = https://technet.microsoft.com/en-us/sysinternals/bb897426
|title       = Windows Sysinternals PageDefrag
|work        = Sysinternals
|publisher   = [[Microsoft]]
|date        = November 1, 2006
|access-date  = 2010-12-20
|url-status     = live
|archive-url  = https://web.archive.org/web/20101225112753/http://technet.microsoft.com/en-us/sysinternals/bb897426
|archive-date = December 25, 2010
}}</ref> The common advice given to avoid this is to set a single "locked" page file size so that Windows will not expand it.  However, the page file only expands when it has been filled, which, in its default configuration, is 150% of the total amount of physical memory.<ref>{{cite web
|title = Page File Information
|url = https://oingo.kpt.co.id/IT/en/107-2/page-file_12799_oingo-kpt.html
|website = Oingo KPT
|access-date = 14 December 2024
}}</ref> Thus the total demand for page file-backed virtual memory must exceed 250% of the computer's physical memory before the page file will expand.

The fragmentation of the page file that occurs when it expands is temporary. As soon as the expanded regions are no longer in use (at the next reboot, if not sooner) the additional disk space allocations are freed and the page file is back to its original state.

Locking a page file size can be problematic if a Windows application requests more memory than the total size of physical memory and the page file, leading to failed requests to allocate memory that may cause applications and system processes to fail. Also, the page file is rarely read or written in sequential order, so the performance advantage of having a completely sequential page file is minimal. However, a large page file generally allows the use of memory-heavy applications, with no penalties besides using more disk space. While a fragmented page file may not be an issue by itself, fragmentation of a variable size page file will over time create several fragmented blocks on the drive, causing other files to become fragmented. For this reason, a fixed-size contiguous page file is better, providing that the size allocated is large enough to accommodate the needs of all applications.

The required disk space may be easily allocated on systems with more recent specifications (i.e. a system with 3&nbsp;GB of memory having a 6&nbsp;GB fixed-size page file on a 750&nbsp;GB disk drive, or a system with 6&nbsp;GB of memory and a 16&nbsp;GB fixed-size page file and 2&nbsp;TB of disk space). In both examples, the system uses about 0.8% of the disk space with the page file pre-extended to its maximum.

[[Defragment]]ing the page file is also occasionally recommended to improve performance when a Windows system is chronically using much more memory than its total physical memory.<ref>{{cite web
|title = What Does Defragging Do?
|url = https://www.hp.com/us-en/shop/tech-takes/what-does-defragging-do
|website = HP Tech Takes
|publisher = Hewlett-Packard
|access-date = 14 December 2024
}}</ref> This view ignores the fact that, aside from the temporary results of expansion, the page file does not become fragmented over time. In general, performance concerns related to page file access are much more effectively dealt with by adding more physical memory.