The Joel on Software Discussion Group (CLOSED)

The rights of the users on the network domain are reflected in the HKEY_CURRENT_USER registry hive if they are user-specific, and in HKEY_LOCAL_MACHINE if they are to be applied to all the users. This applies for all the users in a network domain, whether they are Administrator group users, Restricted Users, Standard Users or Power Users.

However, for restricted users that are created on the local machine, and not on a network domain, the above mentioned registry hives do not apply. I've seen this with one of my applications recently. I want to know what registry hive stores information pertaining to such users.

I don't know, but my feeling is that most of the time one should be using higher level API calls rather than directly accessing the registry. The high level calls would then automatically get/set the information from the right place in the registry?

I fully agree with you, Ian. I *am* infact using the functions from the framework, and not P/Invoking anything.


I have left ambiguity in my question. Here's the scenario.

I've seen that my application runs for all users of the network domain, of whatever rank they may be.

My application also runs smoothly for users of the local machine belonging to the Administrators group. However, if a user of the local machine who is a member of the Standard Users group or of the Restricted Users group logs in, the application does not launch.

The application I am referring to is an Add-in for a Microsoft Office application. It is developed using VB.NET. In order to have it registered for auto-launching it when MS Office starts, I added entries in the following registry keys:

(1) If the user selects Install Just For Me while installing the add-in, the entries are made in the HKEY_CURRENT_USER hive.

OR

(2) If the user selects Install for Everyone while installing the add-in, the entries are made in HKEY_LOCAL_MACHINE.


The keys I am referring to here are the LoadBehavior key for registering the add-in with the MS Office application.

To test the add-in installation, I created four users of the network domain with different ranks - an Administrator, a Standard User, a Restricted User and a Power User. It runs absolutely fine for all of them.

I also created two users on the local machine namely, PlainUser, a Standard Users group member, and SuperMan, an Administrators group member for the local machine.

When I log in as SuperMan, the add-in launches on the start up of the MS Office application. I find the keys I made during the setup I described above in the HKEY_LOCAL_MACHINE, as they should be. Seemingly, and rightly so, they do apply for him and thus the application is launched.

However, when I log in as PlainUser, the Users group member, the add-in does not launch on the start up of the MS Office application. This, inspite of the fact that the HKEY_LOCAL_MACHINE entries are intact.

This leads me to conclude that the local machine users with restricted rights do not even have read rights to any other hive than HKEY_CURRENT_USER.


My first concern is:

Is it even a reasonable demand to have a restricted user read keys from the registry other than CURRENT_USER?

If yes, what's the place in the registry that stores this user's settings? The user being referred to here is the Standard Users group (without rights, the under-privileged user) member on the local machine and not on the network domain.

This leads me to conclude that the local machine users with restricted rights do not even have read rights to any other hive than HKEY_CURRENT_USER.

Wow. Wrong conclusion. So... no. Just run regedit as a normal user. And you'll see and be able to edit all the keys/values that that normal user kan see and edit. (You can certainly read HKEY_LOCAL_MACHINE) For the rest, debug on your own, and may the force be with you and all that. ;-)

One idea might be to attempt a read/write to a specific key in the registry, and if it fails (check for failures), then use something like an INI file to store the user's data (who is probably not a local user if the check fails...)

I'm not saying that it could work, or is feasible for your situation...  That it might work is context-specific to what needs to be done...  so, it's just a free, (possibly worthless!) idea...

*RESOLVED*

Thanks for the suggestion, Peter, but I can't use that mode of persistence because I am not the one persisting the settings in the registry. It is like I _HAVE_ to do that thing in the registry for COM (Outlook is a COM person) to know that there's an Add-in made in .NET that it has to run when it starts up.

It was a file permission related problem. Actually, like Dave said, the suspicion I had was wrong. I couldn't believe it fully too. I mean I was surprised in what I was forced to believe. I said to myself, "it doesn't make sense. LOCAL_MACHINE is biased? How can that be. I am the dick here."

Then I realized I was logging every darn event into an application log and that used to fail. So, the PlainUser guy was still reading the LOCAL_MACHINE and the add-in was getting loaded but before it could fully be instantiated, the logging failed because the user had no write right over the application directory and the control quit the app.

As a solution, I changed the loggin to the application data directory (\Doc & Settings\UserGuy\App Data\). Works!