Working with File-Based Write Filter (Standard 7 SP1)

12/5/2014

Ff793759.collapse(en-US,WinEmbedded.60).gifSummary

This technical article discusses scenarios that you should consider when you design and test a device that uses File-Based Write Filter (FBWF).

FBWF is a File System Minifilter Driver that functions as a file I/O redirector to send all disk writes to a memory-based overlay. These cached writes can then be selectively committed to the actual partition, or flushed by a system restart. FBWF applies I/O redirection in a way that is completely transparent to user-mode applications. This also means that the disk I/O on a protected volume is limited to the physical RAM available on the system. Because changes that are made to the system are not persisted, you should consider design and test scenarios that result when necessary system information is not saved, especially on networked computers.

For more information, see FBWF Operation.

FBWF enables Standard 7 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 7 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 amd64

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 I/O 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 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 functionality to remain completely transparent to user-mode applications. However, by design FBWF does not support certain aspects of NTFS 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 of your scenarios fail, 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, then 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. 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 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 BitLocker

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

What you have learned

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

For more information about how to use FBWF, see File-Based Write Filter (FBWF).

Show: