Storing persistent configuration on separate partition using RegLoadKey

[e7a7b7]

Hello all,

First, thanks to all, especially SB and KM, for a great newgroup.
Thanks to the quality and depth of the answers in the group, I've never
had to post a question before, and I've been using XPe for nearly 6
months.

So, here's our current scenario. We are planning to use RAM EWF with a
product that contains standard consumer-grade PC parts, meaning we have
a hard disk (80GB disk/2GB RAM). Our C: partition, which contains the
OS and application, is the only EWF protected partition and is about
1GB in size. The D: partition which is about 75GB, is used for data.
We don't do any EWF commit operations except during upgrade/downgrades.
The problem for us is where to store persistent configuration
information.

Now, I'm aware that what we really SHOULD have done in our app is to
store persistent configuration information in a file on the D: drive,
but unfortunately our application was not developed with this in mind,
and is instead very registry-dependent at this stage.

So, in an attempt to avoid having to perform a costly re-write of our
configuration architecture, I had an idea for a shortcut: has anybody
using EWF ever tried putting their configuration in a registry hive
file on an unprotected partition? The idea is that your application
can use RegLoadKey to load the hive file on every startup. This way
the application's config info is written and stored on the unprotected
partition without having to perform EWF commit operations, but you
still have all the benefits of using the registry.

