Managing Disk Protection

Managing Disk Protection

  • Comments 5

**Updated 3/26/09 with preface

[The following article is authored by one of the Windows Embedded MVPs (Most Valuable Professionals). Our MVPs have a heavy background in Embedded systems and are a great repository of information on Windows Embedded products. We’re providing this space on our team blog as a service to our readers by allowing MVPs to share some of their knowledge with the rest of the community.] 

Disk Protection offers a lot of benefits in embedded scenarios. However, it does not come for free. Protecting a partition means shielding the content from all changes, which means undesired as well as desired changes. Due to this, complexity in maintaining the system increases.

Fortunately, there are some tools and utilities in Windows Embedded Standard that help to handle even complex update scenarios.

Configuration tips

But let’s have a look at some configuration best practices first.

clip_image002

Managing the write filters starts with the configuration in Target Designer. Here the default setting is that the write filter (as shown above for EWF) is enabled right after running through FBA. Unfortunately, this is, in most cases, not recommended, partly because manual tweaks are still necessary in many scenarios or the system needs to be cloned for production. If you seal a system, with EWF enabled in RAM overlay mode, for example, the sealing will not have the desired effect, because with the next boot all sealing information that was written to RAM is lost. Therefore it is better to turn off write filters and to activate them later in the factory or field after all customizations on the target device have been finished.

Introducing the managers

There are command line utilities provided in Windows Embedded Studio, which have been written to address the needs of system administrators managing disk protection filters. Therefore, they do not work with users or applications running under accounts that do not have administrative rights.


EWFMgr.exe is used to manage Enhanced Write Filter (EWF), while FBWFMger.exe is used for File Based Write Filter (FBWF). You may have noticed that there is no command-line tool for Registry Filter. This is because this filter works in combination with one of the write filters and therefore its state corresponds to the state of the write filter.

EWFMgr.exe is owned by a separate component in Target Designer, namely the “EWF Manager Console application” component (do not forget to include it in your image), while FBWFMgr.exe is part of the File Based Write Filter component.
These managers allow administrators to get an overview on the current state of filters, to turn a filter on or off on a certain partition and to handle how changes are persisted in the current session.

clip_image004

The sample above shows the state information EWFMgr.exe provides either used “globally” (without drive letter) or on a protected partition (with drive letter specified). In global use it shows which partitions are protected and the state of the HORM feature. The information from the command for the protected partition on C: shows quite a few details on the current disk protection settings.

Here are some of the most common commands. To enable or disable EWF on a partition use:

EWFMgr C: -enable

EWFMgr C: -disable

It is important to mention, that in all cases the system needs to be restarted if one changes the state of EWF. The only option that does not require a restart is:

EWFMgr C: -disableandcommit –live

This command immediately commits all changes in the overlay to the original partition and therefore should be treated with caution. Note that this command can only be used with RAM or RAM-Reg overlays. If one needs to commit changes without disabling the write filter the following command will do the job, but it requires a reboot:

EWFMgr C: -commit

File Based Write Filter Manager offers similar commands as shown in the overview below.

fbwfmgr [/? | /help /[switch] | /displayconfig | /overlaydetail | /enable | /disable | /addvolume [volumename] | /removevolume [volumename] [1|0] |

/addexclusion [volumename] [file or directory path] | /removeexclusion [volumename] [file or directory path] |

/setthreshold [threshold] | /setcompression [1|0] | /setpreallocation [1|0] | /commit [volumename] [file path] | /restore [volumename] [file path] | /setsizedisplay [1|0] | /getvirtualsize [volumename] | /getactualsize [volumename]

Be aware that input parameters in FBWFMgr are handled differently. They are preceded by a “/” instead of a ”-“ and the differences between EWF and FBWF need to be taken into account, as well. For example, commit is selective (only for files defined in FBWF), in contrast to committing all changes to a complete partition with EWF.

To get a deeper understanding of the possible options the Windows Embedded Standard platform documentation is recommended as a valuable resource.

Power Management Utility

Speaking about write filter management, there is a third very useful utility, called XP embedded power management application, which can be found in the “Power Management Application” component.

clip_image006

This tool allows a user to change the power state, and is very beneficial whenever it comes to reboot, shutdown or hibernate of the system, managing the write filters or doing maintenance.
XPePM.exe can, of course, be included in any batch files or scripts.

Write Filter APIs

But wait there is more!
Having command line utilities at hand is nice, but it does not cover all usage scenarios, especially if devices use a custom shell that you access via programming interfaces. Microsoft offers native APIs for the write filters that can be found in the C:\Program Files\Windows Embedded\EWFAPI or \FBWFAPI folder, if installed during the setup of the tools (this is optional!).
These native APIs can also be leveraged by managed applications using .NET interop.
With their help it is possible to include write filter management functionality in custom applications and custom shells.
Through these APIs the embedded developer gains maximum flexibility controlling the disk protection EEFs.

- Alexander

Alexander Wechsler

Wechsler Consulting

www.wechsler-consulting.de

Technorati Tags: XPe,Embedded

  • I'm a program Manager with the Windows Embedded Standard team working on the write filters – Enhanced

  • (注:本文译自英文博客) 我是嵌入式Windows产品组的项目经理,具体负责写过滤器(Write Filters)模块,包括 Enhanced Write Filter (EWF) , File Based

  • **Updated 3/26/09 with preface [The following article is authored by one of the Windows Embedded MVPs

  • Is there a way to commit once instead of leaving the drive commited and then all subsequent writes will be committed as well?

    Take for instance.

    Ram overlay

    ewfmgr state = Enabled

    I open a file make some changes then commit. After the commit the drive is still enabled and any subsequent changes to that file are not being commited. So the commit works on rising edge as a one time trigger instead of remaining enabled until you reboot?

  • If You need this, You should use File Based Write Filter (FBWF) on the partition. It allows exactly what You are asking for. EWF sits below the file system and the disk and therefore is only aware of disk sectors not files. This makes it hard to commit single files with EWF.

    HTH :-)

    Alexander

Page 1 of 1 (5 items)
Leave a Comment
  • Please add 6 and 1 and type the answer here:
  • Post