Restoring hibernated status

Speaking of the dirty bit, is there a hibernate bit?

Or a hibernate flag, as I think it would have been called in
mainframes?

I think twice, including at the moment in the recently problematic
computer, I've had the situation where, maybe on the second try to
start up (after a failed first try), even though I had hibernated at
the last shut down, it didn't try to come out of hibernation on
restart. Instead it just started with only the OS running and no
application programs.

But the hibernate file was still there, unused.

I couldn't just hibernate, because then when it restarted, it would
have looked like it did, the OS and its startup programs running and
nothing else.

What I want to do is set the hibernate bit or byte, but NOT copy the
RAM to the hibernate file. Instead, leave that file like it was
before so on the next startup it will look like it looked TWO sessions
ago. I'm assuming that there are two bits, one to tell the OS to
copy the RAM to the hibernate file, and a second to tell the OS to
copy the hibernate file to the RAM, and that normally both get set at
the same time. I just want to set one of them, the second. OTOH,
if there is only one bit, I think that's a design flaw.

Micky wrote:
Speaking of the dirty bit, is there a hibernate bit?

Or a hibernate flag, as I think it would have been called in
mainframes?

I think twice, including at the moment in the recently problematic
computer, I've had the situation where, maybe on the second try to
start up (after a failed first try), even though I had hibernated at
the last shut down, it didn't try to come out of hibernation on
restart. Instead it just started with only the OS running and no
application programs.

But the hibernate file was still there, unused.

I couldn't just hibernate, because then when it restarted, it would
have looked like it did, the OS and its startup programs running and
nothing else.

What I want to do is set the hibernate bit or byte, but NOT copy the
RAM to the hibernate file. Instead, leave that file like it was
before so on the next startup it will look like it looked TWO sessions
ago. I'm assuming that there are two bits, one to tell the OS to
copy the RAM to the hibernate file, and a second to tell the OS to
copy the hibernate file to the RAM, and that normally both get set at
the same time. I just want to set one of them, the second. OTOH,
if there is only one bit, I think that's a design flaw.

AFAIK, there is something in the chipset. It prevents the user
from choosing an OS to boot from, and goes straight back to
the previous activity.

If you kill all the power, that status may be lost. I've managed
to boot a CD by doing that (that's how I discovered Linux won't
mount a hibernated Windows C: ). Now, if you happened to select
the the boot OS again as your choice, I think the OS is supposed
to notice the hiberfile is valid and load it instead.

So to do what you want, you'd

1) Hibernate.
2) Shut off all power.
3) Get a fresh hiberfile onto C: (somehow).
4) Boot, and the fresh hiberfile could be loaded.

But I'm not sure what the utility of that is.
What does that buy me ?

There is a remote danger, that some item is missing
from the file system, if you run the older hiberfile
and some dependency it used to have, is no longer
satisfied. What you want to do isn't guaranteed to be
seamless. The advantage of using the hiberfile that
was just made, is it kinda aligns with the file set
stored on the drive (it's supposed to be a synchronized
"session" after all).

Paul

Paul wrote on 10/23/2015 11:23 PM:
Micky wrote:
Speaking of the dirty bit, is there a hibernate bit?
Or a hibernate flag, as I think it would have been called in
mainframes?

I think twice, including at the moment in the recently problematic
computer, I've had the situation where, maybe on the second try to
start up (after a failed first try), even though I had hibernated at
the last shut down, it didn't try to come out of hibernation on
restart. Instead it just started with only the OS running and no
application programs.
But the hibernate file was still there, unused.
I couldn't just hibernate, because then when it restarted, it would
have looked like it did, the OS and its startup programs running and
nothing else.
What I want to do is set the hibernate bit or byte, but NOT copy the
RAM to the hibernate file. Instead, leave that file like it was
before so on the next startup it will look like it looked TWO sessions
ago. I'm assuming that there are two bits, one to tell the OS to
copy the RAM to the hibernate file, and a second to tell the OS to
copy the hibernate file to the RAM, and that normally both get set at
the same time. I just want to set one of them, the second. OTOH,
if there is only one bit, I think that's a design flaw.

