Windows, Local Machine Registry, and Admin

For reasons beyond the scope of the question, I write to the LOCAL_MACHINE hkey of the registry for serial number types of things. On Vista and upward, these things go into a symlink-like thing looking like HKEY_LOCAL_MACHINE/Software/Wow6432Node/[companyname].

With my test machines, I have no problem creating these keys and writing data. But on many clients machines, they have problems writing here, and I’ve found this is “solved” by having administrator rights when running my program.

However, many clients say that they ARE running as admin - mostly people who have no regard for security and just use the computers as the only person using them. I don’t doubt that they are the administrator and have admin rights. But they can’t write to these areas.

The solution for them is to right-click on the shortcut or application and select “Run as Administrator” (or they can adjust this in the Properties for the shortcut/app). Then it works fine.

Why is this? Why does one have to run a program as admin when they ARE admin?

With UAC turned on even administrators have to run their apps with the runas option, they just don’t have to provide an administrator username/password. The way around this issue is to use a helper app (console is fine). Look at this to see how to launch the helper app requesting elevated UAC.

I looked at that a couple days ago (and perhaps what in my mind made me ask), but isn’t this kind of funky? I mean in this sense - you actually have two .exe’s and one is this launcher (that serves as what the user sees as THE APP) firing up the main .exe that you actually don’t want people to start up. Or am I mistaken?

Or perhaps the code snippet needs to be more complete - is this in your REAL app, and it starts another instance of it up while quitting the first instance? (You’d have to support some way of know that that instance had elevated privledges, whcih I didn’t see in your snippet). I would have tried that snippet but it confused me about the context of it (I’m quite a literalist).

BTW, this is similar to how to start up your app in Mac with elevated privileges.

Yes, Xojo should provide a mechanism for Windows builds to automatically request elevated privileges if required.[quote=30858:@Garth Hjelte]you actually have two .exe’s[/quote]
Yes there are two exe’s, but you don’t necessary need elevated privileges for all operations. I use the code snippet to launch a console app that associates file types for instance, this is a small part of the app that doesn’t require being run often.[quote=30858:@Garth Hjelte]Or perhaps the code snippet needs to be more complete - is this in your REAL app, and it starts another instance of it up while quitting the first instance?[/quote]
As I said it doesn’t need to be the same app. And yes it is in the Xojo code.

This is easy to test for e.g. Try creating a file in the sharedapplicationdata folder and catch the exception. An exception means non-elevated privileges. Or catch the registry exception.

I’m not sure this will work for my purposes. The only reason I want elevated privileges is for the user to authorize my program in the first place. My app actually doesn’t need any elevated privilege other than that. So I’d have to ask the user to run ANOTHER .exe to authorize my program. What I’m trying to do is avoid this.

Could I perhaps put this in my App.Open() event and have it launch the same .exe while quitting the first instance?

Also, isn’t a weak point in your snippet the fact that rarely can you write into the “Program Files” folder. Most/all Windows apps should run within Program Files, and normally you can’t write into it, but you are. Shouldn’t you have the snippet write the script into SpecialFolder.ApplicationData and run it from there?

Actually the snippet creates a vbs file in the temp folder then executes wscript with the file path of the script as it’s parameter.

Also the user does not have to “run” any extra exe. The exe is launched by the script with elevated privileges requested. If the user’s windows has UAC turned on then they will be either prompted to enter an administrator user/password or press the OK button to allow the program to make changes.

So I would check if authorized in the event, if not execute the method to launch the authorization exe then either wait for authorization to complete (with a timer) or show a dialog stating that the app will need to be restarted after authorization.

I’ve put a demo together here.


The new security paradigm on Windows is complex and for many developers quite questionable (including me). The Program Files is simple a closed area. No possibilities at all to write to it in code.

If You want to hide files from the users the workaround is to use the .AppData folder under the User folder. Per default this folder is hidden for the users. upto Windows 7. In Windows 8 it’s possible to switch between to show and hide it.

The easiest solution is to use an installation tool. No need to buy one as it exist some nice tools for free like NvN Installer: