Improving Windows Embedded Standard 7 (WES7) Robustness

Updated Nov 6, 2020

National Instrument's Touch Panel Computers (TPCs) and WES7 CompactRIO and CompactDAQ targets are ideal for high-temperature, rugged environments. These types of environments can lead to questionable power conditions and uncertain power loss conditions. Unlike our real-time operating systems, Windows is more susceptible to disk corruption when power is lost during operation. This tutorial discusses best practices for improving the robustness on WES7 targets.

Enhanced Write Filtering (EWF)

EWF is a useful Microsoft Windows feature built into National Instrument's WES7 images that allows the ability to protect a volume from write access. Instead of writing directly to disk, disk writes are redirected into RAM (EWF Overlay). Once the files are in RAM, you have the ability to commit these file writes to disk through the use of the LabVIEW API if you are using TPC-22xx WES7 target, or from the command line if using any other WES7 target. If you do not commit writes that have been stored in RAM and the unit is powered down or power is lost, the data will not persist.

A major benefit of EWF is that it can extend the life of flash media. Flash-based storage media has a finite number of erase cycles before erase blocks wear out; this means that there is a finite life span for a solid-state drive. Since EWF redirects all file writes into RAM temporarily, and you have to commit these changes for the writes to actually be written to disk, write filtering can significantly decrease the amount of data being written to disk; thus, extending the life span of your media. The TPC-22xx product line have CompactFlash cards that are removable and replaceable, but our CompactRIO and CompactDAQ products also have flash-based storage ranging from CFast cards to PCB-soldered solid-state storage. Please consult the Operating Instructions and Specifications Guide of the target you wish to use to find out more information about drive sizes.

EWF can also help protect against unintended or malicious changes to your system. If a virus or malware is installed, it will be written to the RAM overlay. Unless you commit the overlay to disk, the malicious software will not be written to disk. Thus, upon next reboot, the malicious software will not persist. EWF is not meant to replace anti-virus or malware protection software; rather, it is meant as an additional level of security.

The features of EWF are also beneficial in preventing accidental tampering of your system. For instance, say an application is deployed in a factory and a user of the application alters some of the files or configuration data -- this could lead to an assembly line shutting down. The user could simply reboot the target to return back to a functional state. Ideally, the application would prevent accidental tampering. Figure 1 illustrates a high-level view of the architecture for EWF.

Figure 1. Overview of EWF architecture.

A task that is not ideal for EWF is data logging. Since you must make a commit to log everything written in RAM to disk, this opens up the possibility of committing malicious software or corruptions to disk as well. If you application requires data logging, it is recommended that you create a new partition that will be used strictly for log data. Other options are to used removable media devices or log to a network location. Since EWF is based on a a partition basis, you can have your operating system on your primary partition that is protected by write filtering, and you can have a second partition for storing data that needs to persist between reboots or power failures. CompactDAQ is a good example where this could be put to use.

Previous to LabVIEW 2014, the LabVIEW Touch Panel Module installs a Write Filter API that integrates with Window's EWF. In LabVIEW 2014 and later, the Touch Panel Module has been integrated into the LabVIEW Development System. Note that the LabVIEW API is specific to our TPC-2206, TPC-2212, and TPC-2215 WES7 products and is not compatible with CompactRIO or CompactDAQ targets. You can access this API by:

a.     Create a new LabVIEW Project.

b.     Right-click on the Project and add a touch panel target to your project:

Figure 2. LabVIEW Targets and Devices showing that the TPC-22xx targets are now built into LabVIEW 2014.

c.     You can then open a VI for the touch panel and navigate to Programming » File I/O » Advanced File Functions » Write Filters » Enhanced Write Filter to view all of the available EWF functions within the API. Each function has Context Help associated with it. You can also reference Microsoft's documentation found in the Resources section of this document.

Figure 3. LabVIEW Enhanced Write Filter palette.

For EWF support for WES7 on CompactRIO and CompactDAQ targets you must use the command line. Microsoft has full documentation that can be found in the Resources section of this document. Listed below are few functions that will allow for enabling EWF.

To view the EWF status of all volumes on your system, you can open up the command prompt as an administrator and type the following:

ewfmgr -all

This command returns the volume configuration for all volumes, or partitions, on your system. Figure 4 illustrates an example output of this command:

Figure 4. Command prompt showing the results of the EWF Manager.

You can see that there are two partions: C: and D:. To create multiple partitions on a WES7 target, you must first shrink your current volume (See Shrink a Basic Volume). You can then go to Disk Manager and create a new partition with the newly unutilized space.

Consider a data logging application. The primary partition stores the operating system; therefore, you want to enable EWF to protect this volume. The secondary partition is going to be used to stored log data so it must be left unprotected. To enable EWF on the primary drive (C:), type the following command:

ewfmgr C: -enable

Once this command has been executed, a restart will be required before the EWF settings take effect. Now the primary partition will be protected by EWF while the secondary partition is free to be written to. This significantly lowers the risk of operating system corruption as long as minimal commits are being executed on the primary partition. Figure 5 illustrates an example output of the enable command:

Figure 5. Command prompt showing the results of enabling EWF on the C: partition.


Hibernate Once, Resume Many (HORM)

EWF has another useful feature -- HORM. When HORM is configured and enabled, the system creates a hibernation image that persists across reboots and power cycles. Because the system loads to a static safe state every boot, all disk volumes on the system must remain in a stat state and EWF must be enabled.

When HORM is enabled, the system resume from hibernation on each boot instead of booting through the standard Windows startup process. HORM has several benefits. The first is that since the system is always booting from a fixed, non-changeable hibernation image, this mitigates the risk of any virus or malware persisting between reboots or power cycles.

As seen in Figure 3, LabVIEW 2014 and later has an Enable HORM VI built into the palette set for TPC-22xx targets to use. Prior to LabVIEW 2014, this feature was built into the LabVIEW Touch Panel Module.

HORM inherits all limitations of EWF, including the fact that it is not ideal for data logging. Log data should be stored on removable media or via the network. One great use case for HORM is a kiosk-type application where you need a highly reliable application that is not susceptible to malicious software and does not need to be changed frequently.

Note that HORM is only supported on TPC-22xx devices and not WES7 CompactRIO or CompactDAQ targets.

If you would like to enable HORM, here the commands that need to be executed:

a.     Once EWF has been enabled (see above), you then need to enable hibernation on your device. Type the following in the command prompt as an administrator:

powercfg /h on

b.     To enable HORM, you will need to use the EWF Manager for configuration or the LabVIEW API. Here is an example of the command to enable HORM through EWF Manager:

ewfmgr C: -activatehorm

Figure 6. Command prompt output after HORM activation.

c.     Open any applications and start any processes that need to be running on the system when it resumes from hibernation.

d.     Hibernate the system by executing the following in the command prompt:

shutdown /h

e.     Open a command prompt and type the following to verify that HORM is active:



File-Based Write Filtering (FBWF)

FBWF is another option for write protection on WES7. It is similar to EWF in that it buffers any write operations into RAM, but the major difference is that EWF protects an entire volume while FBWF protects individual files and directories. FBWF can be used to protect an entire volume, but exclusions can be added to the file system and registry keys. In short, FBWF has the flexibility to protect the disk at the file and directory level as opposed to the volume level as seen in EWF.

Disk writes are deferred into RAM until a proper shutdown or user command is given, while other file directories that are excluded operate under Window's standard read/write model. This allows for protection of critical operating system directories while allowing data to be logged to disk as expected. Due to the nature of FBWF, it has less overhead for deferred writes as you can protect only the directories and files that are critical to device operation. This added flexibility also opens up the opportunity to create less protection by creating exclusions to important parts of the disk.

Therefore, in the event of a power loss, the data logged to an FBWF-excluded directory is not lost because it was in an unprotected location. The benefits of FBWF are similar to the EWF benefits.

National Instrument's WES7 images ships with FBWF Manager that allows for command-line access for configuring the system. LabVIEW also has an API for configuring the settings for FBWF. If you have LabVIEW 2014, you can add a touch panel target as shown in Figure 2 and browse in the function palette to Programming » File I/O » Advanced File Functions » Write Filters » File-Based Write Filters. Each VI has Context Help that is useful for utilizing this API in your application. The API allows for enabling/disabling FBWF as well as adding exclusions to the write filter (See Figure 7).

Figure 7. The File-Based Write Filter Palette.

To enable FBWF for CompactRIO and CompactDAQ targets, you must used the command-line interface:

a.     Open a command prompt with administrator privileges and enter the following to view the current status of FBWF Manager:

fbwfmgr /displayconfig

b.     To enable FBWF upon next reboot, type the following:

fbwfmgr /enable

c.     To protect a particular volume, type the following:

fbwfmgr /addvolume C:

d.     To add a directory exclusion, type the following (assuming C:\Datalogging is what I want to exclude):

fbwfmgr /addexclusion C:\Dataloggingewf

e.     Reboot target for the changes to take effect.

Figure 8. Command prompt output of FBWF Manager after configuration and enablement.