AFAIK, there is something in the chipset. It prevents the user
from choosing an OS to boot from, and goes straight back to
the previous activity.

If you kill all the power, that status may be lost. I've managed
to boot a CD by doing that (that's how I discovered Linux won't
mount a hibernated Windows C: ). Now, if you happened to select
the the boot OS again as your choice, I think the OS is supposed
to notice the hiberfile is valid and load it instead.

Paul, the mainboard actual does a good deal of work - restores some of
the system (including the page tables?) and uses a special restart
protocol to energize the OS. This is the reason that hiberfil.sys cannot
be on any disk other than the system disk - the mainboard doesn't want
to be involved in OS-level disk naming. I tracked this down when I build
machines with SSD for system disks and huge memories. I wanted to move
the large file somewhere else but could not and the reason given was the
previous. Now that we have gone from BIOS to UEFI, it is time to change
the G_d D__n hibernate spec too.
--
Jeff Barnett

[Default] On Sat, 24 Oct 2015 13:26:57 -0600, in
microsoft.public.windowsxp.general Jeff Barnett
wrote:

Paul wrote on 10/23/2015 11:23 PM:
Micky wrote:
Speaking of the dirty bit, is there a hibernate bit?
Or a hibernate flag, as I think it would have been called in
mainframes?

I think twice, including at the moment in the recently problematic
computer, I've had the situation where, maybe on the second try to
start up (after a failed first try), even though I had hibernated at
the last shut down, it didn't try to come out of hibernation on
restart. Instead it just started with only the OS running and no
application programs.
But the hibernate file was still there, unused.
I couldn't just hibernate, because then when it restarted, it would
have looked like it did, the OS and its startup programs running and
nothing else.
What I want to do is set the hibernate bit or byte, but NOT copy the
RAM to the hibernate file. Instead, leave that file like it was
before so on the next startup it will look like it looked TWO sessions
ago. I'm assuming that there are two bits, one to tell the OS to
copy the RAM to the hibernate file, and a second to tell the OS to
copy the hibernate file to the RAM, and that normally both get set at
the same time. I just want to set one of them, the second. OTOH,
if there is only one bit, I think that's a design flaw.

AFAIK, there is something in the chipset. It prevents the user
from choosing an OS to boot from, and goes straight back to
the previous activity.

If you kill all the power, that status may be lost. I've managed
to boot a CD by doing that (that's how I discovered Linux won't
mount a hibernated Windows C: ). Now, if you happened to select
the the boot OS again as your choice, I think the OS is supposed
to notice the hiberfile is valid and load it instead.

Paul, the mainboard actual does a good deal of work - restores some of
the system (including the page tables?) and uses a special restart
protocol to energize the OS. This is the reason that hiberfil.sys cannot
be on any disk other than the system disk - the mainboard doesn't want
to be involved in OS-level disk naming. I tracked this down when I build
machines with SSD for system disks and huge memories. I wanted to move
the large file somewhere else but could not and the reason given was the
previous. Now that we have gone from BIOS to UEFI, it is time to change
the G_d D__n hibernate spec too.

I found this interesting:
http://www.pcreview.co.uk/threads/ho...-work.3956197/


How the machine knows to resume from hibernate is BIOS dependant.
There are two schemes.

In both schemes the RAM contents are written to a file called
hiberfil.sys.
In the first scheme, the BIOS checks for the presence of the
hiberfil.sys file on the hard disc and if it finds it, loads it into
RAM and then proceeds as though recovering from STANDBY. Once
recovered the file is deleted.

In the second scheme, the BIOS sets an internal flag that it has
hibernated, and thus loads hiberfil.sys if the flag is set, otherwise
it just boots normally even if the file is present. Some BIOSes report
an error if they can't find the hiberfil.sys file. Once recovered the
file is not necessarily deleted.

The first scheme has the feature that it will recover from
hibernate if the system disc is replaced by another that was
hibernated before it was removed even if the original was not.

M.I.5¾, Jan 21, 2010 #2
--
Like one of those who replied, my experience has been, in XP and
Vista, that the hiberfil is always there (once I've first hibernated,
that might mean)

In Vista, which seems to be a lot like Win7, it's there now, and the
dates are amazing:

Created: Wednesday, April 15, 2015, 2:30:37 PM
Modified Tuesday, October 20, 2015, 11:38:18 PM
Accessed: Wednesday, April 15, 2015, 2:30:37 PM

Created makes sense, because that's about when my friend's
brother-in-law wiped his data off the drive and iiuc reinstalled
Vista. That's when I got the computer but I didn't connect it until
Septermber. Well, I think I had to change a setting to allow
hibernate, so I don't really see how the date could be in April, but
it's the least of my concerns now.

Modified makes no sense. It's 4 days ago, but I hibernated late last
night, and once a day or two ago, and each time it restarted just
where I left off.
Accessed makes no sense either. For the same reason, but its date
goes back all the way to the same time the file was created.

I didn't pay such close attention to dates when XP was working. Some
day I'll get it working again, but right now outdoor chores take
precedence before it gets cold out.

Micky wrote:
[Default] On Sat, 24 Oct 2015 13:26:57 -0600, in
microsoft.public.windowsxp.general Jeff Barnett
wrote:

Paul wrote on 10/23/2015 11:23 PM:
Micky wrote:
Speaking of the dirty bit, is there a hibernate bit?
Or a hibernate flag, as I think it would have been called in
mainframes?

I think twice, including at the moment in the recently problematic
computer, I've had the situation where, maybe on the second try to
start up (after a failed first try), even though I had hibernated at
the last shut down, it didn't try to come out of hibernation on
restart. Instead it just started with only the OS running and no
application programs.
But the hibernate file was still there, unused.
I couldn't just hibernate, because then when it restarted, it would
have looked like it did, the OS and its startup programs running and
nothing else.
What I want to do is set the hibernate bit or byte, but NOT copy the
RAM to the hibernate file. Instead, leave that file like it was
before so on the next startup it will look like it looked TWO sessions
ago. I'm assuming that there are two bits, one to tell the OS to
copy the RAM to the hibernate file, and a second to tell the OS to
copy the hibernate file to the RAM, and that normally both get set at
the same time. I just want to set one of them, the second. OTOH,
if there is only one bit, I think that's a design flaw.
AFAIK, there is something in the chipset. It prevents the user
from choosing an OS to boot from, and goes straight back to
the previous activity.

If you kill all the power, that status may be lost. I've managed
to boot a CD by doing that (that's how I discovered Linux won't
mount a hibernated Windows C: ). Now, if you happened to select
the the boot OS again as your choice, I think the OS is supposed
to notice the hiberfile is valid and load it instead.
Paul, the mainboard actual does a good deal of work - restores some of
the system (including the page tables?) and uses a special restart
protocol to energize the OS. This is the reason that hiberfil.sys cannot
be on any disk other than the system disk - the mainboard doesn't want
to be involved in OS-level disk naming. I tracked this down when I build
machines with SSD for system disks and huge memories. I wanted to move
the large file somewhere else but could not and the reason given was the
previous. Now that we have gone from BIOS to UEFI, it is time to change
the G_d D__n hibernate spec too.

I found this interesting:
http://www.pcreview.co.uk/threads/ho...-work.3956197/


How the machine knows to resume from hibernate is BIOS dependant.
There are two schemes.

In both schemes the RAM contents are written to a file called
hiberfil.sys.
In the first scheme, the BIOS checks for the presence of the
hiberfil.sys file on the hard disc and if it finds it, loads it into
RAM and then proceeds as though recovering from STANDBY. Once
recovered the file is deleted.

In the second scheme, the BIOS sets an internal flag that it has
hibernated, and thus loads hiberfil.sys if the flag is set, otherwise
it just boots normally even if the file is present. Some BIOSes report
an error if they can't find the hiberfil.sys file. Once recovered the
file is not necessarily deleted.

The first scheme has the feature that it will recover from
hibernate if the system disc is replaced by another that was
hibernated before it was removed even if the original was not.

M.I.5¾, Jan 21, 2010 #2
--
Like one of those who replied, my experience has been, in XP and
Vista, that the hiberfil is always there (once I've first hibernated,
that might mean)

