FBWF Design and Test Considerations (Standard 8)


Review the design and test considerations for devices using File-Based Write Filter (FBWF) for Windows Embedded 8 Standard (Standard 8).

FBWF enables Standard 8 to operate in a stateless mode. This means that all changes to the system are discarded on system shutdown and restart. In addition, FBWF enables Standard 8 to start from read-only media.

When you design and test a device that uses FBWF, consider the following scenarios.

Effective Disk Size

The effective disk size of the protected volume is limited by the overlay settings configured in FBWF. This depends on the system RAM and the architecture of the system. The constraints for overlay size based on architecture are as follows:

  • 1 GB for x86
  • Maximum system RAM for x64

The protected partitions share a single FBWF overlay. This also means that the new effective disk size is shared by all partitions protected by FBWF.

If longer system uptime is required, all unnecessary disk writes on protected volumes should be removed. You can use FBWF Manager (Fbwfmgr.exe) or the FbwfFindFirstEx and FbwfFindNextEx APIs to implement a custom tool for this purpose. Regardless of the tool that you select, the process to remove disk writes is as follows:

  1. Enable FBWF, add the system volume to the protected list, and restart the system.
  2. Perform the typical system-usage scenarios.
  3. Use the fbwfmgr /overlaydetail command, or the equivalent functionality using the APIs, to see what writes have been made to the protected list.
  4. Remove these writes by removing/disabling services that are making the writes, redirecting the writes elsewhere.

The data generated should help you estimate the time that is required to fill up the overlay, and thereby predict uptime for your device.

Application Compatibility

FBWF is a file-system driver and supports most NTFS file system functionality to remain completely transparent to user-mode applications. However, by design FBWF does not support certain aspects of NTFS file system that might affect some user-mode applications. To discover if your application is affected, application-compatibility tests are necessary. This is especially important for applications that have a kernel-mode component; for example, antivirus applications.

If any one of your scenarios fails, make sure that this is not because of a missing dependency. Disable FBWF on the system volume and run your test again. If the scenario works with FBWF disabled, and does not work with FBWF enabled, you might have an application-compatibility issue. To isolate such 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 it is possible, add this folder to the write-through list and see whether the problem goes away.

Stateless Operation and Credentials

Stateless operation is frequently required for embedded systems. However, it can also affect device functionality because of purging of system information. If your device will be part of a domain, add Registry Filter to the image and test these 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.

FBWF and System Security

Stateless operation does not mean that embedded systems do not require a security solution. We recommend that you use a separate antivirus application to protect the system. FBWF was not designed to protect against virus attacks, and it does not stop virus infections from propagating over the network. Also, make sure that you test your security applications together with FBWF to avoid application-compatibility issues.

FBWF and Removable Devices

FBWF supports protecting removable devices. However, removable flash devices should be added to the protected list while FBWF is disabled. The first time that a removable device is plugged in, it is installed and initialized. The initialization process creates registry entries; if the system is protected by FBWF, these registry entries are lost on restart and must be recreated. Reinstalling the removable device removes it from the protected list.

FBWF and Path Length

If FBWF is used with a path length of over 240 characters or more, it may exceed the maximum Windows path length of 256 characters. We recommend using path lengths of less than 240 characters.

See Also


FBWF Concepts