Write filters are an essential part of a PLC. In Beckhoff PLCs write filters redirect writes from a disk/partition to RAM or another disk/partition which is flushed after reboot.

Basic principle of a write filter

The reason why you want to have a write filter on your PLC is simple; it’s to protect the PLC from write operations. We’ve all been in the situation where the OS is in the middle of a write, and for some reason it suddenly dies. After a reboot the system might be corrupted. With write filters, most changes in any applications or the operating system will not be persistent, which is often what you want in a system that runs 24/7 year after year. By protecting volumes from writes, the filter also reduces the wear of flash media. Because the filter puts the changes in volatile storage, it’s enough to do a simple reboot to get the system back in a well-known state. In this post I will go through the different types of write filters and discuss some of the finds I did with the new UWF (unified write filter) that comes with the Windows 10 enterprise operating system.

There are three different type of write filters available for the Beckhoff PLCs. The write filters are not something unique for Beckhoff PLCs but are part of the operating system.

• EWF – Enhanced write filter. Protects the whole partition from write access by redirecting it to RAM. Included with PLCs running Windows 7 embedded
• FBWF – File based write filter. Just like above but gives the possibility to add exclusions for folders/filters and the windows registry. Included with PLCs running Windows 7 embedded
• UWF – Unified write filter which replaces the EWF and FBWF. Included with PLCs running Windows 10 enterprise LTSB/LTSC

The EWF is very basic as it can only protect whole partitions. Normally it’s desirable to do some exclusions, as for example:

• the \TwinCAT folder (for software updates, persistent variables, license files etc.)
• the folder for TwinCAT HMI logs (if installed)
• certain registry entries
• any eventual local SQL database
• certain individual files

The list of files and folders is called exclusion list or write through. As the use of the EWF is quite limited I will not discuss it further but rather focus on the FBWF and UWF, which both have functionality for exclusions. My initial assumption was that the UWF would behave the same way as the FBWF. Before I did the analysis of the filters my assumption could best be explained by the great actor James Franco:

The results however show differences. Now I would just simply say “same same, but different“. Below I’ll explain why this is the case.

Both the FBWF and UWF protect the contents of a disk by intercepting write attempts and redirecting them to a virtual overlay. The maximum size of the overlay is fixed, and files that are added to the overlay make it grow up to the maximum size defined. I’ll dig deeper into the write filter functionality of FBWF and UWF by doing some tests by copying large files. As test devices I’ll use two PLCs:

• Beckhoff CX5120, 2 GB RAM, Win7Embedded 32 bit (FBWF)
• Beckhoff CX5140, 4 GB RAM, Win10Enterprise 2016 LTSB 64 bit (UWF)

Beckhoff CX5120 and CX5140

Both are flashed with the latest images to the respective PLC as of this writing. Let’s start looking at the FBWF in Windows 7.

Beckhoff FBWF manager

The Beckhoff FBWF manager does what you would expect, in where you can enable/disable the filter and add exclusions. This is basically a frontend/graphical user interface for the fbwfmgr.exe which is a command line tool residing in the operating system. What I’m missing in this tool is the possibility to set the size and see the current status of the overlay. Running fbwfmgr in the command prompt gives us much more control.

fbwfmgr.exe

Here we can see that the overlay cache is set to 1 GB.  I wonder whether the Beckhoff tool sets the overlay to half the total RAM or whether this is the max?bu Running fbwfmgr /help setthreshold gives us the answer:

C:\Users\Administrator>fbwfmgr /help setthreshold

FbwfMgr /setthreshold threshold
  Sets the cache threshold (in Megabytes) for the write filter. The new
  threshold will take effect after the next reboot.
  Must be between 16 MB and 1024 MB.

Whether the max is always 1024 MB or whether the max is half of the RAM I would need another Beckhoff PLC to confirm. To see how much is consumed of the overlay we can run fbwfmgr /overlaydetail.

fbwfmgr /overlaydetail

Here we can see that we’ve used 101+18 MB of the 1024 MB. Let’s see how the RAM usage and the overlay is affected when copying files to the PLC. To monitor RAM usage, I’ll use the tool resource monitor (resmon.exe) that is built-in into both Windows 7 and Windows 10.

Resource monitor – before copy

There is a good description here that explains what all these different memory allocations are, but for this post we’ll only focus on the “1156 MB Available” on the top. Copying a 375 MB large file to the desktop (which is protected, i.e. not in the exclusion list) of the PLC results in:

• The amount of available memory decreases to 690 MB
• The cache/overlay increases to 482 MB
• The physical disk usage increases by 0 MB

Which is (more or less) what you would expect. Because we write to a protected area of the PLC, the file is written to RAM/overlay. As a second further step, taking another file (with the same size of 375 MB) and copying it to a non-protected (in the exclusion list) area of the PLC (C:\Data) results in:

• The amount of free physical memory changes very little (few MB)
• The cache changes very little (few MB)
• The physical disk usage increases by 375 MB

Again, results as expected. This time, the overlay is not used, and the file is directly written to disk instead, as the folder C:\Data is in the exclusion list of the write filter. Removing the file on the desktop makes the overlay shrink and the available RAM increase. Rebooting the PLC results in the file on the desktop (residing in the RAM overlay) being removed, but the file in C:\Data still being there. The overlay is again only a few MB.

Now let’s look at the UWF. Beckhoff have recently done some changes/updates to their UWF manager which includes the possibility to use a disk instead of RAM for overlay. I’m not entirely sure whether it’s possible to get an upgrade of just the UWF manager software itself, instead I downloaded the latest image for the CX5140 which contained the latest version of this software. Just as with the FBWF manager, Beckhoff only provides the frontend/graphical user interface to the uwfmgr.exe that is part of the Windows 10 enterprise operating system.

Beckhoff UWF manager

The software is similar to the FBWF manager, with some differences. Firstly, it’s possible to set the size of the overlay directly in the GUI. This can be set from values all the way from 256 MB to half of the memory in the PLC, which means it’s possible to set the overlay to 2048 MB with the CX5140. Further, it’s also possible to define which volumes/partitions should be protected. On top of this, you can set exclusions to specific registry entries. Finally, and it will prove most importantly, it’s possible to use another disk/partition as disk overlay:

Overlay target selection

Another difference is that we can see the status of the consumed overlay directly in the GUI, thus we don’t need to use the uwfmgr console application to check this. Let’s start by doing the same tests we did with the FBWF, that is copying some large files over to a protected and non-protected area. I’ll set the overlay to 1024 MB and use the RAM as overlay. Just as with the previous example I’ll have the folder C:\Data added as an exclusion. I’ll use resmon.exe for monitoring memory usage. After rebooting the PLC I’ve got 43 MB in the overlay and 2471 MB available RAM. Copying a 375 MB large file to the desktop of the PLC (protected area) the overlay increases to 419 MB and the RAM decreases to 2144 MB. Results are as expected. What’s different to the FBWF is that the physical disk usage increases by 375 MB, which means that both the RAM and disk usage increase with the same amount. Removing the file decreases the overlay and increases the available RAM again (both back to more or less the start values). It also frees up the space in the disk. I find it a little odd that both the available RAM and disk space decrease. Out of curiosity I’ll try to copy files to the protected area so that the overlay is filled. The result was this:

Frozen

The operating system got completely unresponsive. I could see that TwinCAT was still running as I could still talk to the running PLC program with ADS. With this result I would simply state that you should never fill the overlay, as the only way to do something in the OS again was to power cycle the PLC.

In the next test I wanted to see what would happen if I copied any files to a folder in the exclusion list. Copying the same file to C:\Data (which is in the exclusion list) reveals that the overlay again increases with the size of the file!

Overlay before and after copying large file to excluded area

This was unexpected, and I did the same thing again (with different files to other folders being in the exclusion list) but I got the same result. This is a major difference of how the FBWF works, and I really can’t see why Microsoft has changed this. There seems to be other people discussing the same issue. Let’s see what behavior we get if we use the disk as overlay.

Disk as overlay in UWF

