According to al the documentation that I have read online, when I configure Windows to automatically manage my page file, the size should automatically grow and shrink as needed. While my computer does indeed increase it's page file when it needs to, it does not seem to shrink the size back down. As an example, right now, my page file is 18432 MB, but windows recommends that the size should be 2938 MB. Why won't it shrink down to be closer to the recommended size?

Image of my current pagefile settings:

enter image description here

  • How much memory is installed on your computer? Aug 28, 2020 at 0:46
  • If you really need to shrink the page file, delete it (set to no page file), restart and re-create a new one smaller.
    – John
    Aug 28, 2020 at 0:55
  • @music2myear I have 16GB. However, how relevant would that be for dynamically sized? My friend with 32GB has the same settings as I do, but his computer only has a 5GB page file, which is much closer to the recommended value. Aug 28, 2020 at 1:35

4 Answers 4


The only reason why Windows will expand the pagefile beyond the original size is if the commit charge requires it. The commit limit is RAM size plus pagefile size, minus a small overhead. If the pagefile size was 18432MB (18 GB) with 16GB RAM that means the commit charge must have been about 34 GB at the time the screenshot was taken. That is very high. If it is like that now you need to determine why. This could be caused by a process or the Paged or Non-paged pool or other potential causes.

When the commit charge return to normal the pagefile will shrink, if that is possible. It may not be. If data was written to the end of the extended pagefile and was not freed by whatever allocated the memory then the pagefile cannot be shrunk down. Windows will not rearrange the contents of the pagefile to make this possible. That would have a serious impact on performance.

But first check the commit charge. If that is high the large pagefile is just a symptom.

  • This seems like this right answer, but I want to make sure I am understanding you before I mark it as such. I do indeed occasionally run stuff on my computer that requires a 34GB commit charge, but I would have expected the commit charge to go down after I closed the program. What you are saying is that it should, but the program might not be correctly cleaning up after itself, and windows thinks it still needs a large commit charge (though task manger shows it decreasing after I close). If this is the case, can I force the files that need cleanup out of the charge somehow? Aug 28, 2020 at 6:56
  • 1
    Preferably some way that would not required me to disable the page file, reboot, re-enable the page file, and reboot again? Aug 28, 2020 at 6:56
  • @BarrowWight How do you figure? Nowhere does it explain why Windows won't shrink the pagefile, which was the question asked. Aug 28, 2020 at 9:01
  • If you have 16GB RAM and a 34GB commit charge then the pagefile must be at least 18GB. The pagefile cannot be less than the commit charge minus RAM size. If the pagefile size was restricted then whatever process was causing the high commit would fail. The high commit charge cannot be diagnosed with the limited information provided.
    – LMiller7
    Aug 28, 2020 at 14:03
  • @LMiller7 I am clear on that part. What would be the best way to diagnose the high commit charge? I just checked the commit by exporting all of the data from process monitor and summing up the commit column, and it has committed about 11.5GB, but the page file is 17.2GB. Is that a normal size difference? And if so am I correct to assume that the only way to shrink it would be to close programs using commit? Aug 28, 2020 at 22:14

I can report that Windows eventually shrinks the paging file size in circumstances similar to those outlined by the other contributors.

In my case, a misbehaving application requested enormous amounts (about 40 GB) of memory, leading to a paging file size of about 45 GB and forcing other applications to crash. (My computer is equipped with 16 GB RAM.) I shut down the offending application and prevented future auto-starts such that the application did never run once I recognized the problem. I regularly checked (with Process Explorer and command line pstat) the Commit Charge and the paging file size: it remained at the enormous size for about two weeks including a few reboots.

Today, after another reboot caused by system updates, the paging file has shrunk to a size of 12 GB. It seems that Windows monitors for quite a while to see if the situation occurs again and will eventually shrink the paging file size.


Here is Microsoft's recommended document regarding Pagefile sizes: https://docs.microsoft.com/en-us/windows/client-management/determine-appropriate-page-file-size

The general rule of thumb is that the Pagefile is set to a value a bit greater (some say 1.25x) the total amount of RAM in the computer, with consideration for the volume size.

The primary reason for this is that the system will use the Pagefile to write the dump files in case of a crash, and having a Pagefile a given amount larger than the total memory allows the entire memory dump to be captured.

I cannot say why your recommended value is so low, but I would not say there is any reason to believe the system will use the recommended value, or anything to indicate that it NOT using the recommended value is indicative of a problem.

As others have noted, you are welcome to set the Pagefile size to 0, restart the computer to delete the pagefile, and then set it back to system managed.

I would NOT follow others recommendations to set it manually unless you are very certain that you know what you are doing, and you absolutely do not have the available hard drive space.

For comparison, I have a computer with 64GB of RAM, and the pagefile on it is larger than 64GB.


If the system were to grow and shrink the page file, the page file would become more and more fragmented over time. I recommend just setting the page file to the recommended size and leaving it at that.

  • I would appreciate if the downvoter would explain the reason for the downvote. This is in fact the reason Windows won't shrink the pagefile, which is the question that was asked. Aug 28, 2020 at 9:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .