Print Page | Close Window

Vista Registry VirtualStore

Printed From: Codejock Forums
Category: Codejock Products
Forum Name: General Discussion
Forum Description: Topics Related to Visual C++ MFC Development in General
URL: http://forum.codejock.com/forum_posts.asp?TID=9303
Printed Date: 21 May 2024 at 9:30pm
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com


Topic: Vista Registry VirtualStore
Posted By: Ark42
Subject: Vista Registry VirtualStore
Date Posted: 14 January 2008 at 12:26pm

My application installer (InnoSetup) creates a registry key called "auto" at "HKEY_LOCAL_MACHINE\SOFTWARE\Morpheus Software\Morpheus Photo Morpher" containing the activation code which the user enters during setup. When the program first runs, it sees this key, attempts to activate the software, then tries to create a key called "registration" in the very same location. The reason for this, is so that multiple users can have the software usable on one machine. All other registry access and settings is in HKEY_CURRENT_USER only.

This works fine on all windows through XP, and for nearly all of my users on Vista, but recently a few Vista users were having trouble with the software not staying activated for them. It turns out that the program is writing the "registration" key to "HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Morpheus Software\Morpheus Photo Morpher" but then trying to read the very same key from "HKEY_LOCAL_MACHINE\SOFTWARE\Morpheus Software\Morpheus Photo Morpher" where it doesn't exist.

What is the reason for this nonsense, and how can I have the user work around it, or program around this? I can't seem to find much information from Google other than the fact that Vista DOES do this. My installer has no trouble writing to the real location, and my program can read the "auto" key from the real location, but it can't seem to write back to the very same location.



Replies:
Posted By: kinook
Date Posted: 14 January 2008 at 1:39pm
It's called virtualization, and it's there to allow some legacy apps that don't play well with non-admin scenarios to still work on Vista (non-admin users on Win 2000 and later and non-elevated admin users on Vista can't write to HKEY_LOCAL_MACHINE and %ProgramFiles%).

http://www.kinook.com/blog/?p=40 - http://www.kinook.com/blog/?p=40

-------------
Automate software builds with Visual Build Pro

https://kinook.com/VBP/" rel="nofollow - http://www.visualbuild.com


Posted By: Ark42
Date Posted: 14 January 2008 at 1:51pm
My app is not exactly legacy, and the user IS running as an administrator, I verified that the InnoSetup installer ran correctly for them with the same user logged in, and it did not prompt for a different username/password to run. My InnoSetup configuration requires Admin privileges to run, so it shouldn't even install if that is not present. It was clearly able to create C:\Program Files\Morpheus Photo Morpher and write to that location, as well as HKLM in the registry from the installer.  But then my application, from the same user account, can't write to HKLM for some reason still.

Should the only conclusion be that the user is wrong, and they are simply not running as an Administrator?
The only test I have in the program code to prevent the user from activating as a non-admin account was to check if I can open the "registration" key for writing or not (which works on 2000/XP to tell Admin from non-Admin).



Posted By: kinook
Date Posted: 14 January 2008 at 2:05pm
Like I said, non-elevated admin users on Vista can't write to HKEY_LOCAL_MACHINE and %ProgramFiles%. Most likely your installer is running elevated, but when the user starts your program after installing, it is running unelevated. See the links in the blog post for more details.

-------------
Automate software builds with Visual Build Pro

https://kinook.com/VBP/" rel="nofollow - http://www.visualbuild.com


Posted By: Ark42
Date Posted: 14 January 2008 at 3:46pm
Ok, can you point me towards the API functions I need to use to elevate admin to real-admin and a better way to test if the current user is actually an admin to begin with?

What I still don't really understand though, is when the key is created at "HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Morpheus Software\Morpheus Photo Morpher" because of a write to "HKEY_LOCAL_MACHINE\SOFTWARE\Morpheus Software\Morpheus Photo Morpher", why does a read from "HKEY_LOCAL_MACHINE\SOFTWARE\Morpheus Software\Morpheus Photo Morpher" for the same key then fail? Shouldn't the READ be virtualized too?


Posted By: ijwelch
Date Posted: 14 January 2008 at 8:58pm
To get elevate admin you need to say so in a manifest file. eg:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <assembly
     xmlns="urn:schemas-microsoft-com:asm.v1"
     manifestVersion="1.0">
     <assemblyIdentity
       processorArchitecture="x86"
       version="5.1.0.0"
       type="win32"   
       name="MYAPPNAME.exe"/>
       <description></description>
         <dependency>
           <dependentAssembly>
             <assemblyIdentity
               type="win32"
               name="Microsoft.Windows.Common-Controls"
               version="6.0.0.0"
               publicKeyToken="6595b64144ccf1df"
               language="*"
               processorArchitecture="x86"/>
           </dependentAssembly>
         </dependency>

<!-- Identify the application security requirements, for Windows Vista . -->
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
     <security>
       <requestedPrivileges>
         <!-- <requestedExecutionLevel level="requireAdministrator" />  -->    
         <requestedExecutionLevel level="highestAvailable" />
       </requestedPrivileges>
     </security>
  </trustInfo>

</assembly>



Posted By: Ark42
Date Posted: 14 January 2008 at 11:32pm

So the entire app must run as elevated-admin, not just the dialog where registration happens then? 


Posted By: Sven
Date Posted: 15 January 2008 at 4:21pm
Only elevated apps can write to HKLM. Elevation is only possible for the whole process, impersonation for a few lines isn't possible. An alternative is an elevated COM object.


Posted By: Ark42
Date Posted: 15 January 2008 at 4:25pm
A separate app or COM object for a couple-line popup dialog that does the registration simply isn't worth it. "highestAvailable" it is then.

Is there an API to check what level of permissions the applications is actually running with, since before I only checked if the key I wanted in HKLM was writable, and if that failed, greyed out the text box and put up a message stating that you must be administrator to activate the software. Now with Vista, that key will always be writable, even if it is virtualized.




Posted By: ijwelch
Date Posted: 15 January 2008 at 10:57pm
This may help:
http://www.codeproject.com/KB/vista-security/VistaElevator.aspx - http://www.codeproject.com/KB/vista-security/VistaElevator.aspx


Posted By: Sven
Date Posted: 20 January 2008 at 7:46am
Originally posted by Ark42 Ark42 wrote:

A separate app or COM object for a couple-line popup dialog that does the registration simply isn't worth it. "highestAvailable" it is then.Is there an API to check what level of permissions the applications is actually running with, since before I only checked if the key I wanted in HKLM was writable, and if that failed, greyed out the text box and put up a message stating that you must be administrator to activate the software. Now with Vista, that key will always be writable, even if it is virtualized.

If you are using a manifest, Vista doesn't virtualize registry and file access. You can check the virtualization status with Task Manager, there is a special column for virtualization.


Posted By: Ark42
Date Posted: 20 January 2008 at 12:48pm
I'm using a manifest, but only for XP theme support. Until just now, I hadn't put in the magical "don't break my app" Vista lines.




Print Page | Close Window

Forum Software by Web Wiz Forums® version 12.04 - http://www.webwizforums.com
Copyright ©2001-2021 Web Wiz Ltd. - https://www.webwiz.net