Windows 8/10 Hibernate and the effect on disk space

Frank100

Rising Star
Hello all,

It's hard to believe I joined these forums three years ago but I have been pretty quiet for some time. I thought I would post something that might help people make choices in terms of RAM and hard disk now that we have Windows 8 in full swing and now we know Windows 10 operates in much the same way in relation to hibernate and the fast boot process.

Going back to the old days when you shut your computer down you actually shut the computer down and so when restarting it took a couple of minutes to boot. This is because the BIOS would run its checks, introduce the boot process to the Master Partition Table where a list of partitions would be stored one of which (hopefully) would be marked as active. Having accessed the starting cluster for that partition it would again hopefully find the necessary boot volume information for that partition and boot code in the partition.

Since Windows 8 this process changed. Windows 8 can be fully shut down if you want it to but by default it boots from the hiberfil.sys file and in part from the partition information. This means it can copy much of the hiberfil.sys straight back into memory rather than go through the steps in used to when booting and this is much faster.

Hiberfil.sys has been around for a long time and you used to be able to delete it if you didn't want the space used up on your disk. Because of the fast boot process in Windows 8 and 10 it is now highly inadvisable to disable it and to delete the file.

So why would you want to delete hiberfil.sys? Because it's purpose is to save the entire contents of your RAM into this file and onto the disk it is as large a file as the amount of RAM you have. So if you decided to get 64GB of RAM then your hiberfil.sys file is going to be 64GB too. Now just imagine if you treated yourself to a small SSD for your OS and programs, suddenly you've lost a massive amount of space.

For some reason Microsoft has not provided an opportunity to move the hiberfil.sys to another disk or another partition. I don't see any reason why they couldn't have done that but it would have meant quite a bit of updating registry and other information to amend the fast boot process if a user did choose to move it. Not very helpful really!

If you ever look at a hiberfil.sys file you will see that any decompressed data in the RAM is re-compressed before being written into the hiberfil.sys file. Having analysed many RAM dumps and the corresponding hiberfil.sys files I've been able to match up the expanded data from the RAM to the compressed data in hiberfil.sys. This means in practice hiberfil.sys doesn't really need to be the same size as the RAM. In practice it could easily cope being about 60% of the size. Once I again I would guess Microsoft left it alone because it is extra work and perhaps might be able to argue once in a blue moon there will be very little uncompressed data in the RAM and that 60% or 70% might not be enough on that occasion.

What this does mean is if you go for quite a lot of RAM then you need to factor in that amount of space as dead space on your Windows partition, and if that is a small SSD you might find there is very little space left.

Have a nice day,

Frank (but that isn't really my name. Allegedly President Nixon once had a hedgehog called Frank)
 

timpin

Member
Interesting, thanks.

When I got my new Windows 10 PC recently (which has 32Gb of RAM, a 500Gb SSD plus a HDD), in the initial Windows setup I think I told it "Never" to hibernate, as I generally like it to back up data to my NAS every night, in the middle of the night.

I don't know if that's the reason, but in any event I don't have a hiberfil.sys file on my C: drive. (I am viewing hidden files.)

Compared with my very old previous PC, it's lightning quick to boot up. So this is one possible solution to a C: drive with too big a hiberfil.sys file.
 
Top