Embedded Enabling Features (EEF)
Embedded Enabling Features are specifically developed to facilitate or support Standard 2009 (or its predecessor Window XP Embedded) development.
Common questions When setting up EWF-DISK, is there a way to use all the remaining unallocated space on a disk for the EWF partition without having to supply a specific size?
No, you must specify the size.
When using EWF, should I use a page file in my runtime?
If you deploy a page file, it should not be resident on the volume that is protected using EWF.
How large should I make the EWF partition if using EWF-DISK mode?
For each overlay level you plan to have, you should make space in the EWF partition, keeping in mind the reserved space should be no larger than the size of the volume it is protecting.
What happens when I defragment a protected volume with EWF enabled?
This rapidly consumes overlay sectors in the EWF partition, and there is no benefit in running a defragmenter when EWF is enabled. You should disable EWF before defragmenting a volume.
Which filesystem should I use, FAT32 or NTFS?
FAT32 requires less file system overhead and may be slightly faster. NTFS offers file system security, file compression and encryption, but requires more file system overhead.
I want to protect the boot volume using EWF-RAM or EWF-RAM-REG, but still want to be able to store some persistent data that is not lost when the system is rebooted.
Set up a new volume that is not protected by EWF. This volume may be either on the same physical disk, or on a separate disk.
Common problems and solutions Growing EWF files when using EWF-RAM
The developer will need to test their device in the anticipated scenarios by the customers, monitor system memory consumption, and decide whether it is acceptable. If not acceptable, then developer will need to do one or more of the following:
eliminate the source of growing files
increase system memory
choose to not use EWF-RAM
Your actual system requirements will depend on your specific scenario.
However, there is a distinction between free disk space and in-use disk space, in the EWF protected volume, that the EWF-RAM developer should keep in mind:
1. Growing files, or newly created files, consume free disk space, and cause EWF-RAM to consume system memory. The maximum that can be consumed is the amount of free disk space in the volume. If the initial free disk space is kept limited in size, then the user will receive a warning from the operating system (your system is low in free disk space etc.) before the system can crash because it runs out of system memory.
2. Modifications to in-use disk space also causes EWF-RAM to consume system memory, because some fraction of in-use space will get modified by the developer’s limited functionality runtime. This consumption is bounded, so over time all the sectors that can be modified, become modified, and then no further system memory consumption caused by modification of in-use disk space will occur.
Assuming the developer configured enough system memory to accommodate (2) above, then the only issue remaining is that of growing or newly created files. Note that the choice of Standard 2009 OS components intimately affects this. For example, Internet Explorer maintains a cache of recently used web pages. This cache should be set in Internet Options so it is limited in size.
Here is a summary of things customer can do to reduce memory consumption on their devices instead of looking at solutions like relocating file system metadata files which might not be even the major contributor to the increase of memory consumption on their devices:
Log files and changing data files should be placed on an unprotected partition.
Follow the guidelines on how to improve EWF performance:
EWF Performance Considerations
Relocate user profiles to the unprotected partition.
Re-consider using EWF on their devices. If EWF is absolutely needed, consider using disk-based EWF.
Investigate the memory consumption increase as it might be caused by other app (theirs or 3rd party) or modules in the OS.
Use a pagefile on the unprotected partition, which will improve the system memory management performance.
Use Regmon to find out who’s writing to the registry hives.
Use Filemon to find out what files are being accessed.
You see a never-ending FBA reboot loop.
Before starting FBA, ensure any old EWF (type 45) partitions are first deleted, using Disk Manager (diskmgmt.msc) or the WinPE Diskpart utility.
Make sure your drive letter mapping is correct in Target Device Settings. This information is configurable in the root component of your configuration, under Settings. If your Standard 2009 device system boot volume is on drive D:, your Settings should be as follows:
Boot Drive: C:
Windows Folder: D:\WINDOWS
Program Files Folder: D:\Program Files
Documents and Settings Folder: D:\Documents and Settings
The EWFMGR command with no parameters reports “NO EWF PARTITION”
There is no EWF partition. This is a normal condition if deploying EWF-RAM-REG. You can, however, get the status of the EWF RAM-based volume if you include the drive letter, e.g. EWFMGR C:
A window appears on the desktop stating: “Delayed Write Failed. Windows was unable to save all data for the file…”
The most probable cause of this is that you have run out of free overlay space.
For RAM-based EWF, ensure you are using Windows XP Embedded Service Pack 2 or greater. Otherwise, the total memory available for RAM overlay is limited to 256MB.
Ensure you have a large enough overlay (RAM or DISK) to accommodate the worst case disk write scenarios. This way, when you start running out of normal disk space, the operating system can act correctly on this condition.
Consider setting the following check box: “Use Less Overlay Space & Less Writes”
Your application should minimize disk writes.
Make sure the background disk defragmentation service is turned off.
The FBA log reports that it is unable to create the EWF partition
There are no free sectors available to create the EWF partition. Note that even with EWF-RAM an EWF partition is always created; with a minimum size of 32KB.
File system and/or disk media content corruption issues
There are many facets to this issue, and the root cause can be one or more hardware and/or software sources, regardless of whether EWF is used.
The most important consideration is that surprise power removal from a system that does not receive an early indicator of pending power loss (such as a signal from the power supply that can interrupt the processor as an advance warning) will typically result in file system corruption if the operating system has pending (cached) write data that either has not yet been written to disk, or is in the process of being physically written to the disk.
If your target device contains an ACPI-compliant BIOS, you can configure the XP Power Options Properties (Start->Run Powercfg.cpl) set to Shutdown, so that when you push the power button on the device, the operating system performs an orderly operating system shutdown (the choices are Shutdown, Stand by, Hibernate, Do nothing, or Ask me what to do). Using Shutdown will guarantee that all pending disk data gets properly persisted to disk.
Using EWF-RAM will protect your system from the scenario where the OS has pending write data, because no actual writing occurs to the volume(s) protected by EWF-RAM.
A caveat to the above is the possibility of writes occurring to a protected storage media before EWF.SYS has been launched and installed by the operating system during boot up. In typical scenarios disk writes do not occur during that time.
It is possible that if you enable boot logging for troubleshooting purposes, the file ntbootlog.txt may get corrupted if EWF is enabled because EWF engages after physical writes to ntbootlog.txt have occurred. This results in a partially written log file.
Consider formatting your protected drive using the FAT file system instead of NTFS because of the possibility of NT journaling files being written to at an early time.
Note that there are hardware factors that the operating system has no control over. If you have media corruption problems the cause may be due to a combination of the following:
Environment. Radio frequency interference (RFI) can cause random corruption by injecting voltage and current transients into the hardware. Automotive and other mobile applications can be vulnerable to this. For example in the automotive environment, motors and other inductive devices can generate RFI and line voltage spikes (transients). It may be necessary to enclose the device in a metal cage (Faraday cage) and/or protect wiring to and from the device using optical isolation or line transient suppression techniques. Your power source may be unreliable and subject to power outages or brownouts.
Hardware and firmware design. The power supply might not gracefully handle power loss by providing a clean Reset signal when power loss or brownout occurs. Motherboard components such as the IDE controller chip also need to react gracefully in this situation. The media itself (typically CF) also needs to disable itself quickly when a reset occurs to avoid processing spurious commands.
Operating System and applications. When a file is opened and later is not appropriately closed this typically results in file system corruption. The solution is to ensure that an orderly shutdown occurs. This is particularly true if there are disk volumes that are not protected by EWF. EWF can protect against this corruption but please note that surprise power removal can cause spurious disk sector failure depending on how well the hardware and media reset logic react to immediate power loss.
The following discussion explains what happens if power loss occurs while data is being written to disk. Pending write data is cached by the operating system, 3rd party device drivers, and the storage device itself. How long it takes for the operating system and device driver to write the cached data to be written to the storage device is adjustable, but in any case it remains a statistical issue because there will always be a slice of time where power loss within that time slice will result in failure to commit the data to the disk.
The disk drive hardware itself is a peripheral that contains a data cache. If the disk itself is unable to flush its internal pending writes, then the failure will occur, regardless of the choice of operating system.
If the motherboard itself does not assert a RESET signal when the power supply voltage falls below a level at which operation can become unpredictable, this can result in execution of random code, which might cause a stray write to the storage disk to occur. The same can occur in any peripheral device that contains a microcontroller that runs a program (such as a CF IDE storage device, or the IDE controller that talks to the CF device)
Some CF media that incorporate built in “write wear leveling” use an internal algorithm to balance sector writes across all sectors, in order to maximize the life of the CF device (Flash memory is reliable to approximately 100,000 to 1,000,000 write cycles per sector). If the power loss occurs while the CF itself is performing sector balancing, this could corrupt the CF.
Note that due to the nature of surprise power loss, no operating system can guarantee 100% recovery, if the storage device is writable and actively being written to, unless the operating system receives a power loss interrupt with enough advance warning to flush pending writes to physical disk. Of course, the operating system must have software to act on that interrupt as well; this can be accomplished using a custom device driver.
NTFS is a journaling file system that provides strong guarantees about metadata integrity across unexpected power losses. This ensures that the file/folder metadata is coherent, but does not guarantee that file data is coherent.
Custom applications can be written to flush pending write data to disk sooner but (1) there is always a tradeoff between disk I/O performance and guarantees that the data is quickly persisted to disk and (2) even when file writes are committed immediately there is still a critical time window between the file commit API (such as FlushFileBuffers and _Commit) and when the data actually persisting to disk. The risk time window is made shorter but is not eliminated.
The Enhanced Write Feature greatly reduces failures due to loss of pending write data because once EWF is activated, it prevents the operating system from performing physical writes to the disk (all changes go to system memory, consuming memory in the process). However you would need another disk volume that is not protected by EWF, in order to log your data that persists.
EWF is preferred over FBWF to protect against media corruption because FBWF filters at the file system level (FAT32 or NTFS), while EWF protects at the sector level (and loads at an earlier time than FBWF). If you use FBWF and specify no file exclusions then in theory it should behave similarly to EWF. Though the OS would still be capable of updating sectors that are not controlled by the file system, such as partition boot records.
In order to analyze a storage corruption problem further, it may be useful to discover more about the nature of the data corruption within the storage device. If you cannot read the failing storage device using Windows Explorer, use a sector editor to compare a device that is functional against a device that is corrupted. Here is a public search link for “disk sector editor”:
Bing search for Disk Sector Editor
The next step is to analyze the differences.
If whole sectors are not getting written to the disk, this is likely due to a failure to flush pending write data to disk.
If sectors are partially corrupted, this could be due to random code execution or hardware behaving erratically due to low system voltage.
If you cannot read the CF at all with a sector editor (and cannot even format the device), then the CF likely contains internally corrupted mapping tables due to power loss during a critical time when the CF was completing remapping operations in the course of writing data.
You can use an ATA analyzer to monitor the actual IDE commands between the IDE storage device and the motherboard. Set the analyzer to monitor for writes. With EWF-RAM enabled, you should never see any disk writes to the corresponding protected volume.
Mitigating corrupted volume issues for volumes that are not EWF-RAM protected.
If you have a volume that is not protected, for example because you have an application that needs to persist logging files and/or other data, and you are looking for a means of automatically repairing corruption when it occurs, one way to do this is to essentially manage your own private "file system within a file system".
Typically the possibility of a FAT file system corruption can occur if a file has been created, deleted, or modified in length, and then a power loss occurs before the state of the file system has been fully updated. The key to the following approach is to create a permanent file whose total length never changes.
Suppose you have an application that requires a persisted log file on an unprotected FAT volume. Your application can create a special, large fixed length log file that is treated as a random access file but applications that write to it think it is a variable length log file because they go through a custom logging API that your company develops. You write a logging API that keeps track of the end of file position, perhaps the file position can be kept in the beginning of the file. The purpose of this exercise is to prevent the log file from growing in length so the FAT never needs to get updated by the OS. Thus if an end user performs a surprise shut down, the FAT does not get corrupted because the FAT file system state never changes. Owing to surprise power loss, the contents of the fixed-length file might be a little corrupted; but you could write logic into your logging application that can automatically detect and repair this. For example you could put an EOF character such as control z at the end of file position and when the file is opened the first time it could verify that the EOF pointer correctly points to the control z. If it does not, you can take action by resetting the end of file position (effectively clearing your special log file without changing the total length of the real FAT-based file that contains it).
Storage media protection check list:
Protect the operating system volume using EWF-RAM. Place your log data on a second volume. Consider placing the log data on a second physical CF media device to reduce the chance of corrupting the operating system volume. This way the physical CF media for the operating system volume never gets written to. Note that EWF will not protect you from the hardware performing random code execution during surprise power loss (and the operating system has no control over this either).
Consider using an Uninterruptible Power Supply (UPS) device, one that automatically performs an orderly shutdown when power loss occurs.
If possible, configure the device environment to minimize the scenarios where end users can power down the device incorrectly.
Minimize and/or filter sources of EMI and line transients that can disrupt your device electronics.
Try other CF devices and motherboards that may be more forgiving when power loss occurs. Specifically, hardware that generates a reset signal before power drops below dangerous levels, and peripherals that reset themselves properly when the reset signal occurs.
If you can modify the hardware design, configure the boot device as read only in hardware (or use media that has a write-protect switch), and then use EWF-RAM to protect the boot device.
If you have volumes that are not protected by EWF, and you anticipate surprise power loss, consider flushing files to disk more frequently and/or developing custom file management solutions that can detect and correct file corruption (as described earlier).
Use EWF Manager to monitor and troubleshoot EWF
The EWF Manager Application is a console utility used to manage EWF on the device. It allows you to control EWF operation. You can check the EWF status by issuing the following command:
Ewfmgr C: (where C: is your protected volume)
EWF manager displays a result similar to the following:
Protected Volume Configuration
Type RAM
State ENABLED
Volume ID BB E6 0E BC 00 64 15 00 05 00 00 00 00 00 00 00
Device Name "\Device\HarddiskVolume1" [C:]
Max Levels 1
Clump Size 512
Current Level 1
Memory used for data 2624000 bytes
Memory used for mapping 4096 bytes
If you attempt to run EWFMGR without specifying any arguments, you will receive an error. The message will indicate that it was unable to locate the EWF volume. Also, all non-status commands take effect on the next reboot. Remember that by using the registry to configure EWF, the filter can only be disabled by performing a CommitandDisable operation.
El Torito
Useful links:
How to use Enhanced Write Filter (EWF) on removable media
Troubleshooting
Use kernel debugger to get additional data during boot.
Ensure that the target embedded partition is marked as active. To do so, run Diskmgmt.msc from a command prompt, and then right-click the drive to identify whether it is marked as active.
After FBA completes, inspect the %windir%\Fba\Fbalog.txt file. Confirm that the file contains the following messages:
Created ewf partition on… "
Protected Volume Config on … Type=RAM, State= Disabled
After FBA completes, the following registry entry should exist:
ControlSet\Enum\ElTorito
EWF should indicate it is disabled (run EWFMGR C:).
If you are still having trouble, consider creating an El Torito build that is designed to boot up on a stock computer instead of on your unique hardware or Compact Flash storage to ensure that you are following the basic procedure correctly.
The free space for the EWF partition cannot be larger than 2 GB.
Usage notes
Design any applications that you include on the El Torito image to minimize write operations to the disk, because each new write operation consumes available system memory until the next boot.
After you create your image, you cannot repartition the disk in any way that changes the offset of any boot partition, and you cannot add new boot storage devices. However, you can add non-boot type devices to an El Torito image.
El Torito cannot be used to create a bootable DVD.
Error 0xC000021A occurs when you start the El Torito image
You may receive blue screen error 0xC000021A when you try to start the El Torito image. This behavior occurs if you do not leave the intermediate El Torito CD in the CD-ROM drive when you use the ETPREP tool in preparation for creating the final El Torito CD.
Device Update Agent
Please review this technical article:
Inside Device Update Agent (Standard 2009)
Video tutorials for XP Embedded which are also relevant to Standard 2009, including a DUA tutorial:
Windows XP Embedded Tutorials
In the above web site, choose the following video tutorial for DUA that is 36 minutes long (there's another at the bottom of that page as well):
Device Update Agent for Windows XP Embedded
Windows XP Embedded - Advanced
For the online docs, here's the launching point for DUA:
Device Update Agent
Also review the team blog:
Windows Embedded Standard Team Blog
There's a power toy (DUA ScriptGen) that eliminates some of the burden of authoring the DUScripts:
Aaron Stebner's WebLog
Setting a registry key with Device Update Agent (REGSETVALUE)
Correction to the Device Update Agent documentation
The Device Update Agent documentation indicates that the size parameter for defining or setting a registry key or value is optional, depending on the command that it applies to. The command reference should really be as follows:
11, [ErrorMode], hKey, [ExpandMode], Key, [ExpandMode], ValueName, Type, [Size,] Value
A size parameter is only needed for the following value types:
DAREG_NONE
DAREG_BINARY
DAREG_LINK
DAREG_RESOURCE_LIST
DAREG_MULTI_SZ
For value types that do not require a size, leave out the parameter entirely. DUA looks at the type, and determines if the next parameter should be the size or the value. In the command you included in your Device Update script, DUA sees that the type is REGSZ, and expects the next parameter to be the value. Because the next value is specified as a null string, DUA assumes that this is the value that you want to set and moves on. This is why the command shows as a success. DUA ignores anything beyond the last parameter.
So you will find that this command sets an empty string:
REGSETVALUE,,HKEY_LOCAL_MACHINE,,SYSTEM\CurrentControlSet\SampleKey,,SampleValue,DAREG_SZ,,Hello World
Whereas this command actually sets the value:
REGSETVALUE,,HKEY_LOCAL_MACHINE,,SYSTEM\CurrentControlSet\SampleKey,,SampleValue,DAREG_SZ,Hello World
SDI I get the error message D:\XPe\SDIMGR.WSF(2294, 4) SDIAUT.SDIFile.1: Access is denied, when I try to run writedisk with SDI
You receive an access denied error message when some other application is accessing the volume in the SDI file.
To resolve this problem:
Close all other applications that are accessing the SDI volume.
Make sure that no application is using the disk that you want to write to.
If you are trying to access the SDI file through a share, make sure that the network share that has the SDI file on is shared out with write permissions to the user you are connecting with through Net.exe.
System Cloning Tool and FBRESEAL The fbreseal –keepall option turns off the System Cloning tool advanced property cmiGenerateComputerName
The fbreseal –keepall option is documented as having the same effect as using the following command line switches:
fbreseal -autologon -keepdomain -keepnet -keepuser –keepmounted
However, it also has the effect of disabling the random computer name feature (effectively setting the cmiGenerateComputerName to a value of 0).
If you need the random computer name feature, use the following workaround:
In the Settings of the System Cloning tool, make sure that Generate New Computer Name is checked.
Instead of using fbreseal –keepall, use the following command:
fbreseal -autologon -keepdomain -keepnet -keepuser –keepmounted
For additional information, see the following article in the Microsoft Knowledge Base:
FIX: Windows XP Embedded system cloning may reset runtime information
System Cloning Tool modifies the wrong disk volume
The first boot after the “Reseal complete” Message Box appears causes SysPrep to establish the image as unique. However, If the resealed Standard 2009 target system volume is located on drive D and drive C contains Windows XP Professional, the SysPrep process that is used to clone the device may change the state of Windows XP Professional on drive C. For example the MountedDevices section of the registry on drive C may have the mounted drive letters C and D mapped in reverse (swapped). To avoid this situation, if cloning a device, avoid multiple operating systems on the embedded device during the resealing phase, and/or install your Standard 2009 image on drive C:.
Cryptographic Service problems
You get errors attempting to apply an XP update to a Standard 2009 runtime image after applying the technique(s) shown here:
Updating Standard 2009 runtime images after they have been deployed
“Setup could not verify the integrity of the file Update.inf. Make sure the Cryptographic service is running on this computer.”
Try implementing the instructions contained at these links:
You cannot install some updates or programs
|
