Protecting Multiple Volumes in a Hibernate Once/Resume Many Configuration
One of the limitations of implementing a Hibernate Once/Resume Many environment on your device is that all of the partitions on your system must be protected by EWF. Because the file system caches information about each partition on the system, that file system information is loaded when the system boots from the hibernation file. If a write is made to the system and that write is not captured in the hibernation file, the next time the system boots, the hibernation file will not match the contents of the partition and the system may become corrupt.
For example, on a system with two partition, C drive and D drive, you enable EWF. However, EWF is only enabled for C drive. D drive is not protected by EWF.
When you create the hibernation file, information about the contents of C and D drives are included in the hibernation file. This is because the file system caches information about the attached volumes in the system.
When the system boots, it loads information in the hibernation file about both C and D drives.
You then delete several files from D drive. Because D drive is not protected by EWF, these files are deleted from the system.
The system reboots, and loads information from the hibernation file. Because the hibernation file still includes cached information about the contents of D drive, that information is loaded into RAM. Because the files that you deleted from D drive no longer exist in the system, the contents of the system's RAM and the contents of D drive do not match. There is now potential for the system to become corrupted. This is why EWF must protect all partitions in a Hibernate Once/Resume Many environment.
However, it is possible to flush the contents of a non-boot volume from system cache by unmounting the volume before you create the hibernation file.
Dismounting Volumes Before Hibernation
To ensure that the write cache for a volume is cleared before you create the hibernation file, you must dismount the volume. When a volume is dismounted, the write cache for that volume is flushed from system memory. It is then safe to create the hibernation file. By dismounting any volumes you do not want protected, you can ensure that any write cache data from the system is not written to the hibernation file.
Note This does not guarantee that applications do not have cached state information from the dismounted volumes. It is the responsibility of the designer of the Windows XP Embedded-based system to monitor applications and verify that they do not contain any state information about the volume.
When the system starts from the hibernation file, no information is loaded about the volumes you dismounted. The system rediscovers additional volumes each and every time the system boots from the hibernation file. Because there is no information about the volume that is loaded from the hibernation file, you can safely write to an unprotected volume.
To dismount a volume, you can create an application that will lock and dismount the volume, and then create the hibernation file.
See Also
Creating an Unprotected Volume in a Hibernate Once/Resume Many Environment | Programmatically Dismounting Volumes
Last updated on Wednesday, October 18, 2006
© 2006 Microsoft Corporation. All rights reserved.