Summary: I want to change the location of "hiberfil.sys" on Windows 7 (x64 and x86).As you all probably know, you can put the Windows system files and the bootloader on different partitions. Microsoft chose the following naming scheme for these partitions (see [1]):
"System Partition": This is the partition on which the boot loader resides (MBR, BOOTMGR, BCD stuff, etc.). This partition does NOT contain the Windows system directory.
"Boot Partition": This is the partition with the Windows-directory. This partition does NOT contain the boot loader.
Very strange naming convention, I would have named them just the other way around, but whatever.
The hibernation-file "hiberfil.sys" is always stored on the partition with the windows folder ("boot partition").
This is what I want to change.
Why would I want to change that?
When you use a SSD, storage is expensive. E.g. you have a 120 GB SSD drive, and you have to waste 8 GB or 16 GB for "hiberfil.sys", for a typical RAM-size of a modern PC.
Plus: You should avoid any unnecessary writing to the SSD, as this will stress the drive. (If you have 16 GB RAM and hibernate twice a day, that means 32 GB will be written!).
It would be much better to place the bootloader partion ("System Partition") onto a classic harddrive, and store the hiberfil.sys file there. You can easily place the bootloader onto a partition on another harddrive, but there's no option to change the location of "hiberfil.sys".
Microsoft offers an "explanation" (or should I say: a lame excuse) why this is the case:
http://technet.microsoft.com/en-us/magazine/2007.11.windowsconfidential.aspx
OK, so there is a very simple file system driver in the early boot process, but anyway: This driver has to be able to read files from both, the "System Partition" and the "Boot Partition", so it really shouldn't matter, whether the hibernation data is stored in "C:\hiberfil.sys" or "D:\hiberfil.sys" (when "C:" and "D:" are the "Boot Partition" and the "System Partition", respectively).
The BCD configuration ("bcdedit.exe /enum all") suggests, that it is indeed possible to load "hiberfil.sys" from a different partition:
Wiederaufnahme aus dem Ruhezustand
----------------------------------
Bezeichner {50b3eff0-aa69-11e0-9994-c055d5933a31}
device partition=C:
path \Windows\system32\winresume.exe
description Windows Resume Application
locale de-de
inherit {resumeloadersettings}
filedevice partition=C:
filepath \hiberfil.sys
debugoptionenabled No
You can change that, if you set the system to hibernate, and instead of resuming it on reboot, you boot into ERD Commander (from MSDaRT).
bcdedit.exe /store D:\Boot\BCD /set {50b3eff0-aa69-11e0-9994-c055d5933a31} filedevice partition=D:
I tried that, and I also manually moved "hiberfil.sys" to the other partition (restoring it's original permissions after moving).
Unfortunately, Windows didn't resume afterwards (error message: "Windows did not shut down successfully" on bootup).
I tried to analyze "winresume.exe" (from the checked build of Win7 x86) in IDA, and I found a function "HbResumeFromHibernate()" which calls:
HbInitializeDisplay(&v33);
HbOpenHiberFile();
HbpCheckPageFileValidity(&v27);
HbCheckForUserIntervention((int)&v31, 1, (int)&v30);
HbQueryInitialUserPreference();
HbSetFileDisposition(0);
HbpRestoreImageFromHiberFile(v4, a1, v33, (int)&v27);
(and many more)
I guess somewhere around there lies the problem.
So my questions are:
Which part of the operating system creates the "hiberfil.sys" file?
How to patch "winresume.exe" so that it resumes from the other partition?
There are many talented people out here. I guess some of you (Mark Russinovich...) know Windows even better, than the original Microsoft developers... ;-)
Further reading:
[1] http://en.wikipedia.org/wiki/System_partition_and_boot_partition
======================================
the definitive explanation for the inability to move the hibernation and other files to another drive.
The File System Paradox
The File System Paradox
bootmgr should be able to access any available drive, for which it has a driver.
The article is interesting, but somewhat out of date. It refers to NTLDR boot.ini, and NTDETECT.COM, instead of bootmgr, BCD and \Windows\system32\winload.exe.
It seems obvious to me that the "miniaiture file system driver" has to be contained within the boot sector, MBR and BIOS, in order to start loading bootmgr from the root of the designated drive. Without basic filesystem support, it would not be able to locate nor read the root directory, much less interpret it correctly. All this has to be done to locate the first and remaining clusters of bootmgr. Note, BOOTMGR is specified by name in the NT60 boot sector, whereas an NT52 boot sector specifies NTLDR.
Once bootmgr loads, enough about filesystems is known so that bootmgr can read c:\boot\BCD, and use values in that database, such as \Windows\system32\winload.exe, the usual loader path for a NT60 operating system.
For hiberfil.sys, the loader is \Windows\system32\winresume.exe.
As I said in my previous post, you could change the location for \Windows\system32\winresume.exe to load hiberfil.sys. But this would not change the location where Windows saves hiberfile.sys. That would have to be acomplished elsewhere.
Not only that, I think there are practical reasons why memory intensive files such as hiberfil.sys and pagefile.sys can only work correctly on the root. Having to negotiate a folder heierarchy during such memory and disk activity would slow things down too much.
The article is interesting, but somewhat out of date. It refers to NTLDR boot.ini, and NTDETECT.COM, instead of bootmgr, BCD and \Windows\system32\winload.exe.
It seems obvious to me that the "miniaiture file system driver" has to be contained within the boot sector, MBR and BIOS, in order to start loading bootmgr from the root of the designated drive. Without basic filesystem support, it would not be able to locate nor read the root directory, much less interpret it correctly. All this has to be done to locate the first and remaining clusters of bootmgr. Note, BOOTMGR is specified by name in the NT60 boot sector, whereas an NT52 boot sector specifies NTLDR.
Once bootmgr loads, enough about filesystems is known so that bootmgr can read c:\boot\BCD, and use values in that database, such as \Windows\system32\winload.exe, the usual loader path for a NT60 operating system.
For hiberfil.sys, the loader is \Windows\system32\winresume.exe.
As I said in my previous post, you could change the location for \Windows\system32\winresume.exe to load hiberfil.sys. But this would not change the location where Windows saves hiberfile.sys. That would have to be acomplished elsewhere.
Not only that, I think there are practical reasons why memory intensive files such as hiberfil.sys and pagefile.sys can only work correctly on the root. Having to negotiate a folder heierarchy during such memory and disk activity would slow things down too much.
------------------------------
Thanks a lot. This did the trick. I am trying to clear free space off of a VM and (obviously) the VM doesn't need Hibernate!! :)
------------------------------
That 'File System Paradox' is an excuse not an explanation. Every OS has a single threaded boot version. The boot info is on one drive but the system drive can be on any disk; that is, all the disk partitions are accessable.
Net, this could rather easily have been done and with the use of SSD drives for storing the OS and core systems, coupled with their price which can be 8-10x higher per gigabyte than a regular drive, this should have been done.
While 'the dog ate my homework' tells me why it isn't provided, it isn't a very good answer. An incomplete with at least one letter grade reduction after it arrives.
------------------------------
I don’t know if it can be moved but if you’re not using it, it can be turned off.
You will save the equivalent in hard drive space as RAM that is installed by turning it off.In a Run window, type powercfg.exe -h off and press Enter. To turn it back on, type powercfg.exe -h on and press Enter.
Interestingly, there is also access to Control Panel\All Control Panel Items\Power Options.
Using the Balanced option, and manually setting Display and Computer Sleep to Nevers, does nothing to remove a massive hiberfil.sys (22GB on my 111GB Intel SSD). However, changing Power settings to High performance AND running 'powercfg.exe -h off' immediately removes the hiberfil.sys file.
The hiberfil.sys and pagefil.sys files were massively bloated when I installed Adobe's new (launched yesterday) Creative Cloud. Disk free space dropped from 54GB to 27GB when I installed PhotoShop's 2GB. FYI, outside hiberfil and pagefile, my used space is a little under 27GB.
Given the dynamics of Cloud and solid state technology being used everywhere in massive proportions, it seems very odd that Microsoft hasn't engineered the ability to move pagefile.sys and hibeerfil.sys to an alternative internal disk ... or better yet, an external service device! Say, somewhere inside microsoft.com.
---------------------------------
I don't think you can do that! My system is SSD, and I have some experience that may assist you. But before setting you at ease, just a few things to illustrate why hiberfil and sister pagefile are critical to system function, regardless of you setting their size to zero.
`
Brian Borg I don't know how Windows could be configured to save hiberfil to a different drive... enterbcdedit /enum all in a command prompt. You will see a long list containing something like:
Resume from Hibernate
---------------------
identifier {4b363540-4c2d-11de-a780-e56ff09d11cf}
device partition=C:
path \Windows\system32\winresume.exe
description Windows Resume Application
locale en-US
inherit {resumeloadersettings}
filedevice partition=C:
filepath \hiberfil.sys
debugoptionenabled No
Filedevice and filepath specify the location and name of hiberfil.
`
I have set to Never "Turn off the display" and "Put the computer to sleep". But we get the same bcdedit /enum all output. These are system defaults, and not descriptive of current system status. But why move hiberfil to another drive? Why not downsize it?
`
Are we all aware that there are two "sleep" provisions for the Windows OS? They are pagefile.sys and hiberfil.sys. They both create massive on-the-fly file space. And they are both becoming redundent on new hardware platforms. That is, their temporary file space can be set to zero. This is useful on Microsoft-based computers with 16GB or more of RAM and a Gen 3.0 or better motherboard. Gen 3 is a critical detail, becuase it uses processors with at least one additional layer to replace disc based (temporary files) with dynamic RAM supported system data management.
`
I like to keep my hiberfil and pagefile at "0". Using Microsoft softwares (Windows, Office, etc) that are obviously 64-bit capable and therefore Gen 3 friendly, and this is no problem.
`
Unfortunately, some primitve applications like Adobe Photoshop, while claiming to provide 64-bit operation, are actually dragged down by massive amounts of old 8-bit driver filters. To cut a long story short, primitive software will not run properly on Gen 3 as they are hiberfil and pagefile dependent. Best we can do is try and balance their bloat access: too much bloat and they loop into oblivion, too little bloat and they are lost.
`
Chucking an SSD into your system will not make it Gen 3. If you don't have the correct hardware, you have to accept for now a chubby baby profile! ;o)
`
My Gen 3 platform uses P8Z77 board with Intel 7037 CPU and 32 GB RAM. This is how I zero the bloat.
`
Hiberfil: Control Panel, Power Options, High Performance, Change plan settings, Never...
also: Start, All Programs, Accessories, Command Prompt (right click and Run as administrator),powercfg.exe /hibernate off [on]
also: Start, All Programs, Accessories, Command Prompt (right click and Run as administrator),powercfg.exe /hibernate off [on]
Pagefile: Control Panel, System, Advanced system settings, Advanced tab, Performance settings, Advanced tab [again], Change, No page file...
for Photoshop: Initial size 384, Maximum size 1152
for Photoshop: Initial size 384, Maximum size 1152
-----------------------------
Honestly, I TRY SO HARD to get Microsoft to lauch its own Gen 3 friendly graphics editor. Photoshop 'os' is so... bloated! Maybe we need to get organized, 1.4 billion people using computers in the real world. We herein declare we are on strike without end. No more decent graphics until Microsoft gived us a stable graphics editor.
=================
To stop the Hibernation service in Windows Vista or 7:
- Click on the Start button and in the Search field type
cmd
- When the command prompt opens, type
powercfg.exe -h off
- Exit the command prompt
powercfg.exe -h on
At this point a few important things will have taken place in Windows:
- hiberfil.sys no longer exists in Explorer (i.e. is deleted, thus freeing up a lot of disk space),
- "Hibernate" is no longer available from the Shutdown options in the Start menu, and
- obviously, you will no longer be able to place Windows into a hibernation state (S4).
I don't know how Windows could be configured to save hiberfil to a different drive, but you could configure BOOTMGR to boot from a different location, using bcdedit.exe.
To see the current settings enter bcdedit /enum all in a command prompt. You will see a long list containing something like:
Resume from Hibernate
---------------------
identifier {4b363540-4c2d-11de-a780-e56ff09d11cf}
device partition=C:
path \Windows\system32\winresume.exe
description Windows Resume Application
locale en-US
inherit {resumeloadersettings}
filedevice partition=C:
filepath \hiberfil.sys
debugoptionenabled No
Filedevice and filepath specify the location and name of hiberfil.
No comments:
Post a Comment