Control Set creation and EWF

  • Thread starter Thread starter Peter Boden
  • Start date Start date
P

Peter Boden

This question has two parts.

First, I did some registry modifications for an image off line (loaded the
XPe system hive on my dev station). I added a key to this hive, unloaded it
and booted the XPe drive again. This key was added to ControlSet1 in
HKLM... Funny thing happened... Even though the drive is protected by a RAM
based EWF, changes were committed to the drive. When I analyzed the drive
again on my dev station, a new control set had been created, and somehow had
persisted. All the registry files had new modified times, as well as some
of the logs in the windows folder (setupact.log...). This only happens this
one time. After this has happened, subsequent boots show no changes to the
registry, and the registry file modification times never change, indicating
the EWF is working properly.

So, my first question is: does the addition of a new registry key cause XPe
to do a check point on the registry (create a new control set)?

My second question is, if a new control set is created, is it possible for
this to happen before the EWF is enabled?

Thanks,
Pete
 
Hi Peter,

Are you sure that EWF was working and enabled in your post FBA image. Before you changed values in offline registry.
Also values that you changed, it might help if you mention them to us.

RAM EWF when enabled should protect all changes made by XPe from reaching physical storage.

Regards,
Slobodan
 
The key was to fix the magic "lose an hour every time you power cycle"
issue. I added the DisableAutoDaylightTimeSet DWORD value to the
TimezoneInformation branch (HKLM/Control).

EWF was working correctly before I made the change.

I did notice that when I viewed the registry hive with my hex editor that
the key I added was prefeced with "New Value #1". That disappears after the
first time the OS boots. Is it possible that this gets treated as some type
of FBA action?


Slobodan Brcin (eMVP) said:
Hi Peter,

Are you sure that EWF was working and enabled in your post FBA image.
Before you changed values in offline registry.
 
Peter,
This question has two parts.

First, I did some registry modifications for an image off line (loaded the
XPe system hive on my dev station). I added a key to this hive, unloaded it
and booted the XPe drive again. This key was added to ControlSet1 in
HKLM...
Funny thing happened... Even though the drive is protected by a RAM
based EWF, changes were committed to the drive. When I analyzed the drive
again on my dev station, a new control set had been created, and somehow had
persisted. All the registry files had new modified times, as well as some
of the logs in the windows folder (setupact.log...). This only happens this
one time. After this has happened, subsequent boots show no changes to the
registry, and the registry file modification times never change, indicating
the EWF is working properly.

So, my first question is: does the addition of a new registry key cause XPe
to do a check point on the registry (create a new control set)?

On the first boot of XPe after you added the new key - what was the valiues of [HKLM\SYSTEM\Select], "Failed" ?
AFAIK, a general rule says: if you had made a change to a key under CurrentControlSet that caused the system to crash or etc., XP
(or 2K) would have copied that ControlSet to a new number (e.g., ControlSet003) and listed that in the "Failed" value.
Maybe adding the key offline is also considered as a 'crash' (some CRC check or etc.).
My second question is, if a new control set is created, is it possible for
this to happen before the EWF is enabled?

A new ControlSet gets created by the kernel at system initialization time. So, I think it is possible it happens before EWF.
 
Hi Peter,

I hope that you use "Load Hive"/"Unload Hive" options from regedit to load and unload hive that you need, Right? If not please tell
us how did you changed reg value, step by step.

Regards,
Slobodan
 
Konstantin,
Maybe adding the key offline is also considered as a 'crash' (some CRC check or etc.).

A new ControlSet gets created by the kernel at system initialization time. So, I think it is possible it happens before EWF.

How much in your opinion scale is that this is what is really happening?
It would sound disturbing to me. Since this would mean that if for some boot disk glitch if registry got corrupted during the read
operation, kernel would write back "corrected" registry to disk instead of crashing. And EWF would not protect us. This is not
acceptable behavior to me.

Regards,
Slobodan



KM said:
Peter,
This question has two parts.

First, I did some registry modifications for an image off line (loaded the
XPe system hive on my dev station). I added a key to this hive, unloaded it
and booted the XPe drive again. This key was added to ControlSet1 in
HKLM...
Funny thing happened... Even though the drive is protected by a RAM
based EWF, changes were committed to the drive. When I analyzed the drive
again on my dev station, a new control set had been created, and somehow had
persisted. All the registry files had new modified times, as well as some
of the logs in the windows folder (setupact.log...). This only happens this
one time. After this has happened, subsequent boots show no changes to the
registry, and the registry file modification times never change, indicating
the EWF is working properly.

