Is it possible to write to the HKLM registry branch in Win 7 from an application?
My existing code is not able to write to the HKLM registry branch on Win 7 machines, while it is able to do this on XP machines.
How do you allow an application read/write access to HKLM on Win 7, or should all applications now just use HKCU instead? What if I need to store settings on a machine basis rather than a user basis?
You need to decide whether you are writing an administrative app, that deliberately changes settings for all users (by writing to HKLM) or an ordinary app, that does not. If you really are writing an administrative app then put a manifest on it that has a requestedExecutionLevel of requireAdministrator. The user will get a UAC prompt every time they run the app, but your writes to HKLM will succeed. Alternatively, change the app to write to HKCU or some other per-user store.
(No idea how to add a manifest? Tell me what language/IDE you're using and I'll try to help.)
Relying on virtualization is a bad idea. It was implemented to let unmanifested applications at least sorta kinda work. It will go away some day and is not that great while it's here.
Win 7 uses Registry Virtualization
Read the article and look into (HKEY_USERS\<User SID>_Classes\VirtualStore\Machine\Software).
Related
I have created a small vb6 application which edits the registry in HKLM hive. It makes use of function RegSetValueEx. But when run the exe file in windows 7 and windows 8 pc it does not edit the registry even if run it in administrator user.
In windows XP it works fine.If i run same application as "run as administrator"(by right clicking exe and then run as) in windows 7 and 8 then it works properly.I think the windows 7 and 8 id designed to work like this only. But is there any method i can edit it without running as administrator? Or is there any code in vb6 which does the same.
Here is my small code
Important:
When checking the code create exe and then run the exe and click on button(HKEY_LOCAL_MACHINE\SOFTWARE\Demo registry gets added in wow32 node because vb6 is a 32 bit appliaction).Running the code directly by opening code allows the registry to change.But creating the exe and then running it gives the problem which is the real time scenario in any application.
Microsoft has been warning developers since Windows 2000 that access to the HKLM branch of the registry should not be performed as normal user, as it will sooner or later be restricted to administrators. They also said you should not write to Program Files.
They didn't enforce that rule until Windows Vista, so nobody felt the need to change anything.
Now you have it: don't write to HKLM as normal user - it doesn't work. Don't write your settings to Program Files. It doesn't work.
Application run by the normal user may write their data to user folders and user hives in the registry, nowhere else.
If your application's sole purpose is to write to that value in the HKLM hive then you will need to add a "requiresAdministrator` manifest to the executable, causing Windows to prompt the user for admin access every time it's run.
If this is a small part of a larger project, then you should use COM elevation or just run a small stub executable with the manifest above, allowing windows to only prompt when it's required.
If your application doesn't require admin access at all then you should stop it trying to write to admin restricted locations, and instead use the user's own HKCU hive.
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.
In XP, we used to keep configuration parameters of our application in application specific registry keys under HKLM\Software. The application needs to read and write these values. With the new security model introduced in Vista and Windows 7, these applications won’t work in Vista and Windows 7, unless they are Run “As Administrator”. If the applications are run as normal users, registry writes from these applications will fail in Window Vista and Windows 7.
What is the recommended way to keep application specific data in registry in Windows Vista & Windows 7, when the application is required to write to registry during the lifetime of the application?.
HKLM is for values that affect all users on the computer. Use a key under HKCU for values that affect only the current user. Your application does not need to be elevated to write under HKCU. If only one person uses each machine (it's on their desk or it's their laptop) this distinction matters very little to you, and lets the app run without elevation.
I'm working on an installer for our application. The installer makes some changes to the HKEY_CURRENT_USER\Software\Company\AppName registry key, which the application then looks for the first time it runs. The application then does different things based on the registry keys it finds.
This works great, until you try to install the application as a user account (i.e. non-administrator) on windows 7 (and maybe Vista, I haven't tested that yet).
When the user tries to install the application, Windows elevates to the administrator account's credentials. This means that any changes to HKCU in the registry are made to the administrator's registry, not the launching user's registry. Thus, the keys are not visible to the application when it launches for the first time under the user's account.
We can't be the only people whose installer needs to communicate with the app it installs. Is there no way to reliably use the registry to do this?
We can't rely on the user launching the app after he installs it, so passing the information as a command-line parameter isn't a viable solution. The only way I can see to do it is to have the installer invoke a utility as the original user, which gets or sets the registry key itself; this seems to be a bit of a silly hoop to have to jump through.
Edit: The application needs to delete the keys after it's used them, so I can't just put them in HKEY_LOCAL_MACHINE.
There are 2 recommended approaches for what you want:
Use a per-user installation which
doesn't require Administrator
privileges. You will be able to use
HKEY_CURRENT_USER, but your product
is not installed for all users.
Use a per-machine installation which requires Administrator privileges. In this case you need to redesign your application so it reads its settings from a configuration file. HKEY_CURRENT_USER should be used only when saving user-specific settings, not for global application settings.
Basically, if your application is per-machine, it should use HKEY_LOCAL_MACHINE or a configuration file. If it's per-user, you can use HKEY_CURRENT_USER. Any other combination has limitations and will not work the way you need.
If you need your application's information to be available to all users, use the HKEY_LOCAL_MACHINE hive.
EDIT - 2 alternatives:
Change the security of your registry
keys to allow users to edit/delete
them,
Use the ProgramData directory (instead of the registry) to store
the data.
I have an application that is installed per-machine (since it uses a service). One part of the application is a system tray application that allows the logged-in user to monitor the service operations. I'm trying to figure out how to best install this monitor application.
Each individual user should be allowed to configure whether or not he/she wants to run the monitor application at login. This means that the HKLM/Software/Microsoft/Windows/Run key is out - this only allows configuration for all users.
There is of course the corresponding HKCU-key, however if one simply installs to this key, it will only be for the user that installs the application.
The SO question Launch app on startup for all users, but also allow per-user setting (Windows) refers to the technique of simply having a user-configurable regkey or similar that is checked by the startup-application on to determine whether or not to run. But this means that the application has to start in order to check the value and I would prefer not to bloat the user's startup if I can avoid it. The benefit of this approach is that it is possible to remove the regkey on uninstall.
Another way to accomplish the installation part may be to use Active Setup to create the HKCU regkey on login, this is however undocumented and it seems to me that there is no easy way to uninstall the regkey if the application is uninstalled? I would assume that leaving registry values under the Run key for HKCU might create problems for users after uninstallation.
Is there a standard way to handle per-user startup applications using Windows Installer? Especially with regard to how to uninstall these later on?
Looks to me like you're close to answering your own question. I think you may just need to divide up the responsibility of configures whether to auto-run for each user... er, let me explain:
You can use either a self-healing component of HKCU Registry keys or ActiveSetup to ensure that every user gets the configuration.
If you use an HKCU Registry key, your MSI installer needs to have a component with it's "key file" as an HKCU entry--so thus the first time a new user launches the program, Windows Installer will do a self-heal to write those entries. One of those entries would be your HKCU/Software/Microsoft/Windows/Run value, but not the key value, because you want the users to be able to remove it and not have it come back every time they run the program! You would then want your program to have an option to remove the auto-run value.
If you use ActiveSetup (which I would recommend because it's simple and it "just works"), then you might find it easiest to make a simple app (or VBScript or such) which prompts the user if they want to have the monitor program auto-run. So your ActiveSetup would launch the prompt program/script, and the prompt program would create the HKCU/Software/Microsoft/Windows/Run value or, better yet, just a shortcut in the user's Start Menu\Programs\Startup directory.
A bit lowtech possibly, but can't you just add a shortcut to the user's startup folder (Start menu/Programs/Startup)?
I guess you would use the HKLM/Software/Microsoft/Windows/Run in this case. The feature to run the monitor application at startup or not really belongs to the monitor application and not the installer. At log-on the monitor application can detect if this is the first time that the monitor application has been run and present the user with an option to always run the monitor application on start up or not.