Assessing Risk in Enhanced Write Filter (Standard 7 SP1)

  • Article

12/5/2014

Summary

This technical article discusses scenarios that you should consider when you design and test a device that uses Enhanced Write Filter (EWF).

Introduction

Design and Test Considerations

  • System Requirements
  • Overlay Size and Uptime
  • EWF and HORM
  • EWF and FBWF
  • EWF and Registry Filter
  • EWF and BitLocker
  • Servicing EWF-Protected Run-Time Images
  • Stateless Operation and Credentials
  • Application Compatibility

Conclusion

Introduction

EWF is a sector-based lower filter driver in the volume stack that intercepts and directs all writes to RAM before they reach the underlying volume. It supports the following scenarios:

  • Runs from read-only media.
  • Improves operating system (OS) resilience and reliability.
  • Enables stateless operation.
  • Reduces or eliminates wear on write-sensitive media, such as Compact Flash devices.

Because changes that are made to the system are not persisted, you should consider design and test scenarios that accommodate system information that is not saved, especially on networked computers.

Note

Windows Embedded Standard 7 only supports Enhanced Write Filter RAM and RAM REG modes. Disk mode is not available.

This technical article includes feature descriptions and scenarios that might help you resolve unwanted and unknown feature behavior. In addition, it can help embedded product-support personal by identifying the first practical steps to take when receiving calls from end-users and customers experiencing problems with a device.

Design and Test Considerations

You should consider the following scenarios when you design and test a device protected by EWF.

System Requirements

EWF does not protect dynamic disks; all protected volumes must be configured as basic disks. In addition, EWF does not protect removable disks.

EWF is supported only on master boot record (MBR) partitioned disks. Disks that use GUID partition table (GPT) partitioning are not supported by EWF in Standard 7. Therefore, Extensible Firmware Interface (EFI) systems that require GPT partitioning are not supported for use with EWF.

When EWF RAM mode is configured during EWF installation, it creates a small partition on the media (EWF volume). There is a risk of installation failure if the system does not meet the following requirements:

  • Verify that the disk on which you configure EWF has no more than three primary partitions.
  • If you are using logical partitions, free space for EWF must be contained within the extended partition.

We recommend that you keep your disk-partition configurations simple. Complex disk partitioning can sometimes prevent EWF from setting up correctly. If it is possible, use a single disk that has a single primary partition on it when you configure EWF for the first time.

Overlay Size and Uptime

For EWF RAM-based overlays, writes made to EWF-protected volumes are redirected to the RAM overlay. Therefore, the effective disk space available on the protected volume is limited by overlay size. The RAM that is required for RAM-based EWF depends on the configuration of the run-time image, system architecture, and the number of applications that are running. The EWF overlay is shared among all protected volumes and is not pre-allocated. As your applications write to the protected volume, EWF continues to use free RAM until it runs out of memory. If you have an application that is making many writes to your protected volume, EWF might use all available free memory.

We recommend that you follow these steps to make sure EWF is the correct choice for your run-time image, and to estimate the time that is required to fill the overlay size, thereby predicting the system uptime:

  1. Build a run-time image with EWF that has volumes added to its protected list.
  2. Enable EWF on the system volume, and restart the system.
  3. Perform the typical system-usage scenarios.
  4. Use Application Verifier or BoundsChecker to find memory leaks.
  5. Use ewfmgr.exe C: (where C is the system volume) to determine the amount of memory used by EWF, and to compare it with the available RAM. We recommend defining a safe margin of EWF overlay usage (for example, 80 percent), compared to the available RAM.
  6. Remove writes by removing or disabling services that are making the writes, and redirecting them elsewhere.

EWF and HORM

Using Hibernate Once Resume Many (HORM) can significantly improve start time in certain scenarios that require repeated booting to a predefined state. It lets you define the state of a system by starting with specific applications and services running. To make additional improvements to the performance of your device, eliminate any nonessential device drivers and services.

HORM, when configured incorrectly, can cause system corruption or failure depending on the system configuration. We recommend that you read and understand the documentation for EWF and HORM. For more information, see Hibernation and EWF.

