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.
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.
My application updates some registry fields related to licensing under HKLM. This is for accessing the information for all users in the system. This makes us to make our application run as administrator. Is there any other location in registry where I can keep information which can be accessed by all users?
Registry HKLM and folder %ALLUSERSPROFILE% are accessible to all users, but meant for writing to at install time (as admin).
Registry HKCU and folder %APPDATA% are accessible to current user and meant for writing to at any time.
Why are you modifying licensing info (shared by all users) during run and not just during install?
You could place as an (e.g.) XML document in the file system under a shared folder instead of the Registry.
E.g. System.Environment.SpecialFolder.CommonDocuments or CommonApplicationData.
No there is not. If you have to make a modification that will affect/be visible to all users, you have to deal with UAC or elevate your application on startup. This is part of the design of UAC. If, however, you were to write to a file you could grant all users access to that file without UAC interference.
If, however, you are only reading the registry, you can do this without elevating your security rights. Therefore, if you write once to the registry and then just read it later, you can do so when only elevating your privileges once.
Here is an article on playing nice with UAC:
http://msdn.microsoft.com/en-us/magazine/cc163486.aspx
I'd make your installer precreate the registry entries (it runs as admin typically), and open up their permissions using GetSecurityInfo and SetSecurityInfo. Then your app can write to them without any special perms.
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.
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).