FBWF and EWF

[Mike Warren]

I'm sure I remember reading somewhere that it is possible to have both
EWF and FBWF on the same system as long as only one is active at a time.

I added both components to my image with their "start" check boxes unchecked
and enabled FBWF at the point of creating my recovery image.

This works fine in so far as FBWF starts enabled on the next boot.

My problem is that if I then disable FBWF, and reboot, it is not possible
to enable EWF. "EWFMGR c:" reports "Failed getting protected volume
configuration with error 1". My EWF component was set to Ram (Reg) in TD.

Any ideas?

 

[Mike Warren]

Any ideas?

To follow on: I tried this on the hard drive I originally built the system
on and it works there. Can someone who knows confirm my following
assumptions:

1/ Both diskpart and XP Pro's Disk Management only report the 2 partitions
I expect to be there on both disks. There is no small partition listed.
Am I right in assuming I would be able to see any EWF partition if it
existed?

2/ I'm assuming the error I'm getting is because EWF expects a config
partition. I have checked the registry off line and
ControlSet001\Services\EWF\FBA "OVSize" is shown as 0. Does this value
instruct EWF not to use an overlay? If it's not this, where is the setting?

2/ I have noticed that when the EWF component is set to "Disk" in TD and
then changed back, the value for "EWF Partition Size in KBytes" remains at
1024. Could this cause what I'm seeing?

 

[crus]

Mike,
EWF RAM REG has its config in registry, so no extra partition is created.
Perhaps FBWF conflicts with its registry use.
Also check at the end of FBALOG ( in windows\fba ) if EWF setup is correct.
Regards
Raffaele

 

[Mike Warren]

EWF RAM REG has its config in registry, so no extra partition is created.
Perhaps FBWF conflicts with its registry use.
Also check at the end of FBALOG ( in windows\fba ) if EWF setup is correct.

Thanks for the reply Raffaele.

I'm trying to get some more information about how EWF works. I was
wondering about a possible conflict between EWF and FBWF. It's really
puzzling that I can restore this image to the same hard drive I created
it on and it will work fine.

 

[Matt Kellner \(MSFT\)]

Technically, having EWF and FBWF protecting the same partition is an
unsupported scenario, and as such it hasn't received a lot of testing. I'll
try to answer the operation question, though:

EWF RAM (Reg) mode does store its configuration info in the registry, but it
may not function properly if there is also an EWF configuration partition on
the hard drive. You can't always see that partition through Diskpart or
Disk Management tools - in all the tests I've run, it's been hit-or-miss as
to where I can see the extra partition, if one exists at all. The EWF
config partition is for Disk and RAM modes only.

When you set up EWF in Target Designer, having the EWF mode set to RAM (Reg)
automatically disables a step in FBA that initializes the config partition
(this step is enabled in RAM and Disk modes), so the partition should never
be created in this scenario. As such, the "OVSize" value actually doesn't
matter in this scenario - it really only matters in Disk mode, since it
specifies the size of the disk overlay, and neither RAM mode will use it.

