Vista Registry Problem

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.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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?
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.
zaphekiahAuthor Commented:
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?
10 Tips to Protect Your Business from Ransomware

Did you know that ransomware is the most widespread, destructive malware in the world today? It accounts for 39% of all security breaches, with ransomware gangsters projected to make $11.5B in profits from online extortion by 2019.

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.
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"/>

zaphekiahAuthor Commented:
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.
zaphekiahAuthor Commented:
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.
zaphekiahAuthor Commented:
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.
PAQed with points refunded (500)

EE Admin

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Vista

From novice to tech pro — start learning today.