Here are several checkpoints to help you design and test devices with EWF and HORM:

  • If the system has more than one fixed volume, all the fixed volumes on the system must be protected by EWF. This is because the file system holds cached information about each volume in memory, and that cached information is saved within the hibernation file.
  • If you plan to have unprotected volumes that use EWF with HORM, you must unmount the unprotected volumes before you create the hibernation file.
  • We recommend that you do not use Registry Filter when EWF and HORM are enabled, to avoid system corruption.

EWF and FBWF

Standard 7 provides File-Based Write Filter (FBWF) that operates at the file level, compared to EWF that operates at the sector level. Some system designers use both write filters together in the same OS image. However, this might pose a risk if not used correctly. For example, you must avoid protecting the same volume with both filters.

EWF and Registry Filter

It is common to use EWF with Registry Filter. This lets you persist specific registry keys while protecting the rest of the OS. In addition, it is common to use EWF to start from a hibernation file (HORM) to help improve system start time.

We recommend that you avoid using Registry Filter when HORM is active. After HORM is enabled, it requires the underlying disk to remain unmodified. Registry Filter commits its RamDisk contents to disk whenever a protected key changes. This causes changes to the underlying disk, and can cause file-system corruption.

EWF and BitLocker

BitLocker is a full-volume encryption feature that is implemented, in part, as a volume-filter driver. BitLocker is similar to EWF in the OS device stack. BitLocker encryption or decryption operations should not run on a volume where EWF is enabled. This is required to avoid filling up the overlay. BitLocker encryption and decryption operations must be completed with EWF disabled.

Servicing EWF-Protected Run-Time Images

Because EWF redirects write-access to a volume, you should follow these steps when you want to install an application or update your run-time image. You should avoid updating a system when EWF is enabled because it might result in unexpected or unknown behavior.

Apply an update to an EWF-protected image

  1. Use EWF Manager to disable the overlay by typing the following command:

    • For RAM mode:

      ewfmgr c: -disable

    • For RAM REG mode:

      ewfmgr c: -commitanddisable

      Note

      Because RAM REG mode stores EWF configuration data in the registry, you must commit the disable change to the protected run-time image.

  2. Restart the system.

  3. Install the application or update.

  4. Wait for the installation to complete and restart the system, if required.

  5. Re-enable the EWF overlay by typing the following command:

    ewfmgr c: -enable

  6. Restart the system to enable the EWF overlay.

Stateless Operation and Credentials

Stateless operation is frequently required for embedded systems. However, it can also affect device functionality because of the purging of system information. When a system loses its state on restart, information such as network credentials, security certificate updates, and Group Policy setting updates are lost and your device might be locked out of the domain. If your device will be part of a domain, add Registry Filter to the image and test the scenarios before deployment.

The following sources of information can be lost because of stateless operation:

  • User/Domain/Network/Wireless credentials
  • Event logs/crash dumps
  • Device-servicing information and image updates (Windows Update and third-party updates)
  • User settings/documents that were created on the protected volumes

We recommend that you verify the end-to-end scenarios for your device and take steps to avoid issues caused by stateless operation.

Application Compatibility

EWF is a sector-based lower filter driver in the volume stack and fully supports NFTS. If your application has kernel-mode components used together with EWF (for example, antivirus applications), you must test the application compatibility with EWF.

The most common application-compatibility failure can be caused by a missing dependency in the run-time image. Determine any missing dependencies, rebuild the run-time image, and rerun the tests.

If your scenario works as expected when EWF is disabled, but fails when EWF is enabled, you might have an application-compatibility issue. To isolate issues related to disk I/O, use tools such as Process Monitor to see which I/O calls (call purpose and files/folders names) are failing. If possible, add this folder to the write-through list and see whether the problem goes away.

Conclusion

What you have learned

By using the information in this article, you should have a better understanding of the design and test scenarios when you use EWF with your device.

For more information about how to use EWF, see Enhanced Write Filter with HORM.