Codejock Forums Homepage
Forum Home Forum Home > Codejock Products > Visual C++ MFC > General Discussion
  New Posts New Posts RSS Feed - Vista Registry VirtualStore
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

Vista Registry VirtualStore

 Post Reply Post Reply
Author
Message
Ark42 View Drop Down
Senior Member
Senior Member
Avatar

Joined: 20 October 2003
Status: Offline
Points: 291
Post Options Post Options   Thanks (0) Thanks(0)   Quote Ark42 Quote  Post ReplyReply Direct Link To This Post Topic: Vista Registry VirtualStore
    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.
Back to Top
kinook View Drop Down
Groupie
Groupie


Joined: 13 May 2003
Location: United States
Status: Offline
Points: 14
Post Options Post Options   Thanks (0) Thanks(0)   Quote kinook Quote  Post ReplyReply Direct Link To This Post 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
Automate software builds with Visual Build Pro

http://www.visualbuild.com
Back to Top
Ark42 View Drop Down
Senior Member
Senior Member
Avatar

Joined: 20 October 2003
Status: Offline
Points: 291
Post Options Post Options   Thanks (0) Thanks(0)   Quote Ark42 Quote  Post ReplyReply Direct Link To This Post 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).

Back to Top
kinook View Drop Down
Groupie
Groupie


Joined: 13 May 2003
Location: United States
Status: Offline
Points: 14
Post Options Post Options   Thanks (0) Thanks(0)   Quote kinook Quote  Post ReplyReply Direct Link To This Post 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

http://www.visualbuild.com
Back to Top
Ark42 View Drop Down
Senior Member
Senior Member
Avatar

Joined: 20 October 2003
Status: Offline
Points: 291
Post Options Post Options   Thanks (0) Thanks(0)   Quote Ark42 Quote  Post ReplyReply Direct Link To This Post 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?
Back to Top
ijwelch View Drop Down
Senior Member
Senior Member


Joined: 20 June 2006
Status: Offline
Points: 262
Post Options Post Options   Thanks (0) Thanks(0)   Quote ijwelch Quote  Post ReplyReply Direct Link To This Post 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>

Back to Top
Ark42 View Drop Down
Senior Member
Senior Member
Avatar

Joined: 20 October 2003
Status: Offline
Points: 291
Post Options Post Options   Thanks (0) Thanks(0)   Quote Ark42 Quote  Post ReplyReply Direct Link To This Post Posted: 14 January 2008 at 11:32pm

So the entire app must run as elevated-admin, not just the dialog where registration happens then? 
Back to Top
Sven View Drop Down
Senior Member
Senior Member


Joined: 21 August 2003
Location: Germany
Status: Offline
Points: 127
Post Options Post Options   Thanks (0) Thanks(0)   Quote Sven Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
Ark42 View Drop Down
Senior Member
Senior Member
Avatar

Joined: 20 October 2003
Status: Offline
Points: 291
Post Options Post Options   Thanks (0) Thanks(0)   Quote Ark42 Quote  Post ReplyReply Direct Link To This Post 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.


Back to Top
ijwelch View Drop Down
Senior Member
Senior Member


Joined: 20 June 2006
Status: Offline
Points: 262
Post Options Post Options   Thanks (0) Thanks(0)   Quote ijwelch Quote  Post ReplyReply Direct Link To This Post Posted: 15 January 2008 at 10:57pm
Back to Top
Sven View Drop Down
Senior Member
Senior Member


Joined: 21 August 2003
Location: Germany
Status: Offline
Points: 127
Post Options Post Options   Thanks (0) Thanks(0)   Quote Sven Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
Ark42 View Drop Down
Senior Member
Senior Member
Avatar

Joined: 20 October 2003
Status: Offline
Points: 291
Post Options Post Options   Thanks (0) Thanks(0)   Quote Ark42 Quote  Post ReplyReply Direct Link To This Post 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.

Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 12.04
Copyright ©2001-2021 Web Wiz Ltd.

This page was generated in 0.172 seconds.