HKEY_LOCAL_MACHINE SOFTWARE

[Daniel Coelho]

Hi,

I'm trying to create HKEY_LOCAL_MACHINE\SOFTWARE\NEWKEY but REGEDIT.exe doesn't show the new key on that path, instead, it apears on

HKEY_USERS\S-1-5-21-3683771369-3266819176-3176474894-2642\Software\Classes\VirtualStore\MACHINE\SOFTWARE\NEWKEY.

Reading, writing and deleting works fine, but not on the path I'm specifying. Everything is done on another path.

RegWriteString (REGKEY_HKLM, "SOFTWARE\\NEWKEY", "KEY", "1234");

Why is this behavior happening?

Thanks for your time.

Regards.

[RobertoBozzolo]

As far as I remember, standard users have no access on LOCAL_MACHINE registry key so you may be running into access and privilege problems. Relevant questions in this respect are: which type of user are you logged with? Can you test with an administrative user if you are logged with a standard or restricted user? Also, which OS are you running on? And does RegWriteString report any error?

[Ian.W]

This looks like an issue related to the more rigorous security model in Vista - in particular the "Virtual Store" part.

Here is a great NI page that describes what is going on with virtualization.

--Ian

[Daniel Coelho]

I belong to the administrators group;

I logged in as the Administrator and it worked fine;

I'm using Vista;

And, finally, RegWrite doesn't report any errors.

The data is being stored on ..\VirtualStore\MACHINE\Software...

Its a Vista user privilege issue....

[Daniel Coelho]

Ian,

is it safe to say that, ignoring this virtualization issue, if I try to change the registry the data will always be changed correctly independent from the users privileges?

I don't mind if Vista uses a VirtualStore for safety, as long as I can acess my data as an Administrator or as a Standard user.

[Ian.W]

My understanding is that you will not be able to get cross-user availability/writeability of the data you try to write to HKLM, but I can't claim to be an expert on this. 

Note also that being an admin in Vista does not mean you are always running with full priviliges - UAC provides an extra level of protection against certain actions. I think that right clicking an app and choosing "Run as Adminstrator" or diabling UAC will enable your app to have greater rights, but not all. More info here

My take on this issue is that there is a message here:

HKLM is not a place where any user / app should have write privileges due to the security implications. Sure it is convenient, but it is part of the mindset that Microsoft and developers have to leave behind in the name of security.  Have you considered other places where you can store this information? For the record, if per user is okay, there is HLCU, but also C:\Users\xxx\AppData\  (see this thread).  In your case perhaps C:\Users\Public\ would be better. There you will see NI samples placed in recent versions of CVI and you could create C:\Users\Public\YourCo\YourApp\Data.

Hope this helps. Good luck!

[Daniel Coelho]

Thank your for your reply.

Keeping in mind the Registry, is there any other key besides the LOCAL_MACHINE and CURRENT_USER that maintains the information available for all programs and users?

[Ian.W]

Sorry, Daniel, but I do not know about such a location in the registry.

Apologies for steering in a different direction, but to correct my previous suggestion, a better way to set up this location would be to use the "Common Application Data" location as returned by the Windows API function SHGetFolderPath() . Here is the description of that location from:

CSIDL_COMMON_APPDATA (FOLDERID_ProgramData)

Version 5.0. The file system directory that contains application data for all users. A typical path is C:\Documents and Settings\All Users\Application Data. This folder is used for application data that is not user specific. For example, an application can store a spell-check dictionary, a database of clip art, or a log file in the CSIDL_COMMON_APPDATA folder. This information will not roam and is available to anyone using the computer.

(For compatibility for only Vista and forward, see SHGetKnownFolderPath(), but the above works for XP and Vista.)

--Ian

[Daniel Coelho · Accepted solution]

Thank you for your sugestions.

Currently my programs are aimed for XP so no problems should ocurr, but in the future I have your Windows API function SHGetFolderPath()  sugestion if something doesn't run as aspected.

I wanted to use the Registry for the simple reason that I think that shared folders data may be changed/deleted by any user. Of course that the Registry has the same problem, but I don't think that many "nomal" users dare to even open it. ( I think... )

Thank you for all your help.

Regards.