Move the Registry with Hibernate Once, Resume Many

  • Thread starter Thread starter martin.jeremy
  • Start date Start date
M

martin.jeremy

Hi,
I'm currently integrating a Hibernate Once Resume Many setup into our
current package that is dependant on configuration changes to the
registry (partly from 3erd party software). I have a configuration
partition set for the dismount trick to keep file system information
between HORM boots. the problem is the registry... is there a way to
move the registry hive files (such as %windir%\system32\config\system
and %windir%\system32\config\software) to a configuration partition and
still dismount it just before HORM is set? do NTFS Hard links work in
this case (set up a hard link from %windir%\system32\config\system to
%configpartition%\system)? is the only choice to make the registry
changes, commit them, and set up the hibernate file again?
Thanks in advance.
 
Hi Martin,
is there a way to
move the registry hive files (such as %windir%\system32\config\system
and %windir%\system32\config\software) to a configuration partition and
still dismount it just before HORM is set?

No :-(
But you can try some thing like reg branch export/import from your hiber application.
do NTFS Hard links work in this case
Hard links can't go outside of boundaries of one filesystem. So answer is NO.
is the only choice to make the registry
changes, commit them, and set up the hibernate file again?

Like I said you have limited option to export import certain registry branches from your application. (This is very limited)

Regards,
Slobodan
 
Thanks Slobodan.. that still leaves me with a couple questions though.
if an NTFS Junction is set up then, will the resulting registry changes
not get written to the second drive because the EWF would trap it?
also, how do you guys handle things like windows config changes
(network setup in particular)?
-Jeremy Martin

Hi Martin,


No :-(
But you can try some thing like reg branch export/import from your hiber application.

Hard links can't go outside of boundaries of one filesystem. So answer is NO.


Like I said you have limited option to export import certain registry
branches from your application. (This is very limited)
 
Hi Martin,

Please let me know if you can do "NTFS Junction" thing (what ever it is) so that you have registry hives on both partitions. (With
EWF disabled).
Basically there are many things why this can't be done for purpose that you need.
how do you guys handle things like windows config changes
(network setup in particular)?

You could do config setting changes each time after resume operation relinquish control to your application.

Basically you would have something like in your application:
1. Do some your saving stuff.
2. Unmount unprotected volumes.
3. Hibernate.
4. Load configuration parameters to windows. (Registry and setup changes)
5. Exit application.

Regards,
Slobodan
 
Slobodan,
I have had some success with my trials.
first off, you can find out more about NTFS Junctions at
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q205524
they are a little documented version of hard links (different
implementation really, but same idea) that target directories and can
traverse across partitions. I have found that a link set up on an EWF
partition that points to a non EWF partition will allow data to be
permanently written to the files, even if the file is opened from the
EWF partition. in effect this allows parts of an EWF partition to not
be EWF protected.
now the bad news... the registry cannot be moved in this way. whatever
system level means windows uses to access the registry seems to prevent
it from traversing NTFS junctions... the system simply says it cannot
find the system hive on boot up. this seems weird because junctions are
part of NTFS, and i would think even kernel activities should fully
support NTFS junctions. microsoft? are you listening???
normally you have to order the windows resource kit to get the linkd
utility to make junctions, but check out this free tool from
sysinternals to try making junctions yourself:
http://www.sysinternals.com/ntw2k/source/misc.shtml#junction
source code is included. any thoughts on this Slobodan? anyone else?
how do i take this to microsoft to push for junction support on reg
hives (i'm guessing my msdn subscription wont let me get that far)
 
Ah these are junction points :-) I have remembered after I posted reply.
These are not what you think that they are. And they are most likely not supported by ntldr. ntldr search for files and registry
hives based on ARC path, but let us consider for the moment that this all work as you want it to work.

You would have following situation that is not allowable since it would corrupt data.
1. Some registry entries are cached in memory as part of normal work.
2. You hibernate and make your image.
3. You resume.
4. You modify registry a little bit and flush changes (somehow) to unprotected partition. And dismount etc that partition (not
possible since registry would keep it open but nevermind)
5. You reboot computer on power switch.

6. You computer resume as in point 3.
7. You now have some values precached from memory as hibernation procedure recorded them. And some updated values that can be loaded
from registry that was successfully changed.

Now you see problem. (There are many other problems even not mentioned here, but even this rough estimate is enough)

Registry cannot be moved in this way. AFAIK registry mechanism implemented in kernel allow you to create subparts of registry in
memory or on different disk locations. (I do not know if it is documented legally how, but usually it is irrelevant).
With this approach you could create certain subkeys that are loaded from your hives on some other disk but this is not enough to
make system configurations to be applied :-( Just some your data can be managed in this way.

Now you could even fool kernel function that manipulate with registry and give them your virtual data, and it could even work, but
you still have one major problem.
For drivers that are loaded and use certain settings you would need to stop them and then to restart them so they read your newly
configured settings. And this is a big problem.

So hypothetically even if you can solve registry problem you would need to manage each started driver differently to apply last
settings that you made to them. And if you do that then you don't need all above-mentioned trouble since then you can reconfigure
drivers in flight anyway.

Regards,
Slobodan
PS:
Send feature request to MS:
http://msdn.microsoft.com/embedded/community/community/feedback/feedxp/default.aspx
 
Thanks Slobodan,
I see your point... i ran into a problem on forced shutdowns similar to
this some time ago (effectivly losing data because what was in memory
was different then the disk) and i got around that by forcing a flush
of the registry to disk just prior to power loss (it's quite possible).
moving subkeys like you mentioned is really what i need, mostly becuase
of 3erd party software out of my control (not windows). the driver
issue is less of an issue on our system then it might be on most
systems. we have a very limited working set and can restart drivers at
any point we need.
but at any rate, i'd never get the system to give up it's lock on the
registry hives so i couldnt unmount the partition anyway.
it sounds like i'm forced into a solution following your suggestion of
reimporting the registry and reconfiguring the system after each
resume, which may be time consuming.
at least i can make part of the drive now EWF protected (which was a
brick wall for other reasons until now).
i dont suppose if you know of any *legal* means of moving subkeys such
as you described?
 
Hi Martin,

I can't remember where I saw these infos :-(
But you might want to look at virtual registry entry
HKLM\system\ControlSet001\Control\hivelist
If you make it to exist always it might allow you to use some additional hives. (I have never tried this though)

Let us know if you find out something.

Regards,
Slobodan
 
i dont suppose if you know of any *legal* means of moving subkeys such
as you described?

Can you try using RegLoadKey/RegUnloadKey APIs?

Btw, do you know what registry branch is used by the 3rd party application? If you don't, monitor the app with Regmon.
If it appears that the app regulary change only Current User hive you can "unmount" it (by logoff, e.g.).

Another approach could be in replacing the application calls to registry APIs (create a stub for advapi32.dll) by your own where you
can safely redirect the application data to a file on the uprotected partition.
 
Back
Top