I believe the problem lies in some low-level configuration info in the
registry that both EWF and FBWF rely on for their functions. Both filters
need to know what partitions they're protecting, in what modes, and whether
they're enabled or not. My suspicion is that when FBWF writes its config
info, it's overwriting a key used by EWF, and EWF "loses track" of that
partition. Then EWF tries to get its configuration info from the config
partition (which doesn't exist), and thus gives you the error message you
mentioned.

This right now is speculation on my part, since I don't currently have the
ability to verify this, but it makes sense given that EWF and FBWF *can*
coexist on the same system protecting different partitions.

 

[Mike Warren]

I'll try to answer the operation question, though:

Thank you.

EWF RAM (Reg) mode does store its configuration info in the registry,
but it may not function properly if there is also an EWF
configuration partition on the hard drive.

The reason I asked about the config partition is that the disk I use to
build the image has been partitioned many times and does have a bit of
free space on it. On this disk I can swap between FBWF and EWF at will.

In contrast, the disks it will not work on only have had 2 partitions
created (486MB and the rest of a 200GB drive) after using Diskpart's
"Clean" function. All the disks concerned are just standard SATA drives.

I was thinking that maybe the problem was an invisible EWF partition on
the disk that works.

My suspicion is that when
FBWF writes its config info, it's overwriting a key used by EWF, and
EWF "loses track" of that partition. Then EWF tries to get its
configuration info from the config partition (which doesn't exist),
and thus gives you the error message you mentioned.

This sounds plausible, especially if there is an invisible partition on
my master disk.

This right now is speculation on my part, since I don't currently
have the ability to verify this, but it makes sense given that EWF
and FBWF can coexist on the same system protecting different
partitions.

Is there any documentation that goes into more detail about where in
the registry the config information is stored? Perhaps I can fix up the
appropriate keys manually.

Stepping back a bit, the reason I want both filters is that I need to
support our current software which requires EWF, but in a few months
the new version will need FBWF instead. I really wanted to get away
from having to send out new OS recovery CDs and making sure everyone
updated their OS *before* downloading and installing the new software.

Do you know if there is any way to manually add FBWF to a completed and
working system?

To me, any of this stuff *should* be possible. I just don't have enough
information on the specifics of these filters. I've spent days
searching MSDN and Google and must have read the same basic documents
several times hoping I'd missed something.

 

[Mike Warren]

This sounds plausible, especially if there is an invisible partition
on my master disk.

Tomorrow, I'll get a brand new disk, create exactly the same partition
setup as the disks that don't work, and build my image from scratch. If
it also fails to work, then that will add credence to the invisible
partition theory.

My master disk is configured like this:

[486MB C:] [Unpartitioned 2GB] [approx 184MB D: (rest of drive)]

This was originally done so I could adjust the OS partition size as
needed for testing.

The final target drives:

[486MB C:] [approx 186MB D: (rest of drive)]

 

[Mike Warren]

Tomorrow, I'll get a brand new disk, create exactly the same partition
setup as the disks that don't work, and build my image from scratch.

This problem has nothing to do with FBWF.

After going around in circles for several hours I removed FBWF and
rebuilt the image.

Here is my procedure and results:

1/ Copy pre-FBA image to a hard drive connected to my system by a
USB-SATA adaptor.

2/ Connect the drive to a target machine via SATA and run FBA.

3/ Reconnect to my dev machine and copy all the files except System
Volume Information folder to a compressed recovery file with my custom
recovery program.

4/ Burn this recovery file on a boot CD along with my recovery program.

5/ Reconnect the hard drive to the target machine.

6/ Boot the recovery CD, which formats C: and then extracts all files
from the recovery image.

At this point EWF works fine.

7/ Connect a new hard drive to the target device and perform a recovery
from the boot CD again.

EWF fails here.

8/ Try an existing target device that is known to work with my older
XPe builds and the same recovery procedure.

EWF fails again.

9/ Recover my old SP2 (pre FP2007) based build to this same machine.

EWF works fine.


So... What has changed since SP2 that may cause this behaviour?

This is more serious than I originally thought because I can't
currently release a build with EWF at all.

 

[Matt Kellner \(MSFT\)]

I think part of what may be happening here is that you're essentially going
through a "System Cloning" scenario (even though it's technically not using
the System Cloning Tool), and it's possible that differences in each hard
drive's partition structure may be confusing EWF's configuration. Note that
to properly support having a single runtime being copied to multiple
devices, you should use the System Cloning Tool (fbreseal.exe) to "reseal"
the post-FBA image so that it can properly reinitialize itself on the new
target device. This may or may not help with EWF specifically, but it
sounds like there's a little too much room for variation in your scenario
for me to pin down an exact cause.

As a troubleshooting step, please try rebuilding your image with the System
Cloning Tool component included, set it up however works best for your
scenario, then perform your "burn to CD and redeploy" step immediately after
you reseal the image. Again, I cannot guarantee this will fix the problem,
but it will at least help me rule out a couple of possible causes.

It occurs to me that you mentioned this is on a SATA-based system. What
does the IDE chain look like in each target device? Is it exactly the same,
and do the systems have the same BIOS? If not, it's possible that the BIOS
on the system is causing the drives and individual partitions to enumerate
differently on each device, which can cause EWF to no longer be linked to
the correct hard drive partition. We have had a couple of earlier reports
of El Torito and USB Boot scenarios not working correctly on systems using
SATA hard drives because of enumeration problems, and they've had some
interesting and tricky workarounds.

As a proof-of-concept, do you have a set of two or more target devices
(don't have to be the same hardware) that have IDE-only hardware (no SATA)?
If so, here's something you could try to see if this is a problem with your
SATA-based devices, a problem somewhere in your procedure, or a bug in one
of our components:

* Create a new runtime with the following components:
* Winlogon Sample Macro
* Enhanced Write Filter (configure for RAM Reg mode)
* EWF Manager
* CMD - Command-Line Processor

* Resolve dependencies and build the runtime.
* Configure both devices the same way, with two partitions similar to your
SATA setup.
* Deploy the runtime to the first device and configure as appropriate.
* Repeat your recovery CD procedure and copy the runtime to the second
device.
* See if you continue to have problems with the FP2007 version of EWF.

My guess is that, based on what we've seen before, this procedure will work
correctly, but granted it's a more generalized runtime (Winlogon Sample
Macro should run on just about anything) and with a more limited set of
hardware. But to my knowledge, there weren't any changes to EWF itself that
should cause it to work any differently than the SP2 version in the scenario
you described, assuming both versions are configured the same way.

If you have the ability to test this out, please let me know how it works
for you. If you still have problems with it at that point, I'll forward it
to our product team. Thanks.

 

[Matt Kellner \(MSFT\)]

BTW, I found a thread on our Embedded Windows Forum that looks to be similar
to your situation. You might find this interesting.

http://forums.microsoft.com/EmbeddedWindows/ShowPost.aspx?PostID=1052561&SiteID=47

 

[Mike Warren]

confusing EWF's configuration. Note that to properly support having
a single runtime being copied to multiple devices, you should use the
System Cloning Tool (fbreseal.exe) to "reseal" the post-FBA image so
that it can properly reinitialize itself on the new target device.

Based on my initial tests, this seems to be the solution. I will do
more testing and report back here. This will take a couple of days as

XPe dev is only a very small part of my job, and I remember some
discussion several years ago that it was important not to run fbreseal
more than once on a build. With this in mind I had not planned to run
it until I had completed final configuration.

During my testing, I *think* I tried it at one point, but this was on a
build where EWF was already not working.

This may or may not help with EWF specifically, but it sounds like
there's a little too much room for variation in your scenario for me
to pin down an exact cause.

I wasn't aware fbreseal had anything to do with EWF RAM Reg.

Thanks for all your help.

 

[Mike Warren]

confusing EWF's configuration. Note that to properly support having
a single runtime being copied to multiple devices, you should use the
System Cloning Tool (fbreseal.exe) to "reseal" the post-FBA image so
that it can properly reinitialize itself on the new target device.

Based on my initial tests, this seems to be the solution. I will do
more testing and report back here. This will take a couple of days as
there does appear to be something a little odd (but good) happening.

XPe dev is only a very small part of my job, and I remember some
discussion several years ago that it was important not to run fbreseal
more than once on a build. With this in mind I had not planned to run
it until I had completed final configuration.

During my testing, I think I tried it at one point, but this was on a
build where EWF was already not working.

This may or may not help with EWF specifically, but it sounds like
there's a little too much room for variation in your scenario for me
to pin down an exact cause.

I wasn't aware fbreseal had anything to do with EWF RAM Reg.

Thanks for all your help.

 

[Mike Warren]

Based on my initial tests, this seems to be the solution.

Just to follow up; So far everything looks good. All I did was run
fbreseal just after FBA and it seems I can move the image to any drive
after that. I don't need to run fbreseal again.

I don't understand why so it may still come back and bite me. I'll just
need to do a lot of testing.

 

[Matt Kellner \(MSFT\)]

That sets my mind at ease. Good to know it's working for you now.

I think what's going on is that when you change devices, the SIDs
(system/security IDs) that identify various objects such as the hard drive
volumes, etc., change, and if the OS is not in a state to handle such a
change, some components stop working correctly. EWF is very sensitive to
that, but fbreseal causes all non-predefined SIDs (the computer SID, user
account IDs, etc., but not the Administrator account ID, which is
predefined) to change to a new random number, and components such as EWF
pick up those changes gracefully. I don't know the exact mechanics of this
process, but I'm glad to know that running fbreseal fixes the overall
problem.

As for why the behavior changed between SP2 and now: Not sure on that, but
EWF did take some fixes and changes (particularly to better support HORM)
that may have affected this scenario as well. That's most likely it.