EWF Design and Test Considerations (Standard 8)

Article
09/29/2016

12/5/2014

Review the design and test considerations for devices using Enhanced Write Filter (EWF) for Windows Embedded 8 Standard (Standard 8).

This topic includes feature descriptions and scenarios that might help you resolve unwanted and unknown feature behavior. In addition, it can help you identify the first practical steps to take when receiving calls from end users and customers experiencing problems with a device.

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. 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 in 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:

Build a run-time image with EWF that has volumes added to its protected list.
Enable EWF on the system volume, and restart the system.
Perform the typical system-usage scenarios.
Use Application Verifier or BoundsChecker to find memory leaks.
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.
Remove writes by removing or disabling services that are making the writes, and redirecting them elsewhere.

EWF and FBWF

Standard 8 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 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 could cause unexpected or unknown behavior.

Apply an update to an EWF-protected image

Use EWF Manager to disable the overlay by typing the following command:
- For RAM mode:
```
ewfmgr.exe c: -disable
```
- For RAM REG mode:
```
ewfmgr.exe 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.
Restart the system.
Install the application or update.
Wait for the installation to complete and restart the system, if it is required.
Re-enable the EWF overlay by typing the following command:
```
ewfmgr.exe c: -enable
```
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.