I'm using installshield 2010 express edition to make setup file of win32 application.
I have some problem to register some registry keys.
I configured the installshield project(.ise) to register two registry entry like below.
[HKCU\Software\ProgName\SomeKeys]
[HKLM\Software\ProgName\SomeKeys]
When I install this setup on a x64 machine, the HK key writes to the Wow6432Node [HKLM\Software\Wow6432Node\ProgName\SomeKeys]. It's just what i want.
BUT HKCU does not write anything to the Wow6432Node.
It write on [HKCU\Software\ProgName\SomeKeys] not [HKCU\Software\Wow6432Node\ProgName\SomeKeys].
Why this problem occurred.
Please give me any advices. Thank you
This is working correctly, by design on Microsoft's part. Please read the MSDN documentation:
Registry Redirector
Redirected keys are mapped to physical locations under Wow6432Node.
Registry Keys Affected by WOW64
Under WOW64, certain registry keys are redirected. When a 32-bit or 64-bit application makes a registry call for a redirected key, the registry redirector intercepts the call and maps it to the key's corresponding physical registry location. For more information, see Registry Redirector.
Other registry keys are shared by both 32-bit and 64-bit applications on 64-bit Windows. 32-bit registry calls to shared keys are not redirected. Instead, one physical copy of the key is mapped into each logical view of the registry.
User-defined subkeys underneath HKCU\Software are shared, so there is no Wow6432Node subkey for them.
User-defined keys underneath HKLM\Software are redirected, so there is a Wow6432Node subkey for them.
Related
I have a 32-bit program that is trying to access a key stored in HKLM\Software\Microsoft\VisualStudio in a Windows 64-bit setup running Windows 8.1.
Usually it works just fine and it will actually read that key from the Software\Wow6432Node.
However I have one machine (which doesn't seem that different from others) for which the read fails. When I look at the registry accesses with Process Monitor it shows that it is trying to read it from the VirtualStore and there it is not present, thus the failure.
Any reason why Windows is not presenting the merged view to my application as it does on other installs?
Thanks,
Manu
The virtual store is a compatibility mechanism that was introduced with UAC, and is not directly related to WOW64. When a program that does not declare itself to be compatible with Windows Vista attempts to create a key or file but does not have access to do so, Windows redirects the write into the virtual store. From that point onwards, attempts to open that key or file will be automatically redirected to the virtual store.
To avoid being redirected to a virtual store key or file that another application may have created, use a manifest to declare that your application is compatible with Windows Vista.
My 32-bit application is running on 64-bit Windows 7. I am trying to access the registry HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall. I can see in regedit that I have several subkeys below the Uninstall key in the default 64-bit registry view (Dropbox creates a key in that location, as well as Google Chrome). However, there is really no Uninstall key in the 32-bit registry view. Actually, in regedit there is only a single Active Setup key below HKEY_CURRENT_USER\Software\Wow6432Node\Microsoft. There is not even a Windows subkey below Microsoft.
However, when my 32-bit application tries to access the 32-bit registry view of HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall, I get the keys from the 64-bit view. Why is that?
Even the flag KEY_WOW64_32KEY won't help here. Our code needs to know whether the results are from the 32-bit view or the 64-bit view.
Our code also accesses both the 32-bit and 64-bit views of the key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall and I do not see this issue there. The difference is that the 32-bit view of HKLM has an Uninstall key and the 32-bit view of HKCU does not.
I know the registry redirection of WoW64, but this seems different. I could not really find any useful information on MSDN. Could someone shed some light on this?
This is documented, but only indirectly. This MSDN page lists HKLM\Software as redirected and HKCU\Software as shared.
Note: in this context redirected means that there are two registry views, one for 32-bit and one for 64-bit (in other words: the Wow6432Node subkey exists and is used), whereas shared means that there is only one view for 32-bit and 64-bit processes.
And yes, it is interesting that HKEY_CURRENT_USER\Software\Wow6432Node exists. As the OP mentioned there is only a subkey Microsoft\Active Setup\Installed Components below that - which is probably there because the autors of the Active Setup code at Microsoft incorrectly used the Wow6432Node as subkey path in their registry API calls instead of specifying the desired view via the samDesired parameter of RegOpenKeyEx.
I am closing this question based on the comment I got so far and there is no official confirmation on this. So at this point basically there is really no 32 bit registry for KKEY_CURRENT_USER at 64 bit machine.
If I install an application and then go into Add/Remove Programs in Windows and see that there is not a Repair button when I click on Support Information, does this indicate that the installation is not MSI based?
Will all MSI installations have a Repair button in this location?
No. The ARPNOREPAIR property can be used to remove the button in MSI based installations.
Short answer: Go look at the registry at HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall (there may be an equivalent WOW64 registry key on 64-bit machines)
An application's presence in the Add/Remove Programs ("ARP") dialog can come from several sources. Most notably of course is the MSI database.
The legacy approach to inserting an application into the ARP was for the custom installer to copy the files and settings over and the register it's uninstall exe" with the registry at this registry key. (Anyone remember "InstallShield"?)
If memory serves me correct (from back in the pre-MSI days of windows 95), the only subkeys of HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall that actually needed to exist was the "DisplayName" and "UninstallString". If these two registry values existed, then the app was in the ARP with an "uninstall" button.
More details here: http://support.microsoft.com/kb/314481
Problem: I need to create registry keys in my simple application (MS VC++ project), but this simple application could work in different modes:
if I launch it with WinXP, it's started as a service
if I launch it with Vista or Win7, it's started as a console window
On WinXP, I could install service and also I could write to HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Services\\ section. It's ok.
But, when I'm trying to launch my application on Vista/Win7, and it trying to save some data to HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Services\\ registry section, I get the error message, that I can't do that.
Question: Could anyone tell me, where I could write (create) some data (keys) in registry on all of this systems WinXP, Vista, Seven.
PS. HKEY_CURRENT_USER section I'm unable to use, because, services are working on it's own sessions, so data stored by user in HKEY_CURRENT_USER will not be accessible to service.
PSS. I'm unable to give the administrator rights to the application for save some data. I need another "folder" in registry to write there "for free".
Code examples:
REGKEY service(HKEY_LOCAL_MACHINE, TEXT("System\\CurrentControlSet\\Services"), KEY_READ, REGKEY::open);
REGKEY app(service, TEXT("my_application"), REGKEY::create);
// here comes error
UAC prevents access to HKLM on Visa/7/2008, so without elevation to administrative privileges your application cannot access keys contained within it.
If you can't use HKCU then your best bet is to store the data on disk in a format of your choice, in a directory under CommonApplicationData created by your installer with the appropriate permissions.
I want to create a registry key in local machine hive in windows 7. I used the following code in order to do so:
RegistryKey regKey = Registry.LocalMachine.CreateSubKey(#"Software\Test", RegistryKeyPermissionCheck.ReadWriteSubTree);
the code runs fine without any error. but when I looked at my registy using regedit.exe I don't see the key that i've just created. can anyone help me please.
regards
Are you on a 64 bit machine?
If you are on a 64 bit machine, check your project Build settings (Project Properties > Build tab) and check the Platform target.
If the Platform target is set to x86, and you are on a 64 bit machine the key will be created under the 'Wow6432Node'
In regedit.exe look in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node and you should see your key there.
Change the Platform target to Any CPU and it will create the key in HKEY_LOCAL_MACHINE\SOFTWARE
In all likelihood your application is running without a manifest and is writing to the virtualized copy of HKLM. To test my theory, right click your exe and choose Run As Administrator. If it then writes to the correct area, this is what is happening.
If this is the issue, either change your mind about writing to HKLM (users don't like UAC prompts) or put a manifest on the exe that has requireAdministrator so that it will always request elevation and work properly.
What is the length of your key name? There is a known bug in regedit that wont let you see keys with names longer than 256 characters.