Strange Registry Virtualization issue

  • Thread starter Thread starter Emmanuel Stapf [ES]
  • Start date Start date
E

Emmanuel Stapf [ES]

Hi,

During the installation of my application which requires elevated
privileges, I install some registry keys under HKLM. When I first launch
my application, I read data from HKLM.

However on some vista machine it does not work. Using ProcessMonitor, I
saw that instead of trying to read HKLM he actually tries to read from
the virtualized HKLM, i.e. HKCU\Software\Classes\VirtualStore\MACHINE.

Why does it do that? I've verified that I'm only opening the key with
read access, not write access?

Thanks,
Manu

PS: the vista machines are all running with UAC turned on.
 
Emmanuel Stapf said:
Hi,

During the installation of my application which requires elevated
privileges, I install some registry keys under HKLM. When I first launch
my application, I read data from HKLM.

However on some vista machine it does not work. Using ProcessMonitor, I
saw that instead of trying to read HKLM he actually tries to read from the
virtualized HKLM, i.e. HKCU\Software\Classes\VirtualStore\MACHINE.

Why does it do that?
Click to expand...

Vista provides the virtualization for programs not written for Vista.

http://technet.microsoft.com/en-us/magazine/cc138019.aspx
 
FromTheRafters said:
Vista provides the virtualization for programs not written for Vista.
http://technet.microsoft.com/en-us/magazine/cc138019.aspx
Click to expand...

This is not exactly what I was referring too. My problem is not whether
virtualization is enabled or not. It is that the documentation says it
will merge the content of the virtual store with the one in HKLM and it
is clearly not doing that since my application cannot see the keys that
are in HKLM.

Regards,
Manu
 
Emmanuel Stapf said:
This is not exactly what I was referring too. My problem is not whether
virtualization is enabled or not. It is that the documentation says it
will merge the content of the virtual store with the one in HKLM and it is
clearly not doing that since my application cannot see the keys that are
in HKLM.
Click to expand...

My understanding is that it reads both and presents a
merged view to the application with the virtualized keys
taking precedence over the ones in HKLM. If you want
to make HKLM take precedence - remove the keys from
the virtualized store and it should use the HKLM ones.

In other words, make the virtual store keys in question
non-persistent and the HKLM will be used each time
because no virtualized version will be found.

http://msdn.microsoft.com/en-us/library/bb530198.aspx
 
FromTheRafters said:
My understanding is that it reads both and presents a
merged view to the application with the virtualized keys
taking precedence over the ones in HKLM. If you want
to make HKLM take precedence - remove the keys from
the virtualized store and it should use the HKLM ones.
Click to expand...

The issue is that there are no keys in the virtualized store, the keys
are only in the HKLM one. So I don't understand why he can't read the
one from HKLM.
In other words, make the virtual store keys in question
non-persistent and the HKLM will be used each time
because no virtualized version will be found.
Click to expand...

I agree this is what should be happening, but it is not. Any hint on how
to debug this so that we can find the root cause of this behavior?

Thanks,
Manu
 
FromTheRafters said:
My understanding is that it reads both and presents a
merged view to the application with the virtualized keys
taking precedence over the ones in HKLM. If you want
to make HKLM take precedence - remove the keys from
the virtualized store and it should use the HKLM ones.
Click to expand...

The issue is that there are no keys in the virtualized store, the keys
are only in the HKLM one. So I don't understand why he can't read the
one from HKLM.
In other words, make the virtual store keys in question
non-persistent and the HKLM will be used each time
because no virtualized version will be found.
Click to expand...

I agree this is what should be happening, but it is not. Any hint on how
to debug this so that we can find the root cause of this behavior?

Thanks,
Manu
 
Emmanuel Stapf said:
The issue is that there are no keys in the virtualized store, the keys are
only in the HKLM one. So I don't understand why he can't read the one from
HKLM.


I agree this is what should be happening, but it is not. Any hint on how
to debug this so that we can find the root cause of this behavior?
Click to expand...

Sorry, no. You may want to contact Microsoft support
for this issue. This function is implemented in the kernel.
They may suggest that you rewrite the program so that
it doesn't have to use virtualization at all - which is the
best path anyway.
 
Back
Top