CODEWITHSUNDEEP
windowsregistryinno-setup
Bruno Brs
Bruno Brs

Reputation: 693

Reading keys from a virtualized Windows Registry

My older application writes to registry (which ends up being virtualized), now I want the installer to actually read this data, when I tried directly from LOCAL_MACHINE (I didn't know the key was virtualized) I got error, then when I decided to try reading directly from the virtualized key, I got error as well.

Windows 2008 server 64 bits, and my application is 32bits, UAC is enabled.

So is it actually possible to read from a virtualized windows registry directly?

Now I need to read this data, BUT.

This doesn't work.

  if regkeyexists(HKEY_LOCAL_MACHINE, 'SOFTWARE\Wow6432Node\Company\App') then
  begin
    msgBox('Exists', mbinformation, mb_ok);
  end else begin
    msgBox('Doesnt exists', mbinformation, mb_ok);
  end;

And this doesn't work as well.

  if regkeyexists(HKEY_CURRENT_USER, 'Software\Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node\Company\App') then
  begin
    msgBox('Exists', mbinformation, mb_ok);
  end else begin
    msgBox('Doesnt exists', mbinformation, mb_ok);
  end;

It says the Key doesn't exist

So now I can't actually read the data? I've checked and the path is OK.

Upvotes: 4

Views: 715

Answers (2)

Bruno Brs
Bruno Brs

Reputation: 693

I could resolve my problem using some workaround, so just to let others know in case someone else needs it.

What happened was that even being an administrator user, in Windows 2008 server with UAC enabled, my application (which was not run as administrator) used to record its registry in the virtualized key, while the installation in Inno Setup could write to the true LOCAL_MACHINE, making the application's registry invisible to my application and vice-versa.

As i'm releasing a new version in which i have to make sure the app registries will be in LOCAL_MACHINE, i ran a separated application using 'ShellExecAsOriginalUser' to actually export the virtualized keys to a file, and then import back to LOCAL_MACHINE through Inno Setup.

I'm thankful to all the answeres here!

Upvotes: 2

Miral
Miral

Reputation: 13075

Virtualised keys are per-user data; this means that even if you were able to successfully read one from the installer, you would only be reading the settings of one user, not all users (and as you've found, there's a good chance you won't even be able to read that one).

Normally you can just ignore virtualisation until the time comes to upgrade your application and mark it with a compatibility manifest, at which point it loses virtualisation and you have to handle the registry correctly. So I'm assuming that this is the case you're finding yourself in.

In this case, the correct resolution is not in the installer, it's in your application. Your installer should either not write to the registry at all or should store read-only defaults in HKLM. On startup, your application should first try to read settings from locations in this order (only moving down the list if it cannot find the value there):

  1. HKCU\Software\YourCompany\YourApp\SettingName
  2. the VirtualStore location of the HKLM key you were mistakenly using previously
  3. the HKLM key possibly written by the installer
  4. some internal default value

When your application saves settings, it must write only #1, never anywhere else. Also note that you must follow this list for each individual setting -- it's possible that some settings are in HKCU, some are virtualised, and some are only in HKLM.

Upvotes: 3

Related Questions