Registry-based RAM EWF questions

  • Thread starter Thread starter Doug Gordon
  • Start date Start date
D

Doug Gordon

Well, I finally got registry-based RAM EWF working after a day lost
troubleshooting a problem that turned out to have nothing to do with the EWF
feature. It is about a 45-minute cycle to run TD, make changes, build, copy
the files to my target, and get through FBA, so it got pretty tedious! By
the way, I ended up using Slobodan's "manual config" method with a component
of my own for setting the registry entries.

Anyway, what I noticed that was unexpected was that there was only one
reboot during the FBA processing, where my previous config with disk-based
EWF would reboot twice during the FBA process. Even though everything seems
to be working OK, I have the following questions:

1) Is this one-reboot FBA process correct? Does it have anything to do with
disabling the FBA DLL/COM Registration resource in the EWF component?

2) If my protected partition is, say, 250Mb, can I assume that the RAM EWF
support will never allocate more than about 250Mb of DRAM?

3) When I enter the ewfmgr -commit command, when does the committing
actually occur? The messages that are printed out by ewfmgr imply that it
happens immediately. With disk-based EWF it would happen during the next
reboot, but this is obviously not possible with RAM EWF.

Thanks in advance for clearing up these issues.

Doug G
 
Hi Doug. Glad you got it working. I'll address your points here:

(1) The one-reboot process is correct for RAM Reg configurations because FBA
skips the step where EWF would normally create its special partition. A RAM
Reg runtime stores its configuration info in the Registry rather than using
an overlay partition, so there is no need for it to create this partition.
Therefore, no extra reboot.


(2) No, because EWF has no innate knowledge of the size of the protected
partition. All it does is literally store all of the write operations that
would normally go to your protected partition, including file deletions.
Here's an example to illustrate how this works:

Create and save a file that is, say, 100 KB in size. EWF will store the
save operation to its overlay.
Delete the file.
Save the file again. EWF has now consumed a bit more than 200 KB of RAM to
store these operations, even though the net effect on the file system is
only 100 KB.

Because of this nature, EWF continues to allocate and consume memory for
every write operation, no matter what it is. This means that memory will
eventually fill up (beyond the 250 MB partition size), and you will need to
reboot the system. I recommend rebooting periodically to flush the overlay
and reclaim memory.

Several factors can affect how quickly your RAM is consumed by EWF and how
frequently you'd need to reboot: Generally, you will want to optimize your
runtime as much as possible, so that the OS does minimal writes to the
protected partition. Running on FAT16/FAT32 is more efficient than on NTFS
(since NTFS does quite a bit of file-system maintenance for its added
security benefits). Also, if you have the need to persist
application-specific data between boots, you can try adding a second,
unprotected partition to your target system and saving the data there.


(3) Commits are actually done during the shutdown process, not upon next
boot. This means that both Disk and RAM/RAM Reg overlays will be saved to
disk before the system shuts down or reboots.

Note: With RAM and RAM Reg overlays, there is one exception: Running "ewfmgr
c: -commitanddisable -live" will force the commit immediately and disable
the overlay, which means the partition will remain unprotected until you
issue the command to re-enable it and reboot. (This functionality was added
in SP2.)

--
Matt Kellner ([email protected])
STE, Windows Embedded Group

This posting is provided "AS IS" with no warranties, and confers no rights.
===============================
 
Matt Kellner (MS) said:
(2) No, because EWF has no innate knowledge of the size of the protected
partition. All it does is literally store all of the write operations
that would normally go to your protected partition, including file
deletions.
Click to expand...

Yikes! That is not good at all! These systems are used for industrial
automation in an auto factory, where they are expected to run standalone for
days, if not weeks, between reboots. Holding the assembly line costs the
company $10K per minute in lost profits, so telling them "excuse us for a
minute while we reboot" is not going to go over very well.

However, I might be able to prevent most all writes to the system drive,
mainly by going back from NTFS to FAT32 as you mentioned. And our
application is such that there should be little system drive writing unless
there is background O/S or network activity that I can't control.

We mainly got into this because the customer wants us to switch from hard
drives (which have proved unreliable as usual) to a flash drive. We have
been using disk-based EWF with a large partition and have not seen any space
issues that I know of, but I thought it inadvisable to put an EWF partition
on the much smaller flash drive, so am changing to RAM EWF. I guess we'll
have to wait and see how it goes.

Doug G
 
Matt Kellner (MS) said:
(2) No, because EWF has no innate knowledge of the size of the protected
partition. All it does is literally store all of the write operations
that would normally go to your protected partition, including file
deletions.
Click to expand...

After thinking about this a bit more, how can this work with regard to
reading a file from the protected drive if that file has been modified? Does
the filter have to go through the entire EWF data store to find the most
recent value that has been written to each sector? That does not sound very
efficient. I assumed that it would just cache the most recent contents of
any modified sector.

Doug G
 
Back
Top