Vista Registry Problem

Posted on 2007-03-28
Last Modified: 2008-03-06
I have written a C# shareware application and I am due to release the next version very soon, but I have just discovered it has an incompatibility with Windows Vista. The problem stems from the fact that the program consists of two parts: an executable and a Windows Service. The two parts need to share a registry setting. The Windows Service initialises when the machine starts up, before any user logs on. At present the program writes a setting under the HKEY_LOCAL_MACHINE key, and this can be read by the Windows Service the next time the machine boots. But it now transpires that this is key is not being read correctly by Vista users, because in fact the program only thinks it is writing to HKEY_LOCAL_MACHINE - in fact the value is stored in a virtual registry key under CURRENT_USER. Is there any way I can write to the registry from my program and have the key read by the Windows Service at start up, before there is a current user? It is really imperative that the user NOT have to go into Windows settings or configure any permissions, because many of the users of this program have almost no computer literacy.
Question by:zaphekiah
LVL 41

Expert Comment

ID: 18807626
So is the problem related to the "confusion" on where the item is written?   Or is it a permissions issue, where the user part of the application does have permission to read the registry key?
LVL 24

Expert Comment

ID: 18808966
Try right-clicking the program and selecting Run as Adminstator and see if it then updates the HKEY_LOCAL_MACHINE correctly instead (or just disable UAC). Due to the way UAC works, even when logged in as an Adnimistrator, programs only run with user level rights which could be causing the problem. There are ways to program around this if it ends up being the problem.

Author Comment

ID: 18810533
I obviously didn't explain myself very well. I will give some more background information...

I have been developing a program for the last five years. About six months ago I began work on a new feature which allows users to exchange files via a peer-to-peer file exchange which uses .NET remoting. File requests are not handled by the program itself, but by a Windows Service which is also installed when the program is installed. The advantage of this is that shared files are always available to other users, whenever the sharer's computer is switched on. It does not matter if the sharer has run the program in that session or not.

I use a public server to co-ordinate information about which users are logged on, and enable them to find each other. When the user's computer is first started the Windows Service has to communicate with the server to let it know that it's files are available. It does this by sending a GUID which uniquely identifies that machine. This GUID is held in the registry. It is held in the LOCAL_MACHINE cluster, because if it were in the CURRENT_USER part of the registry it would not be available to the Windows Service, because when that boots up no user is logged on.

So to summarise, this string must be available to the program itself and to the Windows Service. Using the LOCAL_MACHINE key works fine under Windows XP, 2000 etc. It seems to work fine under Vista to begin with, because the program can apparently create the key without errors. But the next time the user reboots his machine and the Windows Service attempts to read the key he gets an empty string. The reason is because while Vista has apparently created the key under LOCAL_MACHINE, in fact it has created it under HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE - a "virtual" location which is different for each user, obviously. Apparently this is similar to the way Vista keeps a "virtual" Program Files folder for each user - in fact it is a different folder for each user but they all map to the same virtual location.

So I want to know if there is anyway I can use the registry under Vista that is independent of who is logged on, or if anyone at all is logged on.

I might be answering my own question here, because one way would be to have the Windows Service run under the user account, not the machine account, and start up after the user has logged on. But I experimented with this at the beginning and it seemed to cause all kinds of problems for the Windows Installer. I am due to release this new version soon, and I am very reluctant to change the WI setup without a lot of testing. In my experience if there is a problem with the program itself users will tell you about it, but if there is a problem with the installation you will only be able to work that out a year into the future when you see it has been a bad one for sales. If people don't even manage to install a program they just curse you for wasting their time; they haven't got enough invested to actually let you know.

