Re: Registry-based RAM EWF questions
- From: "Matt Kellner \(MS\)" <mattkell@xxxxxxxxxxxxx>
- Date: Fri, 28 Oct 2005 11:02:33 -0700
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 (mattkell@xxxxxxxxxxxxxxxxxxxx)
STE, Windows Embedded Group
This posting is provided "AS IS" with no warranties, and confers no rights.
===============================
"Doug Gordon" <douglas.gordon@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:%23i$Xa672FHA.3420@xxxxxxxxxxxxxxxxxxxxxxx
> 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
>
.
- Follow-Ups:
- Re: Registry-based RAM EWF questions
- From: Doug Gordon
- Re: Registry-based RAM EWF questions
- From: Doug Gordon
- Re: Registry-based RAM EWF questions
- Prev by Date: Re: FBA Saving Hives Fail
- Next by Date: Autologon fails -- sometimes
- Previous by thread: Re: FBA Saving Hives Fail
- Next by thread: Re: Registry-based RAM EWF questions
- Index(es):
Relevant Pages
|
