Registry Edit Permissions in Windows 7 and after

[MHawk]

I have an issue where I need to manipulate the latency setting of a number of COM ports in windows to a value other than the default. I can successfully read the value; however when I try to write the value I get Error -601. To check that the error is related to permissions, I first changed the registry to KEY_READ. This successfully returned the current setting of the device. Secondly, I closed LabVIEW and restarted with the "Run as Administrator" option. This allowed me to read and write the registry with my existing code.

While a non-administrator user can manipulate this value from a deeply buried menu, I would really like to be able to have LabVIEW change this value automatically.

My first choice is to have LabVIEW make these changes silently at run time as a 'normal' user. Is there an option I am missing or different permission setup where this could happen?

My second choice would be to have LabVIEW trigger the user to allow the registry change. I did a quick search and did not find any posts that related to getting Window's User Access Control dialog to allow elevated permissions temporarily.

My last choice would be to have the built executable always prompt the user to "Run as Administrator".

Any ideas I'm missing?

Thanks for your thoughts.

[crossrulz]

Microsoft is locking down the registry.  Starting with Windows 7, only an administrator can write to the registry.  Microsoft even tells people to not use the registry.  So stop using it.

What I do is use a configuration file that sits next to the executable.  NI supplies a nice API for it.

[MHawk]

I completely agree that using the registry needs to come to and end.

I very specifically need to change the default installation of the FTDI virtual COM port from 16 ms to a smaller value. Unfortunately, the default file and as installed values exist in "protected" areas of the OS such that modifications require UAC permissions. FTDI Latency Value

I absolutely store my program specific configurations in *.ini files. In this instance, My hand is forced, as the value is a property of the FTDI driver and failing to set this parameter properly causes erratic behavior.

[Hooovahh]

What about on install of your application (which may need administrator privilages) modify the registry?  I do this with InnoSetup which is an installer that you can bundle other installers into.  So during my InnoSetup installer it setups the registry and writes things that needs to be there, then installs the NI installers silently, makes shortcuts, copies files, etc.

It sucks that you need to be an administrator to install the software but that is probably what Microsoft wants anyway.

Or just turn UAC all the way down and I think non-admin users can edit the registry too.

[rolfk]

Actually when you create an installer in LabVIEW you have the option to add registry settings that the installer should apply. It's not a powerful and versatile as you could do with InnoSetup, buf for simple cases it is enough. And since the setup.exe is recognized by Windows as an application that likely needs extra priviliges it will usually invoke an UAC dialog anyways. Otherwise you can force it by putting an according manifest file besides it.

The only way to avoid an error on modifying the registry in most places except the HKLM_CURRENT_USER registry hive, is to either start your process elevated (causing always an UAC dialog of some sort, with or without the need to enter the admin password) or to install a system service that runs under the local system account and send it a command to do the necessary change on your behalve.

[MHawk]

I like the possibilities that the installer offers.

There are two device types which need this special treatment. One is a suite of sensors which is rarely added or subtracted from the pool of possible test instruments. These could be set or installed during the installation with the correct values. The other item is a steady stream of newly manufactured devices which will have ever changing keys. If I modify the default driver values on the computer during the initial installation, then the new devices should be getting the correct parameters by default.

I suppose there is an option where I create two programs. One which runs in user space, and calls a second executable to run as administrator when settings need to be updated.

[rolfk]

Yes you could do that by adding the necessary manifest to that app. But this will of course cause an UAC prompt everytime you execute that, otherwise the whole idea of UAC protection would be just hot air.

[Hooovahh]

---

@MHawk wrote:

I suppose there is an option where I create two programs. One which runs in user space, and calls a second executable to run as administrator when settings need to be updated.

---

It can be the same application, it will just generate a permission error if you aren't an admin (or have UAC).  This could be an opportunity to prompt the user telling them about needing to run the software as an admin.  You could even read the key before and if it is set properly to do nothing.

[MHawk]

So I'm still working out a way to start and/or restart the program as an administrator.  Is there a way to do this programmatically or must I be forced to rely on the user to know what "run as administrator" means?

[rolfk · Accepted solution]

You place a file <your appname>.manifest alongside the executable file with contents as pointed out in the LabVIEW help.

http://zone.ni.com/reference/en-XX/help/371361N-01/lvconcepts/uac_app_manifests_and_dgsn/

Respectively LabVIEW seems to already embed a manifest file in the built executable. So you have to retrieve it, change it and put it back into the executable.