Just based on this GUI I’m not entirely sure which disk/partition is overlay, but it’s a fair assumption to make that the disk/partition that is protected is also used for the overlay. It seems the maximum selectable size for the overlay is the free space of the disk. Copying a file to the desktop (protected) makes the overlay increase with the size of the file. The available disk space decreases with the same amount. Copying the file to C:\Data (non-protected, added to exclusion list) shows exactly the same behavior as with using the RAM as overlay, i.e. the overlay is increased, and the disk space is decreased with the size of the file. After rebooting the PLC all the files in the protected areas are gone, while the files added in the exclusion list are retained. In other words, it seems to work the same way as with RAM. Now the next question; will the size of the overlay increase if I do writes to a non-protected drive/partition? As you can see above it’s only the C:-drive that is protected, while the D: is not. Copying a 1320 MB big file to D: didn’t make the overlay change a single MB. This is a good thing, and it leads me to the discussion.

Discussion

It’s obvious there is a difference in the implementation of the FBWF and the UWF. Adding files to an area that is in the exclusion list makes the overlay increase in the UWF, while it does not for the FBWF. Although the UWF surely seems more capable than the FBWF, it’s a mystery for me why Microsoft decided to put the addition of data in the exclusion list to the overlay. We have to remember that Windows 10 enterprise is used for many other applications than industrial automation, and that Microsoft most likely have a good rationale for this decision. It’s important to understand that the EWF, FBWF and UWF are Microsoft applications. Beckhoff only provide front-end applications for the fbwfmgr.exe and uwfmgr.exe which are part of the respective operating system. Sending an e-mail to the Beckhoff support and asking them to change the behavior of the UWF to be like the FBWF won’t result in anything. Beckhoffs hands are tied to Microsoft, so what can we do?

What we should do is very individual and application specific. The most important thing is to analyze your application. What software will we be running that will do writes to the disk? How much data can we expect to be written? Is the system going to be running 24/7/365, or can we expect it to be rebooted sometimes? If yes, how often? Are there any changes in any configuration of any software while running the system? Beckhoff are continuously adding new functions to TwinCAT that might affect this, such as the new event logger and the web HMI, which we need to take into consideration as well. This analysis should be done irrespective of whether we use the FBWF or UWF. Some general advice/directions can be given/discussed:

• Don’t use RAM-overlay with the UWF. This is because that the amount of RAM is almost always more limited than the amount of disk-space that can be allocated for an overlay, and with the latest UWF manager we can use the disk for overlaying
• Use disk-overlay and create a separate partition for everything that you would normally want in an exclusion list. Set this separate partition to be non-protected in the UWF-manager. Only use the overlay to protect the operating system. With disk-overlay, we can use a much bigger overlay than with RAM. Because the separate partition is not protected, it’s not affecting our overlay

This strategy of using disk-overlay and creating a separate partition does not always work, as it’s sometimes not possible to select where certain data should be saved. Also, one drawback of using the disk instead of RAM as overlay is wear of the drives, which should anyway be minimal as our aim should be to only protect the OS. The longer you plan to run the system continuously (without reboots), the more important it is to do a proper analysis of your use case.

While at this topic, I would end this post with a suggestion. While deleting files in the operating system, I noticed that the overlay increased with the size of file. Why did the overlay increase when I deleted a file? I realized that this was due to the file being put in the recycle bin, which is just a folder on the C: -drive. The recycle bin is (by default) not in the exclusion list either. There are two things we can do to solve this:

1. Add the recycle bin to the exclusion list
2. Make sure any deleted files are never stored in the recycle bin, but immediately removed

Considering our new findings about how the exclusion list works with the UWF, I vote for option 2. To do this, we need to change a property of the recycle bin. Because we are doing a change in the operating system, we first need to disable the UWF. Next, right-click on the recycle bin and select Properties.

Recycle bin properties

Select Don’t move files to the Recycle Bin. Remove files immediately when deleted. Enable the UWF again and reboot the PLC. Done.

Have you experienced any issues with the FBWF or UWF? How are you utilizing it in your application? Do you have any suggestions of how to optimally protect the disk of the PLC? Are there any additional considerations to take into account? Please write a comment below.

Hard drive by olafpictures from www.pixabay.com