Designing Scenarios with New File-Based Write Filter

Fractal Realms series. Backdrop of fractal elements, grids and symbols on the subject of education, science and technology

Windows XP Embedded Service Pack 2 Feature Pack 2007 shipped with a new embedded enabling feature (EEF) called file-based write filter (FBWF). FBWF provides the necessary write filtering capability to ensure a robust embedded system. With a servicing and configuration feature set, the embedded developer can fine-tune his or her devices to enable their scenarios. This new EEF provides stateless protection of solid-state devices with user-controlled file protection. For embedded, the stateless protection is critical for OS resiliency and reliability. Additionally, it helps with device wear from constant writes. The ability to selectively protect some files and not others is a differentiating feature of FBWF.

FBWF performs stateless operation by redirecting writes to a cache in RAM. The cache can be thought of as an overlay on top of the media where the composite view is a combination of the contents on disk and the RAM overlay cache. On system reboots, the RAM overlay is discarded so the operating system is left in a pristine state. Figure 1 shows the composite view of modified files and new files in the cache.

Since FBWF hooks in at the file level, it can perform intelligent filtering based on files, folders or any file system data structures. Basically a user can selectively choose to not protect files by adding them to a “write-through list.” All files on a protected volume are protected by default. Additionally, FBWF enables “file commits,” which can bypass the protection. These features and others can be used to advantage in embedded scenarios.


Reduce Multiple Partition Devices to One

Typical embedded devices contain multiple partitions to separate the OS and data. This separation is required to protect the OS but allow writes to the data. However, it results in wasted space and increases complexity for imaging. This can be solved if the same partition can be used to hold the OS and data but still provide protection boundaries.

For example, developing a media playback device requires two partitions. One contains the OS allowing stateless operation by protecting against writes. The second partition holds the media files, which can be downloaded from the Internet and saved. The media files need to persist across reboots. The OS partition will need some buffer room to allow for updates and system temporary files. This is wasted space that can otherwise be used for the media files. The media files can only be written to the second partition. During the development process, you will find more and more files will need to go on the second partition and the need to repartition the device and reevaluate partition sizes can be difficult.

FBWF solves this problem by adding a folder for the media files to the write-through list. Now one single partition can be used for both OS and data. The OS is protected against writes while media files persist across reboots. This makes imaging a simple procedure avoiding complex partitioning operations or a sector-based imaging tool. Additionally, the total free space is flexible and can be used to update the OS or it can be used to save more media files. Figure 2 depicts such a system using FBWF, which protects the OS but allows writes to the media files.


Debugging Involves Log Files and System Events.

Write protecting the OS volume means application log files and event files are not propagated across reboots. This makes it difficult to diagnose issues if the machine is rebooted. The fix is to allow writes to these special files to persist.

The event log files are great to check for application and system faults. These are located at c:windowssystem32config with filenames ending in .evt. Add these files to the write-through list and events can be analyzed to access the health of a system over time. Also, if you are trying to diagnose setup or PNP issues, c:windowssetupapi.log is a good candidate to add to the write-through list. Developers can also add their own log files to help them diagnose their applications.


Application Updates Without Reboot

Rebooting is a painful and slow process for customers. It puts the machine out of use causing delay for the customer, and the boot process display itself is not the most appealing. However since write filters prevent writes from persisting, they must be disabled before performing an application update. After the update is performed, another reboot is required to re-enable the write filter.

FBWF has the “File Commit” functionality allowing single files to be committed to a protected volume. The commit is immediate and persists through reboots. If the file is not in use, updating an application is as simple as downloading the new application and calling FBWF to commit.

An added option is to do one commit after all writes are completed. Say you have some configuration file that is written throughout the application usage numerous times. These writes go to the FBWF cache. Once the final write is completed and the application exits, the whole file can be committed in one operation. This can save wear and tear to the storage device. Depending on the scenario, this may be the desired behavior instead of adding it to the write-through list. You can think of the FBWF cache as your temporary storage.

This solution can be used in many other scenarios. For example updating virus signatures that are frequently released, or updating the database which holds customer information. For enterprise environments, running SMS is an important mechanism to update a device. SMS inventories the system and may do so on every reboot if state information is not persisted across reboots. Adding SMS directories to the write-through list solves this problem.


Registry Filter and Limitation on HKCU.

Write filters prevent changes to the registry hive from persisting, and FBWF is no different. There are many scenarios where persisting registry keys will enable important scenarios. The Registry filter component is preset to allow keys to enable terminal server licensing and keys to enable domain join participation. FBWF cannot selectively enable write-through to individual keys. It can only preserve the whole registry hive file, meaning all keys within a hive will be permanently saved. So FBWF must also rely on the registry filter for this feature.

There is one set of keys that are currently not handled by the registry filter. These are the HKey Current User (HKCU) keys. These keys are loaded too late in the boot process to be protected by the registry filter. However, some applications save their keys in this location so users can have their own individualized settings. FBWF can be used to allow writes to individual user hives and allow keys to persist. Preserving the whole user hive may actually be desirable for maintaining per-user states on the device.


Use FBWF API to Integrate with an Application

Embedded devices are usually developed for a single purpose, for example, a Point of Service device, a game machine, a robotic controller or some other specific function. This also means writing a custom application that performs all operations necessary to carry out this purpose. The application may also need to apply updates to the device or configure FBWF in a seamless experience for the user.

The File-Based Write Filter Manager provides a command line tool for embedded developers to quickly integrate and prototype FBWF with their embedded devices. This is great for design time use, but with the FBWF user mode APIs, tight integration can be enabled within the application.

For configuration, the comprehensive API allows all settings such as cache memory type, the write-through list and size display modes to be changed. For complex updates to the device, you can also disable and enable the device programmatically. Allowing applications to query memory usage and cache contents also facilitates device management. The application can watch memory consumption and force reboots periodically to free up memory. This can allow for improved device robustness. As well, files can be committed programmatically to update the device intelligently avoiding reboots. The API is programmed via a supplied header and library.

Microsoft,
Redmond, WA.
(206) 882-8080.
[www.microsoft.com].