I might just let it go and have this feature unavailable for Vista users until I can test a proper solution. Reading between the lines of Microsoft's press release they have had a disappointing first month for Vista sales, so it probably won't impact on many users for a year or two. On the other hand it would be nice to get this working for them, especially because by including a Windows Service in the package I have lost any Windows 98 users that were hanging around :-(

Any ideas anyone?
The Eight Noble Truths of Backup and Recovery

How can IT departments tackle the challenges of a Big Data world? This white paper provides a roadmap to success and helps companies ensure that all their data is safe and secure, no matter if it resides on-premise with physical or virtual machines or in the cloud.

LVL 41

Expert Comment

ID: 18810633
As others have pointed out, this is all related to the new permission model for Vista.   I would highly recommend that you at least test your program using an Administrator account with the User Account Control (UAC) feature turned off.  (You can turn it back on after the test).

This simple test will tell us how to proceed to fix the problem.
LVL 41

Expert Comment

ID: 18810783
So, assuming that there are no other issues, you have a few choices...

1) Move the key to a more public place (that is not virutalized).   This is the preferred solution, since it should be clear by now, that Microsoft doesn't want that kind of registry access by oridnary users.
2) Create/Embed a manifest file that tells the OS to elevate the priledges

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
 <assemblyIdentity version="" processorArchitecture="X86" name="Privelidged" type="win32"/>
 <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <requestedExecutionLevel level="requireAdministrator"/>


Author Comment

ID: 18813678
1) Which "more public place" are you talking about? As registry settings go, I thought LOCAL_MACHINE was pretty public.

2) You seem convinced this is about privilidges, and it would be helpful if you could explain why. Vista has not given any alerts about privilidges. It hasn't logged any errors saying "you do not have enough privilidges to do that". In fact it hasn't logged any errors at all. It is simply looking in a different place in a registry than XP does. Where do privilidges come into this?

Also I am skeptical that including a config setting saying <requestedExecutionLevel level="requireAdministrator"/> would be very helpful. Some people who use the program undoubtedly will not have administrator accounts. I would like them to be able to use the program the same way XP users can.

As an aside, I don't have access to a machine with Vista on for testing. I do have a friend with Vista who has been doing some beta testing, and it is he who has reported this bug. He definitely does has full privilidges on his machine because he is the only user.

Author Comment

ID: 18813747
OK, I have found this article which explains the situation:

In view of what it is saying I think I will rewrite the program not to use LOCAL_MACHINE, and change the Windows Service to run under the users account.

Author Comment

ID: 18951253
That seems about right, although in fairness graye's answer did turn out to be in the right direction...just he didn't explain himself very well (and the preferred solution according to the Microsoft article would be to find a way of doing it that didn't require administrator rights, which is the opposite of what he suggested).

For the benefit of anyone who might have a similar problem I might just report that I tried having the Windows Service run under a user account but that meant that the user was presented with a log-in dialog DURING INSTALLATION, asking for the account name under which the service would run. This was completely unacceptable because a lot of peole who install the program will simply cancel at that point, thinking that their security is being compromised or something. OK for a corporate software install but definitely not OK for commercial software. So instead I included a manifest similar to the one graye described (see the microsoft article for details) and the program now runs ok under Vista, albeit that it has a shield icon over the desktop shortcut and requests admin rights everytime it starts. All for one registry key. Ho hum.

Accepted Solution

Computer101 earned 0 total points
ID: 18970665
PAQed with points refunded (500)

EE Admin

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

In order to hide the "ugly" records selectors (triangles) in the rowheaders, here are some suggestions. Microsoft doesn't have a direct method/property to do it. You can only hide the rowheader column. First solution, the easy way The first sol…
This article introduced a TextBox that supports transparent background.   Introduction TextBox is the most widely used control component in GUI design. Most GUI controls do not support transparent background and more or less do not have the…
The Task Scheduler is a powerful tool that is built into Windows. It allows you to schedule tasks (actions) on a recurring basis, such as hourly, daily, weekly, monthly, at log on, at startup, on idle, etc. This video Micro Tutorial is a brief intro…
Nobody understands Phishing better than an anti-spam company. That’s why we are providing Phishing Awareness Training to our customers. According to a report by Verizon, only 3% of targeted users report malicious emails to management. With compan…

679 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question