The limitation and reason of EWF with a Hibernate Once/Resume Many Configuration

上篇文章What is the Differences Between Sleep/Standby and Hibernate提到会讲解一下为什么EWF在支持Hibernate会存在限制。我写这两篇文章原因就是我在学习微软WebCast视频的时候，讲课老师提到“为了支持Hibernate，EWF存在着限制，最好使用EWF保护所有的分区”，我当时并不明白为什么有这个限制，后来想到加密系统盘或者Swap分区，也存在Hibernate的问题，干脆一起研究一下。

1. Introduction

EWF 全称 Enhanced Write Filter (增强型写入过滤)，目的是为了保护介质（如硬盘，CF卡，U盘）上的操作系统和分区数据被篡改，也能提高介质的使用寿命。每次系统重启后，系统和分区数据完好无损，重启之前所有修改全部消失，除非管理员将这些修改提交（commit）到介质中。这种技术在银行、地铁、航空、图书馆的查询系统，网吧，游戏机等领域都有广泛的应用。

EWF原理：在文件系统层下面插入一层过滤驱动，把所有对介质的写操作重定向到Overlay层（in RAM, Registry or Disk），也就是下图中的EWF Volume；读取操作时可以从介质、Overlay层读取数据或者将两者数据集合起来，提交给上层的文件系统。

备注：

a. 读者可以通过下面文章进一步了解EWF

英文：http://msdn.microsoft.com/en-us/library/ms838511(WinEmbedded.5).aspx

中文：http://lzg-ad.blog.sohu.com/78062627.html

b. EWF位于文件系统下层，提供磁盘扇区级别的写保护。微软同时提供了一种叫做FBWF(File Based Write Filter)技术在文件级别提供写保护。FBWF也是一种过滤驱动，位于文件系统上层。这和加密技术提供磁盘扇区级别和文件级别的原理一样。

 

2. EWF with a Hibernate Once/Resume Many Configuration

EWF技术可以提供保护操作系统和分区数据功能。在实际的应用中，除了要求提供保护操作系统和分区数据功能外，也要求系统能够快速启动。系统快速启动功能有几种方式可以实现：

a. 裁剪和优化操作系统。

    系统启动过程中，尽可能的少读取数据和少启动无必要的服务；优化启动过程，提高CPU执行效率和读取数据的吞吐量，如各种Quick Boot技术。

b. 使用更好的硬件。比如用固态硬盘代替传统机械硬盘。

c. 使用休眠技术。比如Supend to RAM和Supend to Disk。

具体对应到Windows Embedded技术而言：

第一种情况，可以使用Windows Embedded工具定制/裁剪出专门的Embedded XP或Standard 7系统，加速启动过程。

第二种情况，更换硬件成本太高，一般应用可以不考虑。

第三种情况，使用Supend to RAM，系统启动更快。缺点也很明显，如果断电就没用了，并且上一次操作的数据会保存在RAM，不符合一些公共系统的要求。使用Supend to Disk（即Hibernate），启动稍微慢一点，但是没上面的缺点。

EWF with a Hibernate Once/Resume Many Configuration主要的意思是：在启用EWF之前，使用工具配置好Hibernate，然后再开启EWF保护。由于系统、分区数据和Hibernate文件都被保护，每次系统重启时，都是从同样内容的Hibernate文件启动，即提高了启动速度，也保证了系统每次启动的状态完全一致。但是存在着一个严重的问题，如果有一个分区没有被EWF保护，在启用EWF保护之前，由于这个分区的有关信息会被缓存到内存中，在配置Hibernate的时候，内存中的数据被保存到Hibernate文件中，当然也包括了未被EWF保护分区在内存的缓存信息。启用EWF保护之前，用户修改了这个未被EWF保护分区的内容，但是Hibernate文件仍然保存的是启用EWF保护之前的分区信息。再次重启后，Hibernate文件被加载到内存中，这时候内存中未被EWF保护分区的信息会和实际的分区中的内容不一致，可能引起潜在的问题。

解决方法之一，在创建Hibernate文件之前，Lock和Dismount未被EWF保护分区，在系统重启之后，Unlock这个分区，系统会自动发现和加载这个分区。

下面是英文原文：

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 creates 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.

To lock and dismount a volume, you must create an application that calls the DeviceIoControl function. This function sends control codes directly to the file system. By passing the parameters FSCTL_LOCK_VOLUME and FSCTL_DISMOUNT_VOLUME to the function, you can lock and dismount the volume before the hibernation file is created.

To allow the system to rediscover the volume, the volume first must be unlocked immediately after the system boots. . Use the DeviceIoControl function with the dwIoControlCode parameter FS_UNLOCK_VOLUME.

After the volume is unlocked, the system automatically rediscovers the volume and makes it accessible. Because the hibernation file does not include any information about the volume, you must unlock the volume on every reboot.

参考文章：

http://msdn.microsoft.com/en-us/library/dd143253(WinEmbedded.5).aspx