This was a question brought up at another forum, which I answered -- and thought that it should be posted here for Sysnative Members to read, if they wish.
During the average Windows installation, Windows does pre-allocate a page file.
It used to be that the page file allocation base size had to be equal in size to installed physical RAM + ~200 MB. If not, then the system was incapable of producing memory dumps. This is because memory dumps are written to the page file.
Beginning with Windows 8, I believe, Windows now allows a much smaller page file to be allocated and it is a variable size, so that when a BSOD or an APPcrash occurs, the system can increase the size of the page file and write the dump to it.
With the explosion of x64 beginning about 10 years ago now, Microsoft recognized that at least some folks would install enormous amounts of relatively cheap RAM into their systems as many had had enough of the very slow XP systems being caused by excessive use of virtual memory (paging - using the page file as RAM when you ran out of RAM). I'm speaking mostly of XP systems that had 128 MB or 256 MB installed physical RAM. Generally, if an XP Pro or Home system had at least 768 MB RAM, the system was much, much faster due to very little, if any, use of virtual memory (paging).
4 GB RAM for x64 became the norm for Vista and Windows 7 for many, but when Windows 8, then 8.1, then 10 came out, people were outfitting their systems with 12, 16, 32 and even 64GB of RAM. This change coincided with the ever-increasing popularity of the then-new SSDs. Many were trying to get by with 128 GB or 256 GB SSD size, only to find a huge chunk was pre-allocated for the page file and therefore caused people to run extremely low or to run out of hard disk space. For many, the answer was to cut-down/delete the page file.
I remember an OP that had a dual-quad core system with 128 GB RAM and a nearly 200 GB page file. This was under Windows 7 and I just could not believe what I was seeing. There is very little chance that any of the 200 GB page file would ever be used except in the event of a BSOD. Some apps like Notepad and SysInternal's Process Monitor do write directly to the page file, but these are the exceptions, not the norm. If you run Notepad and have no page file, a temporary one will be created.
I have an HP ENVY 17 core i7 laptop with 12 GB RAM and my page file is just under 8.6 GB -- and I have had a few BSODs. My page file:
My page file was allocated during initial system boot-up on 12-20-2013 with a base allocation size of 8576 MB (~8.6 GB). I currently am using 2768 MB (~2.8 GB) of virtual memory (due to many open Notepads); my peak virtual memory usage since last re-boot was 7992 MB (~8 GB). Current RAM usage = 10.4 GB/ 12 GB installed physical RAM (obtained from Process Explorer).
If you would like to see your page file info, run #34 in my WMIC Tutorial - "
(wmic pagefile) - Windows Management Instrumentation (WMI) - (Windows 10, 8.1, 8, 7, Vista)
Please forgive the formatting (the extra link in the box) -- it appeared after we just migrated from vBulletin to XenForo forum software.
You can run #34 - either obtaining a TEXT file output or an HTML file output. I assure you that all of the batch files are safe to run. In fact, we just purchased a digital certificate and are just starting to apply it to all of our apps.
So, that same OPs system running Windows 10 with 128 GB RAM will have a relatively small page file these days under Windows 10 - maybe 10 or 20 GB, which is very likely more than enough to capture full kernel memory in the event of a BSOD. It is kernel memory that needs to be analyzed after a BSOD - not the contents of physical RAM.
Anyway, that is my theory on why we have seen dramatically reduced page files beginning with Windows 8.
The Hibernation File (c:\hiberfil.sys) has been trimmed too. Instead of it being equal to the amount of physical RAM, it now is about 75% in size of total physical RAM.
Regards. . .
jcgriff2
Shplad said:
During the average Windows installation, Windows does pre-allocate a page file.
It used to be that the page file allocation base size had to be equal in size to installed physical RAM + ~200 MB. If not, then the system was incapable of producing memory dumps. This is because memory dumps are written to the page file.
Beginning with Windows 8, I believe, Windows now allows a much smaller page file to be allocated and it is a variable size, so that when a BSOD or an APPcrash occurs, the system can increase the size of the page file and write the dump to it.
With the explosion of x64 beginning about 10 years ago now, Microsoft recognized that at least some folks would install enormous amounts of relatively cheap RAM into their systems as many had had enough of the very slow XP systems being caused by excessive use of virtual memory (paging - using the page file as RAM when you ran out of RAM). I'm speaking mostly of XP systems that had 128 MB or 256 MB installed physical RAM. Generally, if an XP Pro or Home system had at least 768 MB RAM, the system was much, much faster due to very little, if any, use of virtual memory (paging).
4 GB RAM for x64 became the norm for Vista and Windows 7 for many, but when Windows 8, then 8.1, then 10 came out, people were outfitting their systems with 12, 16, 32 and even 64GB of RAM. This change coincided with the ever-increasing popularity of the then-new SSDs. Many were trying to get by with 128 GB or 256 GB SSD size, only to find a huge chunk was pre-allocated for the page file and therefore caused people to run extremely low or to run out of hard disk space. For many, the answer was to cut-down/delete the page file.
I remember an OP that had a dual-quad core system with 128 GB RAM and a nearly 200 GB page file. This was under Windows 7 and I just could not believe what I was seeing. There is very little chance that any of the 200 GB page file would ever be used except in the event of a BSOD. Some apps like Notepad and SysInternal's Process Monitor do write directly to the page file, but these are the exceptions, not the norm. If you run Notepad and have no page file, a temporary one will be created.
I have an HP ENVY 17 core i7 laptop with 12 GB RAM and my page file is just under 8.6 GB -- and I have had a few BSODs. My page file:
Code:
AllocatedBaseSize=8576
CurrentUsage=2768
Description=C:\pagefile.sys
InstallDate=20131220133842.488186-300
Name=C:\pagefile.sys
PeakUsage=7992
Status=
TempPageFile=FALSEIf you would like to see your page file info, run #34 in my WMIC Tutorial - "
(wmic pagefile) - Windows Management Instrumentation (WMI) - (Windows 10, 8.1, 8, 7, Vista)
Please forgive the formatting (the extra link in the box) -- it appeared after we just migrated from vBulletin to XenForo forum software.
You can run #34 - either obtaining a TEXT file output or an HTML file output. I assure you that all of the batch files are safe to run. In fact, we just purchased a digital certificate and are just starting to apply it to all of our apps.
So, that same OPs system running Windows 10 with 128 GB RAM will have a relatively small page file these days under Windows 10 - maybe 10 or 20 GB, which is very likely more than enough to capture full kernel memory in the event of a BSOD. It is kernel memory that needs to be analyzed after a BSOD - not the contents of physical RAM.
Anyway, that is my theory on why we have seen dramatically reduced page files beginning with Windows 8.
The Hibernation File (c:\hiberfil.sys) has been trimmed too. Instead of it being equal to the amount of physical RAM, it now is about 75% in size of total physical RAM.
Regards. . .
jcgriff2
Last edited:
