Slobodan Brcin said:
Leonid,
I don't know at what driver level hiber file support is implemented.
But if hiber file is accessed trough file system driver and RAM EWF is
active and protecting partition that contains hiber file then I don't see
how hiber file is written to the disk.
All changes should be stored in RAM not on disk.
But for sake of argument let say that hiber file can be written to disk (if
hiber support uses RAW access to disk and bypass EWF then this would be
possible).
Consider:
1. You start your device normally.
2. Device boots (EWF protect C
3. Some files are changed and written to RAM overlay. physical disk content
is unchanged.
4. At some point you hibernate.
- Memory content is written to disk.
- There is possibility that some info on C: FS state is written also to
hiber file and some other infos as well.
5. You try to boot again.
ntldr tries to verify FS integrity of boot partition, and some written data
in hiber file.
They are different, because ntldr sees physical fs state as it was during
the first boot, but state stored in hiber file during the hibernation is
different since it contains state of FS when EWF was active.
6. Check fails and you have error reported.
This is all hypothetical, since I don't use hibernation so I have not
investigated how this works.
Someone else could have better idea, how things are implemented.
Regards,
Slobodan
Thank you, Slobodan for your answer.
At this time I did some tests and found several tips about
hiberfil.sys in XP news group.
I found two important tips:
The first one is:
- "During hibernation (or crashdump for that matter) the scsi miniport
driver
that is supporting the boot device gets "re-started". By this I mean
that
the miniport driver's DriverEntry routine will be called which will
result
in a call the ScsiPortInitialize, HwFindAdapter, HwInitialize,...
Also during hibernation (or crashdump) the scsiport driver
(scsiport.sys)
which controls the miniport driver during normal system operation is
replaced by the diskdump driver (diskdump.sys). I don't know the
mechanics of how scsiport and diskdump communicate to perform
this switch, I just know that it happens.
Another tidbit, during hibernation (or crashdump) the miniport does
not
run in a truely interrupt driven fashion. The diskdump driver
simulates
interrupt driven behavior by periodically calling the miniport's
HwInterrupt
routine".
This tip explains that hibernation uses the same mechanism as memory
dump in case BSOD is occurred.
The second one is:
-"During hibernation, only the driver for system disk device
(atapi.sys or
some other scsi miniport driver) will be loaded.
No file system driver (ntfs.sys, etc), disk class driver (disk.sys)
will not
be started.
The driver stack during hibernation/crash is totally different from
the
normal case.
During hibernation, diskdump.sys will be loaded as name of
hiber_diskdump.sys. atapi.sys will be loaded as name of
hiber_atapi.sys.
diskdump is a simplified version of scsiport.sys. After the dump
driver
stack is established, Windows will dump memory through diskdump+atapi
directly, no other driver is used".
It means that hibernation file is not under EWF control at this time
(during dump). The wake-up from this file restores exactly the same
OS condition, incuding EWF and overlay state before hibernation (NO
PROTECTION).
With EWF is enabled the hiberfil.sys that we can see in windows
explorer has time/date stamp of first creation (enable hibernation in
power options), even further several hibernation commands were
performed. Time/date of this file may be changed only after EWF commit
command is executed.
I think that ntldr not only looking for hiberfil.sys, but also checks
"resume" bit (bits combination or whatever) to be sure about last
power state changes. After resuming from this file this bit (bits)
must be cleared. But because of EWF is active this bit is not cleared.
(This is all hypothetical)
When I do immediate shutdown (Power off without hibernation command)
the new hiberfil.sys is not created. On Power on ntldr finds that
resume bit is active and tries to resume from this file, but fails on
another checks.(see article below)
According to:
Microsoft Knowledge Base Article - 294427
Windows XP Stops Responding at the Welcome Screen
This article was previously published under Q294427
SYMPTOMS
When you restart Windows XP and the Welcome screen is displayed, your
computer may stop responding: neither the keyboard nor the mouse work.
When you restart your computer again using the F8 key, you may receive
the following error message:
System restart has been paused:
Continue with system restart.
Delete restoration data and proceed to system boot menu.
CAUSE
This problem can occur when your computer enters into the Hibernate
mode and accesses a corrupted memory snapshot.
RESOLUTION
To resolve this problem, select the Delete restoration data and
proceed to system boot menu option which enables the computer to
perform a normal restart, instead of performing the restoration
process while the computer is in Hibernate mode.
STATUS
Microsoft has confirmed that this is a problem in the Microsoft
products that are listed at the beginning of this article.
MORE INFORMATION
The Hibernate mode is a Power Management mode which can store the
state of your computer in its primary mass storage device. The
Hibernate mode is useful when you leave your computer in Standby mode
for an extended period of time.
The information in this article applies to:
Microsoft Windows XP Home Edition
Microsoft Windows XP Professional
From customers experience in case of "corrupted memory snapshot" and
selecting the second option "Continue with system restart" the
computer just keeps looping and gives the same options during an
attempted restart.
But in my case it always successfully continue the restoration with
side effect:
5 Min later after restoration, the computer hibernates itself without
my request.
It means that hiberfil.sys is not really corrupted, but doesn't pass
some integrity checks by ntldr.
Possible there is no information about last power state (or what
else?) because of immediate power off.
Sorry for my long post. But it's really important for my project to
save power of battery from one side and usage of fast boot, protected
HD and possibility to immediate shut down from another side.
Unfortunately, my computer doesn't supoort ACPI S3 (by design) mode
(only S1) and it's power comsumption in S1 is about 4W that is not
acceptable for battery mode.
Is somebody know the hiberfil.sys structure?
Any ideas are welcome.