So, my first question is: does the addition of a new registry key cause XPe
to do a check point on the registry (create a new control set)?

On the first boot of XPe after you added the new key - what was the valiues of [HKLM\SYSTEM\Select], "Failed" ?
AFAIK, a general rule says: if you had made a change to a key under CurrentControlSet that caused the system to crash or etc., XP
(or 2K) would have copied that ControlSet to a new number (e.g., ControlSet003) and listed that in the "Failed" value.
Maybe adding the key offline is also considered as a 'crash' (some CRC check or etc.).
My second question is, if a new control set is created, is it possible for
this to happen before the EWF is enabled?

A new ControlSet gets created by the kernel at system initialization time. So, I think it is possible it happens before EWF.
 
Slobodan,
How much in your opinion scale is that this is what is really happening?
It would sound disturbing to me. Since this would mean that if for some boot disk glitch if registry got corrupted during the read
operation, kernel would write back "corrected" registry to disk instead of crashing. And EWF would not protect us. This is not
acceptable behavior to me.

I think the CRC check (if happens) happens on boot (system init) time. That means the kernal would only create a new ControlSet at
the boot time when EWF does not protect the image yet.
And since the new ControlSet would have the EWF proper settings, it is self-reparing. (I think this is what happened in Peter's
case)
I don't see much troubles here but I am only guessing :-)

Regards,
Konstantin
KM said:
Peter,
This question has two parts.

First, I did some registry modifications for an image off line (loaded the
XPe system hive on my dev station). I added a key to this hive, unloaded it
and booted the XPe drive again. This key was added to ControlSet1 in
HKLM...
Funny thing happened... Even though the drive is protected by a RAM
based EWF, changes were committed to the drive. When I analyzed the drive
again on my dev station, a new control set had been created, and somehow had
persisted. All the registry files had new modified times, as well as some
of the logs in the windows folder (setupact.log...). This only happens this
one time. After this has happened, subsequent boots show no changes to the
registry, and the registry file modification times never change, indicating
the EWF is working properly.

So, my first question is: does the addition of a new registry key cause XPe
to do a check point on the registry (create a new control set)?

On the first boot of XPe after you added the new key - what was the valiues of [HKLM\SYSTEM\Select], "Failed" ?
AFAIK, a general rule says: if you had made a change to a key under CurrentControlSet that caused the system to crash or etc., XP
(or 2K) would have copied that ControlSet to a new number (e.g., ControlSet003) and listed that in the "Failed" value.
Maybe adding the key offline is also considered as a 'crash' (some CRC check or etc.).
My second question is, if a new control set is created, is it possible for
this to happen before the EWF is enabled?

A new ControlSet gets created by the kernel at system initialization time. So, I think it is possible it happens before EWF.
 
Konstantin,
I think the CRC check (if happens) happens on boot (system init) time. That means the kernal would only create a new ControlSet at
the boot time when EWF does not protect the image yet.
And since the new ControlSet would have the EWF proper settings, it is self-reparing. (I think this is what happened in Peter's
case)
I don't see much troubles here but I am only guessing :-)

If this would be a case then I'm worried that EWF would not protect me if some freaky bogus read operation happen during the boot
time and case OS to write corrections to disk.

Regards,
Slobodan
Regards,
Konstantin
KM said:
Peter,

This question has two parts.

First, I did some registry modifications for an image off line (loaded the
XPe system hive on my dev station). I added a key to this hive, unloaded it
and booted the XPe drive again. This key was added to ControlSet1 in
HKLM...

Funny thing happened... Even though the drive is protected by a RAM
based EWF, changes were committed to the drive. When I analyzed the drive
again on my dev station, a new control set had been created, and somehow had
persisted. All the registry files had new modified times, as well as some
of the logs in the windows folder (setupact.log...). This only happens this
one time. After this has happened, subsequent boots show no changes to the
registry, and the registry file modification times never change, indicating
the EWF is working properly.

So, my first question is: does the addition of a new registry key cause XPe
to do a check point on the registry (create a new control set)?

On the first boot of XPe after you added the new key - what was the valiues of [HKLM\SYSTEM\Select], "Failed" ?
AFAIK, a general rule says: if you had made a change to a key under CurrentControlSet that caused the system to crash or
etc.,
 
Back
Top