I haven't actually tried this yet--one thing that's slowing down
testing is that we will still have to re-locate our config info within
the registry since one can only load hives directly under HKLM or HKU
(We're currently using HKLM\Software\[App]). But I wondered if anybody
has tried this, or if anybody sees any dangers with doing this?

Note that I'm not suggesting re-location of the existing registry hives
(SOFTWARE, SYSTEM, etc.)--only the reg info specific to our
application. I don't want to re-locate SOFTWARE or SYSTEM, because
these must remain protected by EWF.

Thanks,
Ryan

 

[Slobodan Brcin \(eMVP\)]

Ryan,

Few weeks ago I used undocumented REG_LINK parameter to create permanent
links in one of my test applications. I just run a search on the net and
found that someone already used this before me so at least I won't need to
write explanation how to use this.
http://www.ntinternals.net/regln/

Don't ask me how to use this tool (you will figure it out) since I have not
used it.

General idea that you can do is to create permanent links during the FBA
from certain registry branches that you use to some virtual paths for
instance HKLM\MyHive\subkey1

Key HKLM\Software\[App] will always exist and for Win32 reg functions it
will not be different from the keys that you have used, but you won't be
able to open it if you don't mount the hive with path that link points to.
You can place as many links as you want throughout the registry that will be
redirected to hive that you will manually load (you can load it from your
application or even before of that from service or some start application).

My idea is to figure out easiest way to automatically (or at least first
thigh after FS driver is loaded) load some hive from different partitions,
so that even certain drivers and services can pull information's from hive
on unprotected partition.

Please let us know how this work for you.

Regards,
Slobodan

Hello all,

First, thanks to all, especially SB and KM, for a great newgroup.
Thanks to the quality and depth of the answers in the group, I've never
had to post a question before, and I've been using XPe for nearly 6
months.

So, here's our current scenario. We are planning to use RAM EWF with a
product that contains standard consumer-grade PC parts, meaning we have
a hard disk (80GB disk/2GB RAM). Our C: partition, which contains the
OS and application, is the only EWF protected partition and is about
1GB in size. The D: partition which is about 75GB, is used for data.
We don't do any EWF commit operations except during upgrade/downgrades.
The problem for us is where to store persistent configuration
information.

Now, I'm aware that what we really SHOULD have done in our app is to
store persistent configuration information in a file on the D: drive,
but unfortunately our application was not developed with this in mind,
and is instead very registry-dependent at this stage.

So, in an attempt to avoid having to perform a costly re-write of our
configuration architecture, I had an idea for a shortcut: has anybody
using EWF ever tried putting their configuration in a registry hive
file on an unprotected partition? The idea is that your application
can use RegLoadKey to load the hive file on every startup. This way
the application's config info is written and stored on the unprotected
partition without having to perform EWF commit operations, but you
still have all the benefits of using the registry.

I haven't actually tried this yet--one thing that's slowing down
testing is that we will still have to re-locate our config info within
the registry since one can only load hives directly under HKLM or HKU
(We're currently using HKLM\Software\[App]). But I wondered if anybody
has tried this, or if anybody sees any dangers with doing this?

Note that I'm not suggesting re-location of the existing registry hives
(SOFTWARE, SYSTEM, etc.)--only the reg info specific to our
application. I don't want to re-locate SOFTWARE or SYSTEM, because
these must remain protected by EWF.

Thanks,
Ryan

 

[KM]

A while ago I was thinking about similar use of REG_LINK.
I also found some useful code: http://assarbad.net/stuff/!export/reglink.txt. Although it is Pascal code but it is really easy to
convert it to C. (you rather be interested in API calls).
(that time I started to think that anything undocumented is already explored and documented on the Web or Usenet )

Although, for application layer it may be easy to accomplish with RegLoadKey but then you have less flexibility on the reg.path.

Anyway, it would be beneficial to move to use an application profile that can be moved around much easier that registry
hives/branches. I am glad Microsoft finally came to the same conclusion and in .Net you operate with per application xml profile
files.

KM

Ryan,

Few weeks ago I used undocumented REG_LINK parameter to create permanent links in one of my test applications. I just run a search
on the net and found that someone already used this before me so at least I won't need to write explanation how to use this.
http://www.ntinternals.net/regln/

Don't ask me how to use this tool (you will figure it out) since I have not used it.

General idea that you can do is to create permanent links during the FBA from certain registry branches that you use to some
virtual paths for instance HKLM\MyHive\subkey1

Key HKLM\Software\[App] will always exist and for Win32 reg functions it will not be different from the keys that you have used,
but you won't be able to open it if you don't mount the hive with path that link points to.
You can place as many links as you want throughout the registry that will be redirected to hive that you will manually load (you
can load it from your application or even before of that from service or some start application).

My idea is to figure out easiest way to automatically (or at least first thigh after FS driver is loaded) load some hive from
different partitions, so that even certain drivers and services can pull information's from hive on unprotected partition.

Please let us know how this work for you.

Regards,
Slobodan

Hello all,

First, thanks to all, especially SB and KM, for a great newgroup.
Thanks to the quality and depth of the answers in the group, I've never
had to post a question before, and I've been using XPe for nearly 6
months.

So, here's our current scenario. We are planning to use RAM EWF with a
product that contains standard consumer-grade PC parts, meaning we have
a hard disk (80GB disk/2GB RAM). Our C: partition, which contains the
OS and application, is the only EWF protected partition and is about
1GB in size. The D: partition which is about 75GB, is used for data.
We don't do any EWF commit operations except during upgrade/downgrades.
The problem for us is where to store persistent configuration
information.

Now, I'm aware that what we really SHOULD have done in our app is to
store persistent configuration information in a file on the D: drive,
but unfortunately our application was not developed with this in mind,
and is instead very registry-dependent at this stage.

So, in an attempt to avoid having to perform a costly re-write of our
configuration architecture, I had an idea for a shortcut: has anybody
using EWF ever tried putting their configuration in a registry hive
file on an unprotected partition? The idea is that your application
can use RegLoadKey to load the hive file on every startup. This way
the application's config info is written and stored on the unprotected
partition without having to perform EWF commit operations, but you
still have all the benefits of using the registry.

I haven't actually tried this yet--one thing that's slowing down
testing is that we will still have to re-locate our config info within
the registry since one can only load hives directly under HKLM or HKU
(We're currently using HKLM\Software\[App]). But I wondered if anybody
has tried this, or if anybody sees any dangers with doing this?

Note that I'm not suggesting re-location of the existing registry hives
(SOFTWARE, SYSTEM, etc.)--only the reg info specific to our
application. I don't want to re-locate SOFTWARE or SYSTEM, because
these must remain protected by EWF.

Thanks,
Ryan

 

[e7a7b7]

Slobodan,

Thanks for the tip on the REG_LINK stuff--I didn't know such an
undocumented feature even existed.

I will indeed try this and let the group know how it goes. As for your
issue of loading the hive as early as possible, that's a tricky one.
For most applications, of course, this isn't an issue, but for
services, drivers, etc.--beats me. I imagine you'll have to research
into some more undocumented features... I've always thought that the
Run/RunOnce keys were insufficient tools for plugging into the startup
sequence, and this of course illustrates that again.

The only thing I could think of would be that if you knew what types of
drivers were loaded first (if there is even a determinable order in
which they are loaded), you could write a driver of that type to take
care of this for you. Probably you've already thought of this, though.

--Ryan

Ryan,

Few weeks ago I used undocumented REG_LINK parameter to create permanent
links in one of my test applications. I just run a search on the net and
found that someone already used this before me so at least I won't need to
write explanation how to use this.
http://www.ntinternals.net/regln/

Don't ask me how to use this tool (you will figure it out) since I have not
used it.

General idea that you can do is to create permanent links during the FBA
from certain registry branches that you use to some virtual paths for

instance HKLM\MyHive\subkey1

Key HKLM\Software\[App] will always exist and for Win32 reg functions it
will not be different from the keys that you have used, but you won't be
able to open it if you don't mount the hive with path that link points to.
You can place as many links as you want throughout the registry that will be
redirected to hive that you will manually load (you can load it from your
application or even before of that from service or some start application).

My idea is to figure out easiest way to automatically (or at least first
thigh after FS driver is loaded) load some hive from different partitions,
so that even certain drivers and services can pull information's from hive
on unprotected partition.

Please let us know how this work for you.

Regards,
Slobodan

Hello all,

First, thanks to all, especially SB and KM, for a great newgroup.
Thanks to the quality and depth of the answers in the group, I've never
had to post a question before, and I've been using XPe for nearly 6
months.

So, here's our current scenario. We are planning to use RAM EWF with a
product that contains standard consumer-grade PC parts, meaning we have
a hard disk (80GB disk/2GB RAM). Our C: partition, which contains the
OS and application, is the only EWF protected partition and is about
1GB in size. The D: partition which is about 75GB, is used for data.
We don't do any EWF commit operations except during upgrade/downgrades.
The problem for us is where to store persistent configuration
information.

Now, I'm aware that what we really SHOULD have done in our app is to
store persistent configuration information in a file on the D: drive,
but unfortunately our application was not developed with this in mind,
and is instead very registry-dependent at this stage.

So, in an attempt to avoid having to perform a costly re-write of our
configuration architecture, I had an idea for a shortcut: has anybody
using EWF ever tried putting their configuration in a registry hive
file on an unprotected partition? The idea is that your application
can use RegLoadKey to load the hive file on every startup. This way
the application's config info is written and stored on the unprotected
partition without having to perform EWF commit operations, but you
still have all the benefits of using the registry.

I haven't actually tried this yet--one thing that's slowing down
testing is that we will still have to re-locate our config info within
the registry since one can only load hives directly under HKLM or HKU
(We're currently using HKLM\Software\[App]). But I wondered if anybody
has tried this, or if anybody sees any dangers with doing this?

Note that I'm not suggesting re-location of the existing registry hives
(SOFTWARE, SYSTEM, etc.)--only the reg info specific to our
application. I don't want to re-locate SOFTWARE or SYSTEM, because
these must remain protected by EWF.

Thanks,
Ryan

 

[Slobodan Brcin \(eMVP\)]

Ryan,

I can solve this trough driver, basically it is should be simple. Just
register for Volume arrival notifications and when each new volume is
mounted we test whether we can load hive and if we can then we do that.
I was curious and hoping to figure out some more universal solution that
could tell to kernel what hive file should be loaded and where, but
existence of such feature is very questionable.

Regards,
Slobodan

Slobodan,

Thanks for the tip on the REG_LINK stuff--I didn't know such an
undocumented feature even existed.

I will indeed try this and let the group know how it goes. As for your
issue of loading the hive as early as possible, that's a tricky one.
For most applications, of course, this isn't an issue, but for
services, drivers, etc.--beats me. I imagine you'll have to research
into some more undocumented features... I've always thought that the
Run/RunOnce keys were insufficient tools for plugging into the startup
sequence, and this of course illustrates that again.

The only thing I could think of would be that if you knew what types of
drivers were loaded first (if there is even a determinable order in
which they are loaded), you could write a driver of that type to take
care of this for you. Probably you've already thought of this, though.

--Ryan

Ryan,

Few weeks ago I used undocumented REG_LINK parameter to create permanent
links in one of my test applications. I just run a search on the net and
found that someone already used this before me so at least I won't need to
write explanation how to use this.
http://www.ntinternals.net/regln/

Don't ask me how to use this tool (you will figure it out) since I have not
used it.

General idea that you can do is to create permanent links during the FBA
from certain registry branches that you use to some virtual paths for

instance HKLM\MyHive\subkey1

Key HKLM\Software\[App] will always exist and for Win32 reg functions it
will not be different from the keys that you have used, but you won't be
able to open it if you don't mount the hive with path that link points to.
You can place as many links as you want throughout the registry that will be
redirected to hive that you will manually load (you can load it from your
application or even before of that from service or some start application).

My idea is to figure out easiest way to automatically (or at least first
thigh after FS driver is loaded) load some hive from different partitions,
so that even certain drivers and services can pull information's from hive
on unprotected partition.

Please let us know how this work for you.

Regards,
Slobodan

Hello all,

First, thanks to all, especially SB and KM, for a great newgroup.
Thanks to the quality and depth of the answers in the group, I've never
had to post a question before, and I've been using XPe for nearly 6
months.

So, here's our current scenario. We are planning to use RAM EWF with a
product that contains standard consumer-grade PC parts, meaning we have
a hard disk (80GB disk/2GB RAM). Our C: partition, which contains the
OS and application, is the only EWF protected partition and is about
1GB in size. The D: partition which is about 75GB, is used for data.
We don't do any EWF commit operations except during upgrade/downgrades.
The problem for us is where to store persistent configuration
information.

Now, I'm aware that what we really SHOULD have done in our app is to
store persistent configuration information in a file on the D: drive,
but unfortunately our application was not developed with this in mind,
and is instead very registry-dependent at this stage.

So, in an attempt to avoid having to perform a costly re-write of our
configuration architecture, I had an idea for a shortcut: has anybody
using EWF ever tried putting their configuration in a registry hive
file on an unprotected partition? The idea is that your application
can use RegLoadKey to load the hive file on every startup. This way
the application's config info is written and stored on the unprotected
partition without having to perform EWF commit operations, but you
still have all the benefits of using the registry.

I haven't actually tried this yet--one thing that's slowing down
testing is that we will still have to re-locate our config info within
the registry since one can only load hives directly under HKLM or HKU
(We're currently using HKLM\Software\[App]). But I wondered if anybody
has tried this, or if anybody sees any dangers with doing this?

Note that I'm not suggesting re-location of the existing registry hives
(SOFTWARE, SYSTEM, etc.)--only the reg info specific to our
application. I don't want to re-locate SOFTWARE or SYSTEM, because
these must remain protected by EWF.

Thanks,
Ryan

 

[e7a7b7]

KM,

Thanks for additional comments and the code link. I definitely agree
that moving to an application profile as you describe is preferable.
Hopefully, though, using RegLoadKey and the REG_LINK feature can get us
working in the meantime until we are ready to make such a change.

I'm not sure I understand what you mean by "less flexibility on the
reg.path"--could you elaborate on that?

--Ryan

 

[KM]

Ryan,

KM,

Thanks for additional comments and the code link. I definitely agree
that moving to an application profile as you describe is preferable.
Hopefully, though, using RegLoadKey and the REG_LINK feature can get us
working in the meantime until we are ready to make such a change.

I'm not sure I understand what you mean by "less flexibility on the
reg.path"--could you elaborate on that?

Nevermind it.
I just meant that with RegLoadKey you can load information at the top of the registry hierarchy (HKEY_LOCAL_MACHINE, HKEY_USERS).
I'd prefer having a way to move some part(s) of, say, software hive to another drive and load it up with an API to merge into
existing SOFTWARE hive. I can do similar on WinCE but I definitely have more flexibility there in a platform OEM adaptation than on
XPe.

 

[KM]

Slobodan,

Did you try [HKLM\SYSTEM\CurrentControlSet\Control\hivelist]?

My understand was that the system (the kernel init part code that os loader passes the control to) only creates
\REGISTRY\MACHINE\SYSTEM and \REGISTRY\MACHINE\HARDWARE link nodes and always looks for hive files under \systemroot\system32\config
dir. To me it seemed that the path is hardcoded.

However, ntinternals guys say that the Configuration Manager refers to the \hivelist values when it needs to locate the hives'
files.
http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=5195

--
Regards,
KM, BSquare Corp.

Ryan,

I can solve this trough driver, basically it is should be simple. Just
register for Volume arrival notifications and when each new volume is
mounted we test whether we can load hive and if we can then we do that.
I was curious and hoping to figure out some more universal solution that
could tell to kernel what hive file should be loaded and where, but
existence of such feature is very questionable.

Regards,
Slobodan

Slobodan,

Thanks for the tip on the REG_LINK stuff--I didn't know such an
undocumented feature even existed.

I will indeed try this and let the group know how it goes. As for your
issue of loading the hive as early as possible, that's a tricky one.
For most applications, of course, this isn't an issue, but for
services, drivers, etc.--beats me. I imagine you'll have to research
into some more undocumented features... I've always thought that the
Run/RunOnce keys were insufficient tools for plugging into the startup
sequence, and this of course illustrates that again.

The only thing I could think of would be that if you knew what types of
drivers were loaded first (if there is even a determinable order in
which they are loaded), you could write a driver of that type to take
care of this for you. Probably you've already thought of this, though.

--Ryan

Ryan,

Few weeks ago I used undocumented REG_LINK parameter to create permanent
links in one of my test applications. I just run a search on the net and
found that someone already used this before me so at least I won't need to
write explanation how to use this.
http://www.ntinternals.net/regln/

Don't ask me how to use this tool (you will figure it out) since I have not
used it.

General idea that you can do is to create permanent links during the FBA
from certain registry branches that you use to some virtual paths for

instance HKLM\MyHive\subkey1

Key HKLM\Software\[App] will always exist and for Win32 reg functions it
will not be different from the keys that you have used, but you won't be
able to open it if you don't mount the hive with path that link points to.
You can place as many links as you want throughout the registry that will be
redirected to hive that you will manually load (you can load it from your
application or even before of that from service or some start application).

My idea is to figure out easiest way to automatically (or at least first
thigh after FS driver is loaded) load some hive from different partitions,
so that even certain drivers and services can pull information's from hive
on unprotected partition.

Please let us know how this work for you.

Regards,
Slobodan


Hello all,

First, thanks to all, especially SB and KM, for a great newgroup.
Thanks to the quality and depth of the answers in the group, I've never
had to post a question before, and I've been using XPe for nearly 6
months.

So, here's our current scenario. We are planning to use RAM EWF with a
product that contains standard consumer-grade PC parts, meaning we have
a hard disk (80GB disk/2GB RAM). Our C: partition, which contains the
OS and application, is the only EWF protected partition and is about
1GB in size. The D: partition which is about 75GB, is used for data.
We don't do any EWF commit operations except during upgrade/downgrades.
The problem for us is where to store persistent configuration
information.

Now, I'm aware that what we really SHOULD have done in our app is to
store persistent configuration information in a file on the D: drive,
but unfortunately our application was not developed with this in mind,
and is instead very registry-dependent at this stage.

So, in an attempt to avoid having to perform a costly re-write of our
configuration architecture, I had an idea for a shortcut: has anybody
using EWF ever tried putting their configuration in a registry hive
file on an unprotected partition? The idea is that your application
can use RegLoadKey to load the hive file on every startup. This way
the application's config info is written and stored on the unprotected
partition without having to perform EWF commit operations, but you
still have all the benefits of using the registry.

I haven't actually tried this yet--one thing that's slowing down
testing is that we will still have to re-locate our config info within
the registry since one can only load hives directly under HKLM or HKU
(We're currently using HKLM\Software\[App]). But I wondered if anybody
has tried this, or if anybody sees any dangers with doing this?

Note that I'm not suggesting re-location of the existing registry hives
(SOFTWARE, SYSTEM, etc.)--only the reg info specific to our
application. I don't want to re-locate SOFTWARE or SYSTEM, because
these must remain protected by EWF.

Thanks,
Ryan

 

[Slobodan Brcin \(eMVP\)]

Konstantin,

I'd prefer having a way to move some part(s) of, say, software hive to
another drive and load it up with an API to merge into

This is why i sugested using both ReLoadKey and fixed links. You could move
all interested parts of software system hives to separate external hive.

Regards,
Slobodan

 

[Slobodan Brcin \(eMVP\)]

Konstantin,

I think that I have tried them but values here are only written for who
knows what reasons at the time when hives are actually mounted. If you write
values there they are not used during the boot :-(
But I think that there is an API that allow us to replace hive on use with
new initialized hive file on next boot. I have never tried this so I do not
know what mechanism is used for this, I will do that sometime.

Regards,
Slobodan

Slobodan,

Did you try [HKLM\SYSTEM\CurrentControlSet\Control\hivelist]?

My understand was that the system (the kernel init part code that os
loader passes the control to) only creates
\REGISTRY\MACHINE\SYSTEM and \REGISTRY\MACHINE\HARDWARE link nodes and
always looks for hive files under \systemroot\system32\config
dir. To me it seemed that the path is hardcoded.

However, ntinternals guys say that the Configuration Manager refers to the
\hivelist values when it needs to locate the hives'
files.
http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=5195

--
Regards,
KM, BSquare Corp.

Ryan,

I can solve this trough driver, basically it is should be simple. Just
register for Volume arrival notifications and when each new volume is
mounted we test whether we can load hive and if we can then we do that.
I was curious and hoping to figure out some more universal solution that
could tell to kernel what hive file should be loaded and where, but
existence of such feature is very questionable.

Regards,
Slobodan

Slobodan,

Thanks for the tip on the REG_LINK stuff--I didn't know such an
undocumented feature even existed.

I will indeed try this and let the group know how it goes. As for your
issue of loading the hive as early as possible, that's a tricky one.
For most applications, of course, this isn't an issue, but for
services, drivers, etc.--beats me. I imagine you'll have to research
into some more undocumented features... I've always thought that the
Run/RunOnce keys were insufficient tools for plugging into the startup
sequence, and this of course illustrates that again.

The only thing I could think of would be that if you knew what types of
drivers were loaded first (if there is even a determinable order in
which they are loaded), you could write a driver of that type to take
care of this for you. Probably you've already thought of this, though.

--Ryan

Slobodan Brcin (eMVP) wrote:
Ryan,

Few weeks ago I used undocumented REG_LINK parameter to create
permanent
links in one of my test applications. I just run a search on the net
and
found that someone already used this before me so at least I won't
need to
write explanation how to use this.
http://www.ntinternals.net/regln/

Don't ask me how to use this tool (you will figure it out) since I
have not
used it.

General idea that you can do is to create permanent links during the
FBA
from certain registry branches that you use to some virtual paths for

instance HKLM\MyHive\subkey1

Key HKLM\Software\[App] will always exist and for Win32 reg functions
it
will not be different from the keys that you have used, but you won't
be
able to open it if you don't mount the hive with path that link
points to.
You can place as many links as you want throughout the registry that
will be
redirected to hive that you will manually load (you can load it from
your
application or even before of that from service or some start
application).

My idea is to figure out easiest way to automatically (or at least
first
thigh after FS driver is loaded) load some hive from different
partitions,
so that even certain drivers and services can pull information's from
hive
on unprotected partition.

Please let us know how this work for you.

Regards,
Slobodan


Hello all,

First, thanks to all, especially SB and KM, for a great newgroup.
Thanks to the quality and depth of the answers in the group, I've
never
had to post a question before, and I've been using XPe for nearly 6
months.

So, here's our current scenario. We are planning to use RAM EWF
with a
product that contains standard consumer-grade PC parts, meaning we
have
a hard disk (80GB disk/2GB RAM). Our C: partition, which contains
the
OS and application, is the only EWF protected partition and is
about
1GB in size. The D: partition which is about 75GB, is used for
data.
We don't do any EWF commit operations except during
upgrade/downgrades.
The problem for us is where to store persistent configuration
information.

Now, I'm aware that what we really SHOULD have done in our app is
to
store persistent configuration information in a file on the D:
drive,
but unfortunately our application was not developed with this in
mind,
and is instead very registry-dependent at this stage.

So, in an attempt to avoid having to perform a costly re-write of
our
configuration architecture, I had an idea for a shortcut: has
anybody
using EWF ever tried putting their configuration in a registry hive
file on an unprotected partition? The idea is that your
application
can use RegLoadKey to load the hive file on every startup. This
way
the application's config info is written and stored on the
unprotected
partition without having to perform EWF commit operations, but you
still have all the benefits of using the registry.

I haven't actually tried this yet--one thing that's slowing down
testing is that we will still have to re-locate our config info
within
the registry since one can only load hives directly under HKLM or
HKU
(We're currently using HKLM\Software\[App]). But I wondered if
anybody
has tried this, or if anybody sees any dangers with doing this?

Note that I'm not suggesting re-location of the existing registry
hives
(SOFTWARE, SYSTEM, etc.)--only the reg info specific to our
application. I don't want to re-locate SOFTWARE or SYSTEM, because
these must remain protected by EWF.

Thanks,
Ryan

 

[KM]

Slobodan,

Konstantin,

I think that I have tried them but values here are only written for who
knows what reasons at the time when hives are actually mounted. If you write
values there they are not used during the boot :-(

Yup.. I agree. I also think these registry values are only written by the kernel on boot.
Perhaps they are in registry for backup purpose (so that the backup software - VSS service - knows about what registry hives must be
backed up and then restored):
http://msdn.microsoft.com/library/d...y_backup_and_restore_operations_under_vss.asp

But I think that there is an API that allow us to replace hive on use with
new initialized hive file on next boot. I have never tried this so I do not
know what mechanism is used for this, I will do that sometime.

Are you referringto RegReplaceKey API here?
(check out the steps at the end of the article I provided the link to above)

--
Regards,
Konstantin

Slobodan,

Did you try [HKLM\SYSTEM\CurrentControlSet\Control\hivelist]?

My understand was that the system (the kernel init part code that os
loader passes the control to) only creates
\REGISTRY\MACHINE\SYSTEM and \REGISTRY\MACHINE\HARDWARE link nodes and
always looks for hive files under \systemroot\system32\config
dir. To me it seemed that the path is hardcoded.

However, ntinternals guys say that the Configuration Manager refers to the
\hivelist values when it needs to locate the hives'
files.
http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=5195

--
Regards,
KM, BSquare Corp.

Ryan,

I can solve this trough driver, basically it is should be simple. Just
register for Volume arrival notifications and when each new volume is
mounted we test whether we can load hive and if we can then we do that.
I was curious and hoping to figure out some more universal solution that
could tell to kernel what hive file should be loaded and where, but
existence of such feature is very questionable.

Regards,
Slobodan

Slobodan,

Thanks for the tip on the REG_LINK stuff--I didn't know such an
undocumented feature even existed.

I will indeed try this and let the group know how it goes. As for your
issue of loading the hive as early as possible, that's a tricky one.
For most applications, of course, this isn't an issue, but for
services, drivers, etc.--beats me. I imagine you'll have to research
into some more undocumented features... I've always thought that the
Run/RunOnce keys were insufficient tools for plugging into the startup
sequence, and this of course illustrates that again.

The only thing I could think of would be that if you knew what types of
drivers were loaded first (if there is even a determinable order in
which they are loaded), you could write a driver of that type to take
care of this for you. Probably you've already thought of this, though.

--Ryan

Slobodan Brcin (eMVP) wrote:
Ryan,

Few weeks ago I used undocumented REG_LINK parameter to create
permanent
links in one of my test applications. I just run a search on the net
and
found that someone already used this before me so at least I won't
need to
write explanation how to use this.
http://www.ntinternals.net/regln/

Don't ask me how to use this tool (you will figure it out) since I
have not
used it.

General idea that you can do is to create permanent links during the
FBA
from certain registry branches that you use to some virtual paths for

instance HKLM\MyHive\subkey1

Key HKLM\Software\[App] will always exist and for Win32 reg functions
it
will not be different from the keys that you have used, but you won't
be
able to open it if you don't mount the hive with path that link
points to.
You can place as many links as you want throughout the registry that
will be
redirected to hive that you will manually load (you can load it from
your
application or even before of that from service or some start
application).

My idea is to figure out easiest way to automatically (or at least
first
thigh after FS driver is loaded) load some hive from different
partitions,
so that even certain drivers and services can pull information's from
hive
on unprotected partition.

Please let us know how this work for you.

Regards,
Slobodan


Hello all,

First, thanks to all, especially SB and KM, for a great newgroup.
Thanks to the quality and depth of the answers in the group, I've
never
had to post a question before, and I've been using XPe for nearly 6
months.

So, here's our current scenario. We are planning to use RAM EWF
with a
product that contains standard consumer-grade PC parts, meaning we
have
a hard disk (80GB disk/2GB RAM). Our C: partition, which contains
the
OS and application, is the only EWF protected partition and is
about
1GB in size. The D: partition which is about 75GB, is used for
data.
We don't do any EWF commit operations except during
upgrade/downgrades.
The problem for us is where to store persistent configuration
information.

Now, I'm aware that what we really SHOULD have done in our app is
to
store persistent configuration information in a file on the D:
drive,
but unfortunately our application was not developed with this in
mind,
and is instead very registry-dependent at this stage.

So, in an attempt to avoid having to perform a costly re-write of
our
configuration architecture, I had an idea for a shortcut: has
anybody
using EWF ever tried putting their configuration in a registry hive
file on an unprotected partition? The idea is that your
application
can use RegLoadKey to load the hive file on every startup. This
way
the application's config info is written and stored on the
unprotected
partition without having to perform EWF commit operations, but you
still have all the benefits of using the registry.

I haven't actually tried this yet--one thing that's slowing down
testing is that we will still have to re-locate our config info
within
the registry since one can only load hives directly under HKLM or
HKU
(We're currently using HKLM\Software\[App]). But I wondered if
anybody
has tried this, or if anybody sees any dangers with doing this?

Note that I'm not suggesting re-location of the existing registry
hives
(SOFTWARE, SYSTEM, etc.)--only the reg info specific to our
application. I don't want to re-locate SOFTWARE or SYSTEM, because
these must remain protected by EWF.

Thanks,
Ryan

 

[Slobodan Brcin \(eMVP\)]

Konstantin,

Are you referringto RegReplaceKey API here?

Yes. Do you know how it works when does the actual swap occur?

Regards,
Slobodan

Slobodan,

Konstantin,

I think that I have tried them but values here are only written for who
knows what reasons at the time when hives are actually mounted. If you
write
values there they are not used during the boot :-(

Yup.. I agree. I also think these registry values are only written by the
kernel on boot.
Perhaps they are in registry for backup purpose (so that the backup
software - VSS service - knows about what registry hives must be
backed up and then restored):
http://msdn.microsoft.com/library/d...y_backup_and_restore_operations_under_vss.asp

But I think that there is an API that allow us to replace hive on use
with
new initialized hive file on next boot. I have never tried this so I do
not
know what mechanism is used for this, I will do that sometime.

Are you referringto RegReplaceKey API here?
(check out the steps at the end of the article I provided the link to
above)

--
Regards,
Konstantin

Slobodan,

Did you try [HKLM\SYSTEM\CurrentControlSet\Control\hivelist]?

My understand was that the system (the kernel init part code that os
loader passes the control to) only creates
\REGISTRY\MACHINE\SYSTEM and \REGISTRY\MACHINE\HARDWARE link nodes and
always looks for hive files under \systemroot\system32\config
dir. To me it seemed that the path is hardcoded.

However, ntinternals guys say that the Configuration Manager refers to
the
\hivelist values when it needs to locate the hives'
files.
http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=5195

--
Regards,
KM, BSquare Corp.


Ryan,

I can solve this trough driver, basically it is should be simple. Just
register for Volume arrival notifications and when each new volume is
mounted we test whether we can load hive and if we can then we do
that.
I was curious and hoping to figure out some more universal solution
that
could tell to kernel what hive file should be loaded and where, but
existence of such feature is very questionable.

Regards,
Slobodan

Slobodan,

Thanks for the tip on the REG_LINK stuff--I didn't know such an
undocumented feature even existed.

I will indeed try this and let the group know how it goes. As for
your
issue of loading the hive as early as possible, that's a tricky one.
For most applications, of course, this isn't an issue, but for
services, drivers, etc.--beats me. I imagine you'll have to
research
into some more undocumented features... I've always thought that
the
Run/RunOnce keys were insufficient tools for plugging into the
startup
sequence, and this of course illustrates that again.

The only thing I could think of would be that if you knew what types
of
drivers were loaded first (if there is even a determinable order in
which they are loaded), you could write a driver of that type to
take
care of this for you. Probably you've already thought of this,
though.

--Ryan

Slobodan Brcin (eMVP) wrote:
Ryan,

Few weeks ago I used undocumented REG_LINK parameter to create
permanent
links in one of my test applications. I just run a search on the
net
and
found that someone already used this before me so at least I won't
need to
write explanation how to use this.
http://www.ntinternals.net/regln/

Don't ask me how to use this tool (you will figure it out) since I
have not
used it.

General idea that you can do is to create permanent links during
the
FBA
from certain registry branches that you use to some virtual paths
for

instance HKLM\MyHive\subkey1

Key HKLM\Software\[App] will always exist and for Win32 reg
functions
it
will not be different from the keys that you have used, but you
won't
be
able to open it if you don't mount the hive with path that link
points to.
You can place as many links as you want throughout the registry
that
will be
redirected to hive that you will manually load (you can load it
from
your
application or even before of that from service or some start
application).

My idea is to figure out easiest way to automatically (or at least
first
thigh after FS driver is loaded) load some hive from different
partitions,
so that even certain drivers and services can pull information's
from
hive
on unprotected partition.

Please let us know how this work for you.

Regards,
Slobodan


Hello all,

First, thanks to all, especially SB and KM, for a great newgroup.
Thanks to the quality and depth of the answers in the group, I've
never
had to post a question before, and I've been using XPe for nearly
6
months.

So, here's our current scenario. We are planning to use RAM EWF
with a
product that contains standard consumer-grade PC parts, meaning
we
have
a hard disk (80GB disk/2GB RAM). Our C: partition, which
contains
the
OS and application, is the only EWF protected partition and is
about
1GB in size. The D: partition which is about 75GB, is used for
data.
We don't do any EWF commit operations except during
upgrade/downgrades.
The problem for us is where to store persistent configuration
information.

Now, I'm aware that what we really SHOULD have done in our app is
to
store persistent configuration information in a file on the D:
drive,
but unfortunately our application was not developed with this in
mind,
and is instead very registry-dependent at this stage.

So, in an attempt to avoid having to perform a costly re-write of
our
configuration architecture, I had an idea for a shortcut: has
anybody
using EWF ever tried putting their configuration in a registry
hive
file on an unprotected partition? The idea is that your
application
can use RegLoadKey to load the hive file on every startup. This
way
the application's config info is written and stored on the
unprotected
partition without having to perform EWF commit operations, but
you
still have all the benefits of using the registry.

I haven't actually tried this yet--one thing that's slowing down
testing is that we will still have to re-locate our config info
within
the registry since one can only load hives directly under HKLM or
HKU
(We're currently using HKLM\Software\[App]). But I wondered if
anybody
has tried this, or if anybody sees any dangers with doing this?

Note that I'm not suggesting re-location of the existing registry
hives
(SOFTWARE, SYSTEM, etc.)--only the reg info specific to our
application. I don't want to re-locate SOFTWARE or SYSTEM,
because
these must remain protected by EWF.

Thanks,
Ryan

 

[KM]

Slobodan,

Konstantin,

Yes. Do you know how it works when does the actual swap occur?

No, I don't :-(
My guess was that it really happens on during registry detach (on system exit/shutdown). It is not done through MoveFileEx routine.
This must be something within MS VMM registry library (vmmreg32.dll).

Btw, I think FBA uses the RegReplaceKey API (perhaps in FBASaveAndReplaceSystemHives call). You can verify that in Export/Import
sections of fbalib.dll.
My guess it does that for compacting the system hives making them less fragmented after much of installation happened.

Regards,
Konstantin

Slobodan,

Konstantin,

I think that I have tried them but values here are only written for who
knows what reasons at the time when hives are actually mounted. If you
write
values there they are not used during the boot :-(

Yup.. I agree. I also think these registry values are only written by the
kernel on boot.
Perhaps they are in registry for backup purpose (so that the backup
software - VSS service - knows about what registry hives must be
backed up and then restored):
http://msdn.microsoft.com/library/d...y_backup_and_restore_operations_under_vss.asp

But I think that there is an API that allow us to replace hive on use
with
new initialized hive file on next boot. I have never tried this so I do
not
know what mechanism is used for this, I will do that sometime.

Are you referringto RegReplaceKey API here?
(check out the steps at the end of the article I provided the link to
above)

--
Regards,
Konstantin

Slobodan,

Did you try [HKLM\SYSTEM\CurrentControlSet\Control\hivelist]?

My understand was that the system (the kernel init part code that os
loader passes the control to) only creates
\REGISTRY\MACHINE\SYSTEM and \REGISTRY\MACHINE\HARDWARE link nodes and
always looks for hive files under \systemroot\system32\config
dir. To me it seemed that the path is hardcoded.

However, ntinternals guys say that the Configuration Manager refers to
the
\hivelist values when it needs to locate the hives'
files.
http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=5195

--
Regards,
KM, BSquare Corp.


Ryan,

I can solve this trough driver, basically it is should be simple. Just
register for Volume arrival notifications and when each new volume is
mounted we test whether we can load hive and if we can then we do
that.
I was curious and hoping to figure out some more universal solution
that
could tell to kernel what hive file should be loaded and where, but
existence of such feature is very questionable.

Regards,
Slobodan

Slobodan,

Thanks for the tip on the REG_LINK stuff--I didn't know such an
undocumented feature even existed.

I will indeed try this and let the group know how it goes. As for
your
issue of loading the hive as early as possible, that's a tricky one.
For most applications, of course, this isn't an issue, but for
services, drivers, etc.--beats me. I imagine you'll have to
research
into some more undocumented features... I've always thought that
the
Run/RunOnce keys were insufficient tools for plugging into the
startup
sequence, and this of course illustrates that again.

The only thing I could think of would be that if you knew what types
of
drivers were loaded first (if there is even a determinable order in
which they are loaded), you could write a driver of that type to
take
care of this for you. Probably you've already thought of this,
though.

--Ryan

Slobodan Brcin (eMVP) wrote:
Ryan,

Few weeks ago I used undocumented REG_LINK parameter to create
permanent
links in one of my test applications. I just run a search on the
net
and
found that someone already used this before me so at least I won't
need to
write explanation how to use this.
http://www.ntinternals.net/regln/

Don't ask me how to use this tool (you will figure it out) since I
have not
used it.

General idea that you can do is to create permanent links during
the
FBA
from certain registry branches that you use to some virtual paths
for

instance HKLM\MyHive\subkey1

Key HKLM\Software\[App] will always exist and for Win32 reg
functions
it
will not be different from the keys that you have used, but you
won't
be
able to open it if you don't mount the hive with path that link
points to.
You can place as many links as you want throughout the registry
that
will be
redirected to hive that you will manually load (you can load it
from
your
application or even before of that from service or some start
application).

My idea is to figure out easiest way to automatically (or at least
first
thigh after FS driver is loaded) load some hive from different
partitions,
so that even certain drivers and services can pull information's
from
hive
on unprotected partition.

Please let us know how this work for you.

Regards,
Slobodan


Hello all,

First, thanks to all, especially SB and KM, for a great newgroup.
Thanks to the quality and depth of the answers in the group, I've
never
had to post a question before, and I've been using XPe for nearly
6
months.

So, here's our current scenario. We are planning to use RAM EWF
with a
product that contains standard consumer-grade PC parts, meaning
we
have
a hard disk (80GB disk/2GB RAM). Our C: partition, which
contains
the
OS and application, is the only EWF protected partition and is
about
1GB in size. The D: partition which is about 75GB, is used for
data.
We don't do any EWF commit operations except during
upgrade/downgrades.
The problem for us is where to store persistent configuration
information.

Now, I'm aware that what we really SHOULD have done in our app is
to
store persistent configuration information in a file on the D:
drive,
but unfortunately our application was not developed with this in
mind,
and is instead very registry-dependent at this stage.

So, in an attempt to avoid having to perform a costly re-write of
our
configuration architecture, I had an idea for a shortcut: has
anybody
using EWF ever tried putting their configuration in a registry
hive
file on an unprotected partition? The idea is that your
application
can use RegLoadKey to load the hive file on every startup. This
way
the application's config info is written and stored on the
unprotected
partition without having to perform EWF commit operations, but
you
still have all the benefits of using the registry.

I haven't actually tried this yet--one thing that's slowing down
testing is that we will still have to re-locate our config info
within
the registry since one can only load hives directly under HKLM or
HKU
(We're currently using HKLM\Software\[App]). But I wondered if
anybody
has tried this, or if anybody sees any dangers with doing this?

Note that I'm not suggesting re-location of the existing registry
hives
(SOFTWARE, SYSTEM, etc.)--only the reg info specific to our
application. I don't want to re-locate SOFTWARE or SYSTEM,
because
these must remain protected by EWF.

Thanks,
Ryan

 

[KM]

Slobodan,

No, I don't :-(
My guess was that it really happens on during registry detach (on system exit/shutdown). It is not done through MoveFileEx
routine.
This must be something within MS VMM registry library (vmmreg32.dll).

I was totaly wrong in my guess above. (vmmreg32 is probaly just a wrapper but I don't know what it is for. Maybe some Win95 legacy)
According to this (http://www.sysinternals.com/ntw2k/info/ntdll.shtml), the RegReplaceKey is just mapped to NtReplaceKey.
The latter is described here:
http://undocumented.ntinternals.net/UserMode/Undocumented Functions/NT Objects/Key/NtReplaceKey.html.

It seems that the NtReplaceKey will internally end up with a kernel call to ZwSetInformationFile with FileRenameInformation
parameter passed (see DDK).
Great doc about NT/XP registry can be found here:
http://www.i.u-tokyo.ac.jp/ss/lecture/new-documents/Lectures/09-Registry/Registry.pdf

Regards,
Konstantin

I think that I have tried them but values here are only written for who
knows what reasons at the time when hives are actually mounted. If you
write
values there they are not used during the boot :-(


Yup.. I agree. I also think these registry values are only written by the
kernel on boot.
Perhaps they are in registry for backup purpose (so that the backup
software - VSS service - knows about what registry hives must be
backed up and then restored):
http://msdn.microsoft.com/library/d...y_backup_and_restore_operations_under_vss.asp


But I think that there is an API that allow us to replace hive on use
with
new initialized hive file on next boot. I have never tried this so I do
not
know what mechanism is used for this, I will do that sometime.

Are you referringto RegReplaceKey API here?
(check out the steps at the end of the article I provided the link to
above)

--
Regards,
Konstantin

Slobodan,

Did you try [HKLM\SYSTEM\CurrentControlSet\Control\hivelist]?

My understand was that the system (the kernel init part code that os
loader passes the control to) only creates
\REGISTRY\MACHINE\SYSTEM and \REGISTRY\MACHINE\HARDWARE link nodes and
always looks for hive files under \systemroot\system32\config
dir. To me it seemed that the path is hardcoded.

However, ntinternals guys say that the Configuration Manager refers to
the
\hivelist values when it needs to locate the hives'
files.
http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=5195

--
Regards,
KM, BSquare Corp.


Ryan,

I can solve this trough driver, basically it is should be simple. Just
register for Volume arrival notifications and when each new volume is
mounted we test whether we can load hive and if we can then we do
that.
I was curious and hoping to figure out some more universal solution
that
could tell to kernel what hive file should be loaded and where, but
existence of such feature is very questionable.

Regards,
Slobodan

Slobodan,

Thanks for the tip on the REG_LINK stuff--I didn't know such an
undocumented feature even existed.

I will indeed try this and let the group know how it goes. As for
your
issue of loading the hive as early as possible, that's a tricky one.
For most applications, of course, this isn't an issue, but for
services, drivers, etc.--beats me. I imagine you'll have to
research
into some more undocumented features... I've always thought that
the
Run/RunOnce keys were insufficient tools for plugging into the
startup
sequence, and this of course illustrates that again.

The only thing I could think of would be that if you knew what types
of
drivers were loaded first (if there is even a determinable order in
which they are loaded), you could write a driver of that type to
take
care of this for you. Probably you've already thought of this,
though.

--Ryan

Slobodan Brcin (eMVP) wrote:
Ryan,

Few weeks ago I used undocumented REG_LINK parameter to create
permanent
links in one of my test applications. I just run a search on the
net
and
found that someone already used this before me so at least I won't
need to
write explanation how to use this.
http://www.ntinternals.net/regln/

Don't ask me how to use this tool (you will figure it out) since I
have not
used it.

General idea that you can do is to create permanent links during
the
FBA
from certain registry branches that you use to some virtual paths
for

instance HKLM\MyHive\subkey1

Key HKLM\Software\[App] will always exist and for Win32 reg
functions
it
will not be different from the keys that you have used, but you
won't
be
able to open it if you don't mount the hive with path that link
points to.
You can place as many links as you want throughout the registry
that
will be
redirected to hive that you will manually load (you can load it
from
your
application or even before of that from service or some start
application).

My idea is to figure out easiest way to automatically (or at least
first
thigh after FS driver is loaded) load some hive from different
partitions,
so that even certain drivers and services can pull information's
from
hive
on unprotected partition.

Please let us know how this work for you.

Regards,
Slobodan


Hello all,

First, thanks to all, especially SB and KM, for a great newgroup.
Thanks to the quality and depth of the answers in the group, I've
never
had to post a question before, and I've been using XPe for nearly
6
months.

So, here's our current scenario. We are planning to use RAM EWF
with a
product that contains standard consumer-grade PC parts, meaning
we
have
a hard disk (80GB disk/2GB RAM). Our C: partition, which
contains
the
OS and application, is the only EWF protected partition and is
about
1GB in size. The D: partition which is about 75GB, is used for
data.
We don't do any EWF commit operations except during
upgrade/downgrades.
The problem for us is where to store persistent configuration
information.

Now, I'm aware that what we really SHOULD have done in our app is
to
store persistent configuration information in a file on the D:
drive,
but unfortunately our application was not developed with this in
mind,
and is instead very registry-dependent at this stage.

So, in an attempt to avoid having to perform a costly re-write of
our
configuration architecture, I had an idea for a shortcut: has
anybody
using EWF ever tried putting their configuration in a registry
hive
file on an unprotected partition? The idea is that your
application
can use RegLoadKey to load the hive file on every startup. This
way
the application's config info is written and stored on the
unprotected
partition without having to perform EWF commit operations, but
you
still have all the benefits of using the registry.

I haven't actually tried this yet--one thing that's slowing down
testing is that we will still have to re-locate our config info
within
the registry since one can only load hives directly under HKLM or
HKU
(We're currently using HKLM\Software\[App]). But I wondered if
anybody
has tried this, or if anybody sees any dangers with doing this?

Note that I'm not suggesting re-location of the existing registry
hives
(SOFTWARE, SYSTEM, etc.)--only the reg info specific to our
application. I don't want to re-locate SOFTWARE or SYSTEM,
because
these must remain protected by EWF.

Thanks,
Ryan

 

[Slobodan Brcin \(eMVP\)]

Konstantin,

According to description hive will be replaced immediately. I have no idea
how they accomplish to do that since many keys can be open.
Also what would be the purpose of this function? You can use it on non
standard hives that you loaded for some reason. But why would you use it on
regular hives. I mean I have no idea why MS even bothered to create such
function?

Great doc about NT/XP registry can be found here:

Really great doc. Thanks for this doc.

Regards,
Slobodan

Slobodan,

No, I don't :-(
My guess was that it really happens on during registry detach (on system
exit/shutdown). It is not done through MoveFileEx routine.
This must be something within MS VMM registry library (vmmreg32.dll).

I was totaly wrong in my guess above. (vmmreg32 is probaly just a wrapper
but I don't know what it is for. Maybe some Win95 legacy)
According to this (http://www.sysinternals.com/ntw2k/info/ntdll.shtml),
the RegReplaceKey is just mapped to NtReplaceKey.
The latter is described here:
http://undocumented.ntinternals.net/UserMode/Undocumented Functions/NT Objects/Key/NtReplaceKey.html.

It seems that the NtReplaceKey will internally end up with a kernel call
to ZwSetInformationFile with FileRenameInformation parameter passed (see
DDK).
Great doc about NT/XP registry can be found here:
http://www.i.u-tokyo.ac.jp/ss/lecture/new-documents/Lectures/09-Registry/Registry.pdf

Regards,
Konstantin

I think that I have tried them but values here are only written for
who
knows what reasons at the time when hives are actually mounted. If
you
write
values there they are not used during the boot :-(


Yup.. I agree. I also think these registry values are only written by
the
kernel on boot.
Perhaps they are in registry for backup purpose (so that the backup
software - VSS service - knows about what registry hives must be
backed up and then restored):
http://msdn.microsoft.com/library/d...y_backup_and_restore_operations_under_vss.asp


But I think that there is an API that allow us to replace hive on use
with
new initialized hive file on next boot. I have never tried this so I
do
not
know what mechanism is used for this, I will do that sometime.

Are you referringto RegReplaceKey API here?
(check out the steps at the end of the article I provided the link to
above)

--
Regards,
Konstantin

Slobodan,

Did you try [HKLM\SYSTEM\CurrentControlSet\Control\hivelist]?

My understand was that the system (the kernel init part code that
os
loader passes the control to) only creates
\REGISTRY\MACHINE\SYSTEM and \REGISTRY\MACHINE\HARDWARE link nodes
and
always looks for hive files under \systemroot\system32\config
dir. To me it seemed that the path is hardcoded.

However, ntinternals guys say that the Configuration Manager refers
to
the
\hivelist values when it needs to locate the hives'
files.
http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=5195

--
Regards,
KM, BSquare Corp.


Ryan,

I can solve this trough driver, basically it is should be simple.
Just
register for Volume arrival notifications and when each new volume
is
mounted we test whether we can load hive and if we can then we do
that.
I was curious and hoping to figure out some more universal
solution
that
could tell to kernel what hive file should be loaded and where,
but
existence of such feature is very questionable.

Regards,
Slobodan

Slobodan,

Thanks for the tip on the REG_LINK stuff--I didn't know such an
undocumented feature even existed.

I will indeed try this and let the group know how it goes. As
for
your
issue of loading the hive as early as possible, that's a tricky
one.
For most applications, of course, this isn't an issue, but for
services, drivers, etc.--beats me. I imagine you'll have to
research
into some more undocumented features... I've always thought
that
the
Run/RunOnce keys were insufficient tools for plugging into the
startup
sequence, and this of course illustrates that again.

The only thing I could think of would be that if you knew what
types
of
drivers were loaded first (if there is even a determinable order
in
which they are loaded), you could write a driver of that type to
take
care of this for you. Probably you've already thought of this,
though.

--Ryan

Slobodan Brcin (eMVP) wrote:
Ryan,

Few weeks ago I used undocumented REG_LINK parameter to create
permanent
links in one of my test applications. I just run a search on
the
net
and
found that someone already used this before me so at least I
won't
need to
write explanation how to use this.
http://www.ntinternals.net/regln/

Don't ask me how to use this tool (you will figure it out)
since I
have not
used it.

General idea that you can do is to create permanent links
during
the
FBA
from certain registry branches that you use to some virtual
paths
for

instance HKLM\MyHive\subkey1

Key HKLM\Software\[App] will always exist and for Win32 reg
functions
it
will not be different from the keys that you have used, but you
won't
be
able to open it if you don't mount the hive with path that link
points to.
You can place as many links as you want throughout the registry
that
will be
redirected to hive that you will manually load (you can load it
from
your
application or even before of that from service or some start
application).

My idea is to figure out easiest way to automatically (or at
least
first
thigh after FS driver is loaded) load some hive from different
partitions,
so that even certain drivers and services can pull
information's
from
hive
on unprotected partition.

Please let us know how this work for you.

Regards,
Slobodan


Hello all,

First, thanks to all, especially SB and KM, for a great
newgroup.
Thanks to the quality and depth of the answers in the group,
I've
never
had to post a question before, and I've been using XPe for
nearly
6
months.

So, here's our current scenario. We are planning to use RAM
EWF
with a
product that contains standard consumer-grade PC parts,
meaning
we
have
a hard disk (80GB disk/2GB RAM). Our C: partition, which
contains
the
OS and application, is the only EWF protected partition and
is
about
1GB in size. The D: partition which is about 75GB, is used
for
data.
We don't do any EWF commit operations except during
upgrade/downgrades.
The problem for us is where to store persistent configuration
information.

Now, I'm aware that what we really SHOULD have done in our
app is
to
store persistent configuration information in a file on the
D:
drive,
but unfortunately our application was not developed with this
in
mind,
and is instead very registry-dependent at this stage.

So, in an attempt to avoid having to perform a costly
re-write of
our
configuration architecture, I had an idea for a shortcut: has
anybody
using EWF ever tried putting their configuration in a
registry
hive
file on an unprotected partition? The idea is that your
application
can use RegLoadKey to load the hive file on every startup.
This
way
the application's config info is written and stored on the
unprotected
partition without having to perform EWF commit operations,
but
you
still have all the benefits of using the registry.

I haven't actually tried this yet--one thing that's slowing
down
testing is that we will still have to re-locate our config
info
within
the registry since one can only load hives directly under
HKLM or
HKU
(We're currently using HKLM\Software\[App]). But I wondered
if
anybody
has tried this, or if anybody sees any dangers with doing
this?

Note that I'm not suggesting re-location of the existing
registry
hives
(SOFTWARE, SYSTEM, etc.)--only the reg info specific to our
application. I don't want to re-locate SOFTWARE or SYSTEM,
because
these must remain protected by EWF.

Thanks,
Ryan

 

[KM]

Slobodan,

According to description hive will be replaced immediately. I have no idea how they accomplish to do that since many keys can be
open.

I don't know how the ZwSetInformationFile works interneally. What if it renames a locked file only on reboot?

Also what would be the purpose of this function? You can use it on non standard hives that you loaded for some reason. But why
would you use it on regular hives. I mean I have no idea why MS even bothered to create such function?

Well.. As I said, one purposes would be decreasing system hives' fragmentation. You write a hive to a new file (RegSaveKey) and it
is getting compacted this way.

Really great doc. Thanks for this doc.

Yup.
Interesting fact.. I happened to find a lot of interesting and publicly available Windows Internals documents on .jp domain only.

Regards,
Konstantin

Slobodan,

Are you referringto RegReplaceKey API here?
Yes. Do you know how it works when does the actual swap occur?

No, I don't :-(
My guess was that it really happens on during registry detach (on system exit/shutdown). It is not done through MoveFileEx
routine.
This must be something within MS VMM registry library (vmmreg32.dll).

I was totaly wrong in my guess above. (vmmreg32 is probaly just a wrapper but I don't know what it is for. Maybe some Win95
legacy)
According to this (http://www.sysinternals.com/ntw2k/info/ntdll.shtml), the RegReplaceKey is just mapped to NtReplaceKey.
The latter is described here:
http://undocumented.ntinternals.net/UserMode/Undocumented Functions/NT Objects/Key/NtReplaceKey.html.

It seems that the NtReplaceKey will internally end up with a kernel call to ZwSetInformationFile with FileRenameInformation
parameter passed (see DDK).
Great doc about NT/XP registry can be found here:
http://www.i.u-tokyo.ac.jp/ss/lecture/new-documents/Lectures/09-Registry/Registry.pdf

Regards,
Konstantin

I think that I have tried them but values here are only written for who
knows what reasons at the time when hives are actually mounted. If you
write
values there they are not used during the boot :-(


Yup.. I agree. I also think these registry values are only written by the
kernel on boot.
Perhaps they are in registry for backup purpose (so that the backup
software - VSS service - knows about what registry hives must be
backed up and then restored):
http://msdn.microsoft.com/library/d...y_backup_and_restore_operations_under_vss.asp


But I think that there is an API that allow us to replace hive on use
with
new initialized hive file on next boot. I have never tried this so I do
not
know what mechanism is used for this, I will do that sometime.

Are you referringto RegReplaceKey API here?
(check out the steps at the end of the article I provided the link to
above)

--
Regards,
Konstantin

Slobodan,

Did you try [HKLM\SYSTEM\CurrentControlSet\Control\hivelist]?

My understand was that the system (the kernel init part code that os
loader passes the control to) only creates
\REGISTRY\MACHINE\SYSTEM and \REGISTRY\MACHINE\HARDWARE link nodes and
always looks for hive files under \systemroot\system32\config
dir. To me it seemed that the path is hardcoded.

However, ntinternals guys say that the Configuration Manager refers to
the
\hivelist values when it needs to locate the hives'
files.
http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=5195

--
Regards,
KM, BSquare Corp.


Ryan,

I can solve this trough driver, basically it is should be simple. Just
register for Volume arrival notifications and when each new volume is
mounted we test whether we can load hive and if we can then we do
that.
I was curious and hoping to figure out some more universal solution
that
could tell to kernel what hive file should be loaded and where, but
existence of such feature is very questionable.

Regards,
Slobodan

Slobodan,

Thanks for the tip on the REG_LINK stuff--I didn't know such an
undocumented feature even existed.

I will indeed try this and let the group know how it goes. As for
your
issue of loading the hive as early as possible, that's a tricky one.
For most applications, of course, this isn't an issue, but for
services, drivers, etc.--beats me. I imagine you'll have to
research
into some more undocumented features... I've always thought that
the
Run/RunOnce keys were insufficient tools for plugging into the
startup
sequence, and this of course illustrates that again.

The only thing I could think of would be that if you knew what types
of
drivers were loaded first (if there is even a determinable order in
which they are loaded), you could write a driver of that type to
take
care of this for you. Probably you've already thought of this,
though.

--Ryan

Slobodan Brcin (eMVP) wrote:
Ryan,

Few weeks ago I used undocumented REG_LINK parameter to create
permanent
links in one of my test applications. I just run a search on the
net
and
found that someone already used this before me so at least I won't
need to
write explanation how to use this.
http://www.ntinternals.net/regln/

Don't ask me how to use this tool (you will figure it out) since I
have not
used it.

General idea that you can do is to create permanent links during
the
FBA
from certain registry branches that you use to some virtual paths
for

instance HKLM\MyHive\subkey1

Key HKLM\Software\[App] will always exist and for Win32 reg
functions
it
will not be different from the keys that you have used, but you
won't
be
able to open it if you don't mount the hive with path that link
points to.
You can place as many links as you want throughout the registry
that
will be
redirected to hive that you will manually load (you can load it
from
your
application or even before of that from service or some start
application).

My idea is to figure out easiest way to automatically (or at least
first
thigh after FS driver is loaded) load some hive from different
partitions,
so that even certain drivers and services can pull information's
from
hive
on unprotected partition.

Please let us know how this work for you.

Regards,
Slobodan


Hello all,

First, thanks to all, especially SB and KM, for a great newgroup.
Thanks to the quality and depth of the answers in the group, I've
never
had to post a question before, and I've been using XPe for nearly
6
months.

So, here's our current scenario. We are planning to use RAM EWF
with a
product that contains standard consumer-grade PC parts, meaning
we
have
a hard disk (80GB disk/2GB RAM). Our C: partition, which
contains
the
OS and application, is the only EWF protected partition and is
about
1GB in size. The D: partition which is about 75GB, is used for
data.
We don't do any EWF commit operations except during
upgrade/downgrades.
The problem for us is where to store persistent configuration
information.

Now, I'm aware that what we really SHOULD have done in our app is
to
store persistent configuration information in a file on the D:
drive,
but unfortunately our application was not developed with this in
mind,
and is instead very registry-dependent at this stage.

So, in an attempt to avoid having to perform a costly re-write of
our
configuration architecture, I had an idea for a shortcut: has
anybody
using EWF ever tried putting their configuration in a registry
hive
file on an unprotected partition? The idea is that your
application
can use RegLoadKey to load the hive file on every startup. This
way
the application's config info is written and stored on the
unprotected
partition without having to perform EWF commit operations, but
you
still have all the benefits of using the registry.

I haven't actually tried this yet--one thing that's slowing down
testing is that we will still have to re-locate our config info
within
the registry since one can only load hives directly under HKLM or
HKU
(We're currently using HKLM\Software\[App]). But I wondered if
anybody
has tried this, or if anybody sees any dangers with doing this?

Note that I'm not suggesting re-location of the existing registry
hives
(SOFTWARE, SYSTEM, etc.)--only the reg info specific to our
application. I don't want to re-locate SOFTWARE or SYSTEM,
because
these must remain protected by EWF.

Thanks,
Ryan

 

[Slobodan Brcin \(eMVP\)]

Konstantin,

Well.. As I said, one purposes would be decreasing system hives'
fragmentation. You write a hive to a new file (RegSaveKey) and it is
getting compacted this way.

IIRC Last time I checked this I had some strange results with compacting in
that way.
1. Software hive grow for 100 KB (It was 40+MB large).
2. System hive shrinked 3 times.

so figure this out, I was not able to do so.

Regards,
Slobodan

Slobodan,

According to description hive will be replaced immediately. I have no
idea how they accomplish to do that since many keys can be open.

I don't know how the ZwSetInformationFile works interneally. What if it
renames a locked file only on reboot?

Also what would be the purpose of this function? You can use it on non
standard hives that you loaded for some reason. But why would you use it
on regular hives. I mean I have no idea why MS even bothered to create
such function?

Well.. As I said, one purposes would be decreasing system hives'
fragmentation. You write a hive to a new file (RegSaveKey) and it is
getting compacted this way.

Really great doc. Thanks for this doc.

Yup.
Interesting fact.. I happened to find a lot of interesting and publicly
available Windows Internals documents on .jp domain only.

Regards,
Konstantin

Slobodan,

Are you referringto RegReplaceKey API here?
Yes. Do you know how it works when does the actual swap occur?

No, I don't :-(
My guess was that it really happens on during registry detach (on
system exit/shutdown). It is not done through MoveFileEx routine.
This must be something within MS VMM registry library (vmmreg32.dll).

I was totaly wrong in my guess above. (vmmreg32 is probaly just a
wrapper but I don't know what it is for. Maybe some Win95 legacy)
According to this (http://www.sysinternals.com/ntw2k/info/ntdll.shtml),
the RegReplaceKey is just mapped to NtReplaceKey.
The latter is described here:
http://undocumented.ntinternals.net/UserMode/Undocumented Functions/NT Objects/Key/NtReplaceKey.html.

It seems that the NtReplaceKey will internally end up with a kernel call
to ZwSetInformationFile with FileRenameInformation parameter passed (see
DDK).
Great doc about NT/XP registry can be found here:
http://www.i.u-tokyo.ac.jp/ss/lecture/new-documents/Lectures/09-Registry/Registry.pdf

Regards,
Konstantin


I think that I have tried them but values here are only written for
who
knows what reasons at the time when hives are actually mounted. If
you
write
values there they are not used during the boot :-(


Yup.. I agree. I also think these registry values are only written
by the
kernel on boot.
Perhaps they are in registry for backup purpose (so that the backup
software - VSS service - knows about what registry hives must be
backed up and then restored):
http://msdn.microsoft.com/library/d...y_backup_and_restore_operations_under_vss.asp


But I think that there is an API that allow us to replace hive on
use
with
new initialized hive file on next boot. I have never tried this so
I do
not
know what mechanism is used for this, I will do that sometime.

Are you referringto RegReplaceKey API here?
(check out the steps at the end of the article I provided the link
to
above)

--
Regards,
Konstantin

Slobodan,

Did you try [HKLM\SYSTEM\CurrentControlSet\Control\hivelist]?

My understand was that the system (the kernel init part code that
os
loader passes the control to) only creates
\REGISTRY\MACHINE\SYSTEM and \REGISTRY\MACHINE\HARDWARE link
nodes and
always looks for hive files under \systemroot\system32\config
dir. To me it seemed that the path is hardcoded.

However, ntinternals guys say that the Configuration Manager
refers to
the
\hivelist values when it needs to locate the hives'
files.
http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=5195

--
Regards,
KM, BSquare Corp.


Ryan,

I can solve this trough driver, basically it is should be
simple. Just
register for Volume arrival notifications and when each new
volume is
mounted we test whether we can load hive and if we can then we
do
that.
I was curious and hoping to figure out some more universal
solution
that
could tell to kernel what hive file should be loaded and where,
but
existence of such feature is very questionable.

Regards,
Slobodan

Slobodan,

Thanks for the tip on the REG_LINK stuff--I didn't know such
an
undocumented feature even existed.

I will indeed try this and let the group know how it goes. As
for
your
issue of loading the hive as early as possible, that's a
tricky one.
For most applications, of course, this isn't an issue, but for
services, drivers, etc.--beats me. I imagine you'll have to
research
into some more undocumented features... I've always thought
that
the
Run/RunOnce keys were insufficient tools for plugging into the
startup
sequence, and this of course illustrates that again.

The only thing I could think of would be that if you knew what
types
of
drivers were loaded first (if there is even a determinable
order in
which they are loaded), you could write a driver of that type
to
take
care of this for you. Probably you've already thought of
this,
though.

--Ryan

Slobodan Brcin (eMVP) wrote:
Ryan,

Few weeks ago I used undocumented REG_LINK parameter to
create
permanent
links in one of my test applications. I just run a search on
the
net
and
found that someone already used this before me so at least I
won't
need to
write explanation how to use this.
http://www.ntinternals.net/regln/

Don't ask me how to use this tool (you will figure it out)
since I
have not
used it.

General idea that you can do is to create permanent links
during
the
FBA
from certain registry branches that you use to some virtual
paths
for

instance HKLM\MyHive\subkey1

Key HKLM\Software\[App] will always exist and for Win32 reg
functions
it
will not be different from the keys that you have used, but
you
won't
be
able to open it if you don't mount the hive with path that
link
points to.
You can place as many links as you want throughout the
registry
that
will be
redirected to hive that you will manually load (you can load
it
from
your
application or even before of that from service or some start
application).

My idea is to figure out easiest way to automatically (or at
least
first
thigh after FS driver is loaded) load some hive from
different
partitions,
so that even certain drivers and services can pull
information's
from
hive
on unprotected partition.

Please let us know how this work for you.

Regards,
Slobodan


Hello all,

First, thanks to all, especially SB and KM, for a great
newgroup.
Thanks to the quality and depth of the answers in the
group, I've
never
had to post a question before, and I've been using XPe for
nearly
6
months.

So, here's our current scenario. We are planning to use
RAM EWF
with a
product that contains standard consumer-grade PC parts,
meaning
we
have
a hard disk (80GB disk/2GB RAM). Our C: partition, which
contains
the
OS and application, is the only EWF protected partition and
is
about
1GB in size. The D: partition which is about 75GB, is used
for
data.
We don't do any EWF commit operations except during
upgrade/downgrades.
The problem for us is where to store persistent
configuration
information.

Now, I'm aware that what we really SHOULD have done in our
app is
to
store persistent configuration information in a file on the
D:
drive,
but unfortunately our application was not developed with
this in
mind,
and is instead very registry-dependent at this stage.

So, in an attempt to avoid having to perform a costly
re-write of
our
configuration architecture, I had an idea for a shortcut:
has
anybody
using EWF ever tried putting their configuration in a
registry
hive
file on an unprotected partition? The idea is that your
application
can use RegLoadKey to load the hive file on every startup.
This
way
the application's config info is written and stored on the
unprotected
partition without having to perform EWF commit operations,
but
you
still have all the benefits of using the registry.

I haven't actually tried this yet--one thing that's slowing
down
testing is that we will still have to re-locate our config
info
within
the registry since one can only load hives directly under
HKLM or
HKU
(We're currently using HKLM\Software\[App]). But I
wondered if
anybody
has tried this, or if anybody sees any dangers with doing
this?

Note that I'm not suggesting re-location of the existing
registry
hives
(SOFTWARE, SYSTEM, etc.)--only the reg info specific to our
application. I don't want to re-locate SOFTWARE or SYSTEM,
because
these must remain protected by EWF.

Thanks,
Ryan

 

[KM]

Slobodan,

IIRC Last time I checked this I had some strange results with compacting in
that way.
1. Software hive grow for 100 KB (It was 40+MB large).
2. System hive shrinked 3 times.

so figure this out, I was not able to do so.

The first result is a bit wierd. Certainly defragmantation does not promise to compact any file but still better results would be
expected.

Well.. You could "test" the fragmentation with PageDefrag from sysinternals. Basically, you would see how many clusters and
fragments the SOFTWARE hive comsumed.
That could shed some light on why it did not get compacted.

http://www.sysinternals.com/ntw2k/freeware/pagedefrag.shtml


Regards,
Konstantin

Slobodan,

According to description hive will be replaced immediately. I have no
idea how they accomplish to do that since many keys can be open.

I don't know how the ZwSetInformationFile works interneally. What if it
renames a locked file only on reboot?

Also what would be the purpose of this function? You can use it on non
standard hives that you loaded for some reason. But why would you use it
on regular hives. I mean I have no idea why MS even bothered to create
such function?

Well.. As I said, one purposes would be decreasing system hives'
fragmentation. You write a hive to a new file (RegSaveKey) and it is
getting compacted this way.

Great doc about NT/XP registry can be found here:
Really great doc. Thanks for this doc.

Yup.
Interesting fact.. I happened to find a lot of interesting and publicly
available Windows Internals documents on .jp domain only.

Regards,
Konstantin

Slobodan,

Are you referringto RegReplaceKey API here?
Yes. Do you know how it works when does the actual swap occur?

No, I don't :-(
My guess was that it really happens on during registry detach (on
system exit/shutdown). It is not done through MoveFileEx routine.
This must be something within MS VMM registry library (vmmreg32.dll).

I was totaly wrong in my guess above. (vmmreg32 is probaly just a
wrapper but I don't know what it is for. Maybe some Win95 legacy)
According to this (http://www.sysinternals.com/ntw2k/info/ntdll.shtml),
the RegReplaceKey is just mapped to NtReplaceKey.
The latter is described here:
http://undocumented.ntinternals.net/UserMode/Undocumented Functions/NT Objects/Key/NtReplaceKey.html.

It seems that the NtReplaceKey will internally end up with a kernel call
to ZwSetInformationFile with FileRenameInformation parameter passed (see
DDK).
Great doc about NT/XP registry can be found here:
http://www.i.u-tokyo.ac.jp/ss/lecture/new-documents/Lectures/09-Registry/Registry.pdf

Regards,
Konstantin


I think that I have tried them but values here are only written for
who
knows what reasons at the time when hives are actually mounted. If
you
write
values there they are not used during the boot :-(


Yup.. I agree. I also think these registry values are only written
by the
kernel on boot.
Perhaps they are in registry for backup purpose (so that the backup
software - VSS service - knows about what registry hives must be
backed up and then restored):
http://msdn.microsoft.com/library/d...y_backup_and_restore_operations_under_vss.asp


But I think that there is an API that allow us to replace hive on
use
with
new initialized hive file on next boot. I have never tried this so
I do
not
know what mechanism is used for this, I will do that sometime.

Are you referringto RegReplaceKey API here?
(check out the steps at the end of the article I provided the link
to
above)

--
Regards,
Konstantin

Slobodan,

Did you try [HKLM\SYSTEM\CurrentControlSet\Control\hivelist]?

My understand was that the system (the kernel init part code that
os
loader passes the control to) only creates
\REGISTRY\MACHINE\SYSTEM and \REGISTRY\MACHINE\HARDWARE link
nodes and
always looks for hive files under \systemroot\system32\config
dir. To me it seemed that the path is hardcoded.

However, ntinternals guys say that the Configuration Manager
refers to
the
\hivelist values when it needs to locate the hives'
files.
http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=5195

--
Regards,
KM, BSquare Corp.


Ryan,

I can solve this trough driver, basically it is should be
simple. Just
register for Volume arrival notifications and when each new
volume is
mounted we test whether we can load hive and if we can then we
do
that.
I was curious and hoping to figure out some more universal
solution
that
could tell to kernel what hive file should be loaded and where,
but
existence of such feature is very questionable.

Regards,
Slobodan

Slobodan,

Thanks for the tip on the REG_LINK stuff--I didn't know such
an
undocumented feature even existed.

I will indeed try this and let the group know how it goes. As
for
your
issue of loading the hive as early as possible, that's a
tricky one.
For most applications, of course, this isn't an issue, but for
services, drivers, etc.--beats me. I imagine you'll have to
research
into some more undocumented features... I've always thought
that
the
Run/RunOnce keys were insufficient tools for plugging into the
startup
sequence, and this of course illustrates that again.

The only thing I could think of would be that if you knew what
types
of
drivers were loaded first (if there is even a determinable
order in
which they are loaded), you could write a driver of that type
to
take
care of this for you. Probably you've already thought of
this,
though.

--Ryan

Slobodan Brcin (eMVP) wrote:
Ryan,

Few weeks ago I used undocumented REG_LINK parameter to
create
permanent
links in one of my test applications. I just run a search on
the
net
and
found that someone already used this before me so at least I
won't
need to
write explanation how to use this.
http://www.ntinternals.net/regln/

Don't ask me how to use this tool (you will figure it out)
since I
have not
used it.

General idea that you can do is to create permanent links
during
the
FBA
from certain registry branches that you use to some virtual
paths
for

instance HKLM\MyHive\subkey1

Key HKLM\Software\[App] will always exist and for Win32 reg
functions
it
will not be different from the keys that you have used, but
you
won't
be
able to open it if you don't mount the hive with path that
link
points to.
You can place as many links as you want throughout the
registry
that
will be
redirected to hive that you will manually load (you can load
it
from
your
application or even before of that from service or some start
application).

My idea is to figure out easiest way to automatically (or at
least
first
thigh after FS driver is loaded) load some hive from
different
partitions,
so that even certain drivers and services can pull
information's
from
hive
on unprotected partition.

Please let us know how this work for you.

Regards,
Slobodan


Hello all,

First, thanks to all, especially SB and KM, for a great
newgroup.
Thanks to the quality and depth of the answers in the
group, I've
never
had to post a question before, and I've been using XPe for
nearly
6
months.

So, here's our current scenario. We are planning to use
RAM EWF
with a
product that contains standard consumer-grade PC parts,
meaning
we
have
a hard disk (80GB disk/2GB RAM). Our C: partition, which
contains
the
OS and application, is the only EWF protected partition and
is
about
1GB in size. The D: partition which is about 75GB, is used
for
data.
We don't do any EWF commit operations except during
upgrade/downgrades.
The problem for us is where to store persistent
configuration
information.

Now, I'm aware that what we really SHOULD have done in our
app is
to
store persistent configuration information in a file on the
D:
drive,
but unfortunately our application was not developed with
this in
mind,
and is instead very registry-dependent at this stage.

So, in an attempt to avoid having to perform a costly
re-write of
our
configuration architecture, I had an idea for a shortcut:
has
anybody
using EWF ever tried putting their configuration in a
registry
hive
file on an unprotected partition? The idea is that your
application
can use RegLoadKey to load the hive file on every startup.
This
way
the application's config info is written and stored on the
unprotected
partition without having to perform EWF commit operations,
but
you
still have all the benefits of using the registry.

I haven't actually tried this yet--one thing that's slowing
down
testing is that we will still have to re-locate our config
info
within
the registry since one can only load hives directly under
HKLM or
HKU
(We're currently using HKLM\Software\[App]). But I
wondered if
anybody
has tried this, or if anybody sees any dangers with doing
this?

Note that I'm not suggesting re-location of the existing
registry
hives
(SOFTWARE, SYSTEM, etc.)--only the reg info specific to our
application. I don't want to re-locate SOFTWARE or SYSTEM,
because
these must remain protected by EWF.

Thanks,
Ryan

 

[Slobodan Brcin \(eMVP\)]

Konstantin,

That could shed some light on why it did not get compacted.
http://www.sysinternals.com/ntw2k/freeware/pagedefrag.shtml

I had that tool buf completely forgot to use it :-(
If/when there is next time I will certainly use it to see what happened.

Regards,
Slobodan

Slobodan,

IIRC Last time I checked this I had some strange results with compacting
in
that way.
1. Software hive grow for 100 KB (It was 40+MB large).
2. System hive shrinked 3 times.

so figure this out, I was not able to do so.

The first result is a bit wierd. Certainly defragmantation does not
promise to compact any file but still better results would be
expected.

Well.. You could "test" the fragmentation with PageDefrag from
sysinternals. Basically, you would see how many clusters and
fragments the SOFTWARE hive comsumed.
That could shed some light on why it did not get compacted.

http://www.sysinternals.com/ntw2k/freeware/pagedefrag.shtml


Regards,
Konstantin

Slobodan,

According to description hive will be replaced immediately. I have no
idea how they accomplish to do that since many keys can be open.

I don't know how the ZwSetInformationFile works interneally. What if it
renames a locked file only on reboot?

Also what would be the purpose of this function? You can use it on non
standard hives that you loaded for some reason. But why would you use
it
on regular hives. I mean I have no idea why MS even bothered to create
such function?

Well.. As I said, one purposes would be decreasing system hives'
fragmentation. You write a hive to a new file (RegSaveKey) and it is
getting compacted this way.

Great doc about NT/XP registry can be found here:
Really great doc. Thanks for this doc.

Yup.
Interesting fact.. I happened to find a lot of interesting and publicly
available Windows Internals documents on .jp domain only.

Regards,
Konstantin

Slobodan,

Are you referringto RegReplaceKey API here?
Yes. Do you know how it works when does the actual swap occur?

No, I don't :-(
My guess was that it really happens on during registry detach (on
system exit/shutdown). It is not done through MoveFileEx routine.
This must be something within MS VMM registry library
(vmmreg32.dll).

I was totaly wrong in my guess above. (vmmreg32 is probaly just a
wrapper but I don't know what it is for. Maybe some Win95 legacy)
According to this
(http://www.sysinternals.com/ntw2k/info/ntdll.shtml),
the RegReplaceKey is just mapped to NtReplaceKey.
The latter is described here:
http://undocumented.ntinternals.net/UserMode/Undocumented Functions/NT Objects/Key/NtReplaceKey.html.

It seems that the NtReplaceKey will internally end up with a kernel
call
to ZwSetInformationFile with FileRenameInformation parameter passed
(see
DDK).
Great doc about NT/XP registry can be found here:
http://www.i.u-tokyo.ac.jp/ss/lecture/new-documents/Lectures/09-Registry/Registry.pdf

Regards,
Konstantin


I think that I have tried them but values here are only written
for
who
knows what reasons at the time when hives are actually mounted.
If
you
write
values there they are not used during the boot :-(


Yup.. I agree. I also think these registry values are only
written
by the
kernel on boot.
Perhaps they are in registry for backup purpose (so that the
backup
software - VSS service - knows about what registry hives must be
backed up and then restored):
http://msdn.microsoft.com/library/d...y_backup_and_restore_operations_under_vss.asp


But I think that there is an API that allow us to replace hive
on
use
with
new initialized hive file on next boot. I have never tried this
so
I do
not
know what mechanism is used for this, I will do that sometime.

Are you referringto RegReplaceKey API here?
(check out the steps at the end of the article I provided the
link
to
above)

--
Regards,
Konstantin

Slobodan,

Did you try [HKLM\SYSTEM\CurrentControlSet\Control\hivelist]?

My understand was that the system (the kernel init part code
that
os
loader passes the control to) only creates
\REGISTRY\MACHINE\SYSTEM and \REGISTRY\MACHINE\HARDWARE link
nodes and
always looks for hive files under \systemroot\system32\config
dir. To me it seemed that the path is hardcoded.

However, ntinternals guys say that the Configuration Manager
refers to
the
\hivelist values when it needs to locate the hives'
files.
http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=5195

--
Regards,
KM, BSquare Corp.


Ryan,

I can solve this trough driver, basically it is should be
simple. Just
register for Volume arrival notifications and when each new
volume is
mounted we test whether we can load hive and if we can then
we
do
that.
I was curious and hoping to figure out some more universal
solution
that
could tell to kernel what hive file should be loaded and
where,
but
existence of such feature is very questionable.

Regards,
Slobodan

Slobodan,

Thanks for the tip on the REG_LINK stuff--I didn't know
such
an
undocumented feature even existed.

I will indeed try this and let the group know how it goes.
As
for
your
issue of loading the hive as early as possible, that's a
tricky one.
For most applications, of course, this isn't an issue, but
for
services, drivers, etc.--beats me. I imagine you'll have
to
research
into some more undocumented features... I've always
thought
that
the
Run/RunOnce keys were insufficient tools for plugging into
the
startup
sequence, and this of course illustrates that again.

The only thing I could think of would be that if you knew
what
types
of
drivers were loaded first (if there is even a determinable
order in
which they are loaded), you could write a driver of that
type
to
take
care of this for you. Probably you've already thought of
this,
though.

--Ryan

Slobodan Brcin (eMVP) wrote:
Ryan,

Few weeks ago I used undocumented REG_LINK parameter to
create
permanent
links in one of my test applications. I just run a search
on
the
net
and
found that someone already used this before me so at least
I
won't
need to
write explanation how to use this.
http://www.ntinternals.net/regln/

Don't ask me how to use this tool (you will figure it out)
since I
have not
used it.

General idea that you can do is to create permanent links
during
the
FBA
from certain registry branches that you use to some
virtual
paths
for

instance HKLM\MyHive\subkey1

Key HKLM\Software\[App] will always exist and for Win32
reg
functions
it
will not be different from the keys that you have used,
but
you
won't
be
able to open it if you don't mount the hive with path that
link
points to.
You can place as many links as you want throughout the
registry
that
will be
redirected to hive that you will manually load (you can
load
it
from
your
application or even before of that from service or some
start
application).

My idea is to figure out easiest way to automatically (or
at
least
first
thigh after FS driver is loaded) load some hive from
different
partitions,
so that even certain drivers and services can pull
information's
from
hive
on unprotected partition.

Please let us know how this work for you.

Regards,
Slobodan


Hello all,

First, thanks to all, especially SB and KM, for a great
newgroup.
Thanks to the quality and depth of the answers in the
group, I've
never
had to post a question before, and I've been using XPe
for
nearly
6
months.

So, here's our current scenario. We are planning to use
RAM EWF
with a
product that contains standard consumer-grade PC parts,
meaning
we
have
a hard disk (80GB disk/2GB RAM). Our C: partition,
which
contains
the
OS and application, is the only EWF protected partition
and
is
about
1GB in size. The D: partition which is about 75GB, is
used
for
data.
We don't do any EWF commit operations except during
upgrade/downgrades.
The problem for us is where to store persistent
configuration
information.

Now, I'm aware that what we really SHOULD have done in
our
app is
to
store persistent configuration information in a file on
the
D:
drive,
but unfortunately our application was not developed with
this in
mind,
and is instead very registry-dependent at this stage.

So, in an attempt to avoid having to perform a costly
re-write of
our
configuration architecture, I had an idea for a
shortcut:
has
anybody
using EWF ever tried putting their configuration in a
registry
hive
file on an unprotected partition? The idea is that your
application
can use RegLoadKey to load the hive file on every
startup.
This
way
the application's config info is written and stored on
the
unprotected
partition without having to perform EWF commit
operations,
but
you
still have all the benefits of using the registry.

I haven't actually tried this yet--one thing that's
slowing
down
testing is that we will still have to re-locate our
config
info
within
the registry since one can only load hives directly
under
HKLM or
HKU
(We're currently using HKLM\Software\[App]). But I
wondered if
anybody
has tried this, or if anybody sees any dangers with
doing
this?

Note that I'm not suggesting re-location of the existing
registry
hives
(SOFTWARE, SYSTEM, etc.)--only the reg info specific to
our
application. I don't want to re-locate SOFTWARE or
SYSTEM,
because
these must remain protected by EWF.

Thanks,
Ryan

 

[e7a7b7]

So, some follow-up information for those interested. First of all, it
appears that this is in fact a decent workaround--we are going to go
with it for now. It does come with some caveats, though, due to the
fact that it is difficult to load a hive file early enough to guarantee
its availability to all drivers, services, applications, etc. [this is
what KM and SB's discussion has centered around].

One caveat is that we will have to make adjustments to our application
installation and upgrade process. We use MSI to install/update the
application that resides on the image (more easily distributed and
flexible for testing), and the installation includes a handful of reg
keys. However, when the first install takes place during FBA, the
RegLoadKey operation has not yet taken place because the
application--which runs as shell eventually--has not run yet. In this
case, you say, use "reg load" or something similar in the FBA. OK.
But then it is also possible that during app upgrade if any restarts
are ever required, the MSI may postpone business until after reboot
when the hive is again not yet loaded. It just makes me a little
uneasy to have the installer worrying about loading a key.

Our solution to this will probably be to take the short route and
simply pull all registry keys out of our installer, since they aren't
truly necessary. So, that will work, although we are lucky that there
isn't too much dependence there. If you couldn't pull the reg stuff
out of your installer, then other possible solutions might be to code a
custom action to load the key in the installer, or actually install a
service/driver in the image that loads the hive (I wouldn't mind some
details on how you installed a driver to do this, Slobodan--I'm afraid
its a bit out of my league).

So to summarize, I believe this is a nice workaround if you have an
application that is heavily registry dependent but you want to use EWF.
However, you must be careful to consider your installation/upgrade
process and any other entities that might access your hive such as
other processes, etc.--at least until Slobodan and KM "crack the code"
and discover how to automatically load a hive early enough in the OS
startup sequence.

--Ryan