- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This question may be a little out of forum as it is to do with MS OSs but as it relates to fortran applications I thought I'd ask it here first. My application writes and reads the registry for such data as recently opened files and license key. Logically these two sorts of data go under seperate registry keys; recently opened files under hkey_current_user and license key under hkey_local_machine (or at least that's the logic I'm applying). I have recently looked into deploying my application and am using a commercial installer for this purpose. When I use this software to uninstall my application it can be instructed to delete registry keys and this is does. However I spotted an issue with this in that there is something called registry virtualisation which may be applied to keys under the hkey_local_machine group. I spotted this on a Vista machine where I tested my deployment but didn't see it on my W7 development machine. However, yesterday I spotted that my UAC setting was down at its lowest setting so I shoved it back up to the 2/3 setting. I now get registry virtualisation on my W7 machine. This is not a problem for my application in the sense that it doesn't know that this is occurring and can still read/write the registry key. However it is not clear that I can tell the uninstaller the exact location of the virtualised key as it is certainly different for my two computers (vista and w7). The virtualised key is under hkey_users/s-1-5-21-2555............../software/classes/virtualstore/machine/software/my_key. The s-1-5-21-2555....... part of the address seems to be machine dependent. So my question is what are the alternatives? Can, for example, one force the writing of the key to the unvirtualised address by getting my application to have a different priority/security/... setting - although as I am working under an administrator account I don't quite see how this could be relevent. Anyway if anyone has experience of dealing with this sort of issue I'd be grateful if you could share it.
Many thanks, ACAR.
Link Copied
14 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Search for RegOpenKeyEx. Here you can find further information about registry virtualisation, how to avoid it and how todeal withredirected and not redirected keys.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have already looked at this but to no avail (unless I'm missing a trick). I can't see anything there about forcing a particular behaviour so I guess I need to tell my application to assume a certain security level?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you read carefully all about virtualisation your only problem can be how to locate or change keys like hkey_users/s-1-5-21-2555............../. Don't use keys like that! Use hkey_current_user instead. You only need keys like hkey_users/s-1-5-... if you want to change keys from other users. But this will fail because of security issues.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I agree with rwg - don't do that. One form of "virtualization" is used when running a 32-bit app on 64-bit Windows, but it should all be transparent. Unless you really do want to license per-user, you would be better off to stick to HKEY_LOCAL_MACHINE. But I'll note that writing this not during install may be problematic, so perhaps you have to use HKEY_CURRENT_USER after all.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Exactly - that was the question I was asking: how to locate keys of the type you mention. My logic may be flawed but I thought that if I put the license key for a machine under a hkey_current_user location then other users would not be able to access it. The logical place to me seemed to be under hkey_local_machine.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My registry interaction for hkey_local_machine is being virtualised by the OS. My installer does not have this issue but I want my installer to find the virtualised location when it uninstalls my application. The only option seems to me to be able to elevatethe UAC setting for my application when it interacts with the registry?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Windows usually recognizes installers and grants them permission to change the REAL HKLM tree, instead of giving each user a local copy to play with which it does for compatibility. If you are using a regular install tool (InstallShield, Wise, etc.) you should not need to do anything special. I don't know how Windows decides what constitutes an installer.
The other choice, which may be what you want, is to link with a manifest that specifies the program should run with administrator privileges. I don't know offhand the details for that but I'm sure you can find them. Windows will then prompt the user to allow it.
It would be better if you could use HKLM for this.
The other choice, which may be what you want, is to link with a manifest that specifies the program should run with administrator privileges. I don't know offhand the details for that but I'm sure you can find them. Windows will then prompt the user to allow it.
It would be better if you could use HKLM for this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting acar
...The only option seems to me to be able to elevatethe UAC setting for my application when it interacts with the registry?
Are you doing something "machine global" like updating a use-count every time your application runs?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Ian. The procedure I am using is as follows: My application is installed on a new users machine via a commercial installer. I have not currently asked it to create any registry keys as I am doing this with my application. The user runs my application and if no license key is present on the machine (checked by looking in a HKLM address) the user must get a license key from me). With a license key the user then reruns my application which reads the key and puts it in HKLM address. What I am finding though is that (depending on UAC setting) my application could virtualise the HKLM address. This is no problem for my application. But if the user then uninstalls my application I would like it to remove the license key. However, if it has been virtualised it won't easliy find it and so it remains undeleted. Equally, although I have not yet tried this, after my application has been licensed, another user may wish to run the application and if the license key has been virtualised by the first user then perhaps the new user may not have access to the license key? Actually I have just tried this and as I suspected the other user cannot find the virtualised license key. If I understand you correctly IanH then provided the license key can actually be written to a HKLM address (which required elevated rights) then any user can read from there - i.e. it is only the write key that is virtualised. So is the way round to have a seperate small application with elevated rights (like the installer) that is called to perform the initial write to HKLM? If so then how does one elevate rights for a Fortran application?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is only a concern if the license key is stored as plain text in the registry key. What if your application stores the key as an encrypted string? It can recover the key, decrypt and then test it. If you cannot delete the encrypted key later on uninstalling the application, should that matter to you?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Anthony. I am keeping the key in encrypted form and you're right that it is not much of an issue about the uninstaller not being able to find it for deletion (except from a housekeeping point of view). The issue I have, I think, is that if the first run of my application installs the encrypted key in the registry and it is virtualised then other users of the same machine can't find it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This link shows you what should go into a manifest file and what is required to attach it to the application's resource file so that Windows Vista and XP can be told what privilege level the application needs to run.
http://msdn.microsoft.com/en-us/library/bb756929.aspx
http://msdn.microsoft.com/en-us/library/bb756929.aspx
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Anthony that works as planned (at least once I'd realised how to add and embed the manifest into my application). If I elevate the application execution level to requireAdministrator then the HKLM write is no longer virtualised. Just need now to check that a standard user can read from the HKLM key and if so then I need to write a little application to register my license key prior to running my main application.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Actually, I've just discovered that one doesn't need to have a explicit manifest file for this as the project properties (linker>manifest file) has the options to set the UAC Execution Level. But I am wondering whether the resulting embedded manifest is compatible with Vista and XP...... I'll discover that in due course!

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page