In Vista, which seems to be a lot like Win7, it's there now, and the
dates are amazing:

Created: Wednesday, April 15, 2015, 2:30:37 PM
Modified Tuesday, October 20, 2015, 11:38:18 PM
Accessed: Wednesday, April 15, 2015, 2:30:37 PM

Created makes sense, because that's about when my friend's
brother-in-law wiped his data off the drive and iiuc reinstalled
Vista. That's when I got the computer but I didn't connect it until
Septermber. Well, I think I had to change a setting to allow
hibernate, so I don't really see how the date could be in April, but
it's the least of my concerns now.

Modified makes no sense. It's 4 days ago, but I hibernated late last
night, and once a day or two ago, and each time it restarted just
where I left off.
Accessed makes no sense either. For the same reason, but its date
goes back all the way to the same time the file was created.

I didn't pay such close attention to dates when XP was working. Some
day I'll get it working again, but right now outdoor chores take
precedence before it gets cold out.

The chipset does have state information, but we don't know
if any BIOS code checks it or not.

I looked up ICH5 Southbridge as an example, and it
has SLP_S3#, SLP_S4#, and SLP_S5# signals. These would
be used, for example, to decide whether the RAM should
receive standby power or not. In SLP_S4#, the RAM
should be cut off cold. So the enable pin on the standby
power source for the RAM, could well be tied to
one of those signals.

SLP_S4# would be hibernate, and the Intel doc claims
RAM would be powered down in that case. If the chipset
resumes, then that signal will still be present early
in BIOS operation, and if the BIOS wanted, it could
check it.

If all power was removed, that information might be lost. it
all depends on whether it is in the CMOS_well (powered by 3VSB),
or is part of some other power rail.

*******

The hibernate file is deleted if you do this:

powercfg -h off

If the OS is shutdown and hibernation is not involved,
the hiberfile remains. Just the header is modified to
represent the fact that it contains no valid information.
From a security perspective, the hiberfile could contain
all sorts of stuff, because it never really has to be
overwritten entirely. A "small" hibernation will not erase
bits of a "large" hibernation, so up near the end of the
hiberfile, you could find all sorts of ancient history.
If the hiberfile is 48GB in size, a user would notice
if there was some regular erasure procedure for it.
It would take forever to process. Users would complain
if it worked (securely) that way.

The pagefile is a different story, in that a registry
option is available to securely purge it, so the remains
of a session are not left in there. Short of doing

powercfg -h off
powercfg -h on

to create a brand new hiberfile, I don't know if it
has the same purge options as pagefile does. And
if you discard the hiberfile by doing the above
two commands, like all "deleted" files, only the pointer
to the clusters is removed. The clusters themselves are
not purged. Unless you specifically have a third-party
software (maybe Heidi Eraser).

I was reading the other day, that SSDs with TRIM, the
TRIM operation can clean the blocks before they
are put on the free_list. But even at SSD speeds, it
might take a while to do that if the whole drive
was freed up by deletion. The web site I was reading,
did a test, and their data recovery software could
still find a little bit of data, with no indication
how it was missed. (It could be stored in $MFT, but
they would need to have examined the LBAs involved to
figure out if that's how it happened. The $MFT is yet
another place for leakage.)

The whole OS leaks in the general sense, and "swatting
at flies" is not how you fix that. You cannot piecemeal
expect to clean up the leakage one item at a time.
A disk with whole_disk_encryption is how you want to
do it. The hard drive companies have threatened to make
that a standard feature for *all* drives, but since that
announcement, there has been no progress update on how
they hope to implement that (make it so malware
doesn't turn on encryption when your back is turned).

Paul

On Sat, 24 Oct 2015 23:39:47 -0400, Micky
wrote:


In Vista, which seems to be a lot like Win7, it's there now, and the
dates are amazing:

Created: Wednesday, April 15, 2015, 2:30:37 PM
Modified Tuesday, October 20, 2015, 11:38:18 PM
Accessed: Wednesday, April 15, 2015, 2:30:37 PM

Replying to my own post: During dinner it occurred to me that maybe
the dates are wrong because hiberfil.sys is modified and accessed
either after windows has closed or before it opens, so the normal
method for changing file info is not running.

But then the question arises, why is the modified date ONLY 4 days
ago. I didn't modify the file within windows, or even look at it, or
until a day ago at its properties\



Created makes sense, because that's about when my friend's
brother-in-law wiped his data off the drive and iiuc reinstalled
Vista. That's when I got the computer but I didn't connect it until
Septermber. Well, I think I had to change a setting to allow
hibernate, so I don't really see how the date could be in April, but
it's the least of my concerns now.

Modified makes no sense. It's 4 days ago, but I hibernated late last
night, and once a day or two ago, and each time it restarted just
where I left off.
Accessed makes no sense either. For the same reason, but its date
goes back all the way to the same time the file was created.

I didn't pay such close attention to dates when XP was working. Some
day I'll get it working again, but right now outdoor chores take
precedence before it gets cold out.

Micky wrote:
On Sat, 24 Oct 2015 23:39:47 -0400, Micky
wrote:

In Vista, which seems to be a lot like Win7, it's there now, and the
dates are amazing:

Created: Wednesday, April 15, 2015, 2:30:37 PM
Modified Tuesday, October 20, 2015, 11:38:18 PM
Accessed: Wednesday, April 15, 2015, 2:30:37 PM

Replying to my own post: During dinner it occurred to me that maybe
the dates are wrong because hiberfil.sys is modified and accessed
either after windows has closed or before it opens, so the normal
method for changing file info is not running.

But then the question arises, why is the modified date ONLY 4 days
ago. I didn't modify the file within windows, or even look at it, or
until a day ago at its properties\

When the OS starts writing out the body of the hiberfile,
the OS is already shut down at that point. The program
counter no longer visits Windows places. The code is in
a tight loop, copying memory, compressing it, and storing
it in the hiberfile. And this means the file system
is no longer running.

The hiberfile could be written at two points in time. After
the OS boots up, the OS could overwrite the header of the
hiberfile, preventing it from "looking valid". Then later,
if the user requests hibernation, the writing loop happens
after the OS is shutdown. The state of the OS is frozen,
so it would not be fair to go back and update some timestamps
on the file.

So the timestamp could be the last time the OS was required
to invalidate the hiberfile, by writing the header. This
would be right after recovering from hibernation, for example.
Maybe a cold boot doesn't need to do that ?

They could of course, cheat, and "touch" the hiberfile
just before the OS is frozen. And then every hibernation
attempt would be accompanied by semi-correct dates.

You'll have to correlate the date stamps you're seeing,
with how you're using the machine, to figure out how
it really works.

Paul

On Sun, 25 Oct 2015 02:28:59 -0400, Paul wrote:

Micky wrote:
On Sat, 24 Oct 2015 23:39:47 -0400, Micky
wrote:

In Vista, which seems to be a lot like Win7, it's there now, and the
dates are amazing:

Created: Wednesday, April 15, 2015, 2:30:37 PM
Modified Tuesday, October 20, 2015, 11:38:18 PM
Accessed: Wednesday, April 15, 2015, 2:30:37 PM

Replying to my own post: During dinner it occurred to me that maybe
the dates are wrong because hiberfil.sys is modified and accessed
either after windows has closed or before it opens, so the normal
method for changing file info is not running.

But then the question arises, why is the modified date ONLY 4 days
ago. I didn't modify the file within windows, or even look at it, or
until a day ago at its properties\

When the OS starts writing out the body of the hiberfile,
the OS is already shut down at that point. The program
counter no longer visits Windows places. The code is in
a tight loop, copying memory, compressing it, and storing
it in the hiberfile. And this means the file system
is no longer running.

The hiberfile could be written at two points in time. After
the OS boots up, the OS could overwrite the header of the
hiberfile, preventing it from "looking valid". Then later,

That's a thought I hadn't had.

if the user requests hibernation, the writing loop happens
after the OS is shutdown. The state of the OS is frozen,
so it would not be fair to go back and update some timestamps
on the file.

So the timestamp could be the last time the OS was required
to invalidate the hiberfile, by writing the header. This
would be right after recovering from hibernation, for example.
Maybe a cold boot doesn't need to do that ?

With this computer, every time I've booted after hibernation (except
maybe** once a couple weeks ago) it's not been a cold boot, but an
unhibernate, judging by the fact that it opened with programs already
open.

Certainly the one yesterday morning was like that.

So under your theory, the date should be yesterday morning. Other
than that, I like your theory.

**I say "maybe" because Vista, in its inimitable way, doesn't show a
progress bar when doing hibernation saving or restoring. In fact it's
totally black during almost all of the process, hibernating and
unhibernating. I guess MS figured the less we know the better.

They made things visible again with 7, 8 and 10, right?? Please?

I didn't pay nearly so much attention with XP, but I still hope to
have the chance to do so.

They could of course, cheat, and "touch" the hiberfile
just before the OS is frozen. And then every hibernation
attempt would be accompanied by semi-correct dates.

You'll have to correlate the date stamps you're seeing,
with how you're using the machine, to figure out how
it really works.

Paul

[Default] On Sun, 25 Oct 2015 16:34:28 -0400, in
microsoft.public.windowsxp.general Micky
wrote:


With this computer, every time I've booted after hibernation (except
maybe** once a couple weeks ago) it's not been a cold boot, but an
unhibernate, judging by the fact that it opened with programs already
open.

Certainly the one yesterday morning was like that.

So under your theory, the date should be yesterday morning. Other
than that, I like your theory.

**I say "maybe" because Vista, in its inimitable way, doesn't show a
progress bar when doing hibernation saving or restoring. In fact it's
totally black during almost all of the process, hibernating and
unhibernating. I guess MS figured the less we know the better.

Correcting myself, it does say, in Vista, for a little while, during
unhibernating, "Windows resuming", or something similar.

No progress bar and then it goes black for a while (when XP went black
for just a moment).

This is my error because I've gone back to a CRT monitor and it was
taking a while to warm up, plus it does go black when hibernating, so
I was ready to believe the worst.

I have a bigger than average CRT monitor, so it's going to be hard to
carry it downstairs. It was hard enough to carry it upstairs and that
was 6 years ago. I could throw it out the window, but there's
furniture in front of the window. If I wait until I'm 80, it will be
too heavy to carry down the stairs. I'd have to disassemble it, but
after 10 or 20 TVs, that's not as much fun as it used to be.

They made things visible again with 7, 8 and 10, right?? Please?

I didn't pay nearly so much attention with XP, but I still hope to
have the chance to do so.

Micky wrote:


I have a bigger than average CRT monitor, so it's going to be hard to
carry it downstairs. It was hard enough to carry it upstairs and that
was 6 years ago. I could throw it out the window, but there's
furniture in front of the window. If I wait until I'm 80, it will be
too heavy to carry down the stairs. I'd have to disassemble it, but
after 10 or 20 TVs, that's not as much fun as it used to be.

Hey, I've done that. I pulled an 85lb Trinitron out of the basement and
took it to the recycler. What a job getting it up the stairs.

I remember when I bought that thing new years ago. I got it out
in the parking lot, and pulled it out of the box. And put it
in the passenger seat, and put a seat belt around it. The empty
box went on the top of the car, on a roof rack.

Who says computing isn't good exercise ? :-)

Good times,
Paul

On 10/26/2015 1:05 AM, Paul wrote:
Micky wrote:


I have a bigger than average CRT monitor, so it's going to be hard to
carry it downstairs. It was hard enough to carry it upstairs and that
was 6 years ago. I could throw it out the window, but there's
furniture in front of the window. If I wait until I'm 80, it will be
too heavy to carry down the stairs. I'd have to disassemble it, but
after 10 or 20 TVs, that's not as much fun as it used to be.

Hey, I've done that. I pulled an 85lb Trinitron out of the basement and
took it to the recycler. What a job getting it up the stairs.

I remember when I bought that thing new years ago. I got it out
in the parking lot, and pulled it out of the box. And put it
in the passenger seat, and put a seat belt around it. The empty
box went on the top of the car, on a roof rack.

Who says computing isn't good exercise ? :-)

Good times,
Paul
LOL