What’s New in the February CTP

Hi. I’m Alex, the product manager for User Account Control. Today we released February Windows Vista CTP (build 5308) and we wanted to make beta testers aware of what new things you’ll find in this build.

• Application-Aware Elevation Prompts
  The elevation prompts that users see are now customized based on the type of application that is running. To have control over which prompt the user sees, the executable must be signed using Microsoft Authenticode technology. If an unsigned application attempts to run with full administrator privileges, the approval dialog will contain stronger warning language and be color coded to warn users of the potential risk.

  But for signed applications and Windows component, the dialogs will use different colors, icons, and less strong warning language.

  This will help users tell at a glance if they need to be extra-cautious before running a particular program. Developers who do not yet digitally sign their applications should begin signing them to prevent Windows Vista customers from seeing these strong warnings when attempting to install or run your software.

  We are still refining these dialogs, but the February CTP shows the direction we are headed.

• Access to Virtualized Files
  It is now easier to find the files that are redirected by the file virtualization capabilities in Windows Vista. First, a brief explanation of what we mean by virtualization in User Account Control. Many applications break for standard users (non-admins) today because they attempt to write to protected areas that the standard user does not have access to. Windows Vista will improve application compatibility for these users by redirecting writes (and subsequent reads) to a per-user location within the user’s profile. For example, if an application attempts to write to “C:\program files\appname\settings.ini” and the user doesn’t have permissions to write to that directory, the write will get redirected to “C:\Users\username\AppData\Local\VirtualStore\Program Files\appname\.”

  To make it easier to find these redirected files we added a new button to Windows Explorer. If there is a virtualized version of a file related to the current directory, a Compatibility Files button appears that will take you to the virtual location to view that file.

• Run as Administrator
  The right-click “Run elevated” command that you could use to force an application to run with elevated privileges is now called “Run as administrator

If you find other things that are new, different, or unexpected in this build please post them as comments on this entry.

- Alex Heaton
  User Account Control Product Manager

Comments

• Anonymous
  February 22, 2006
  PingBack from http://kernelmustard.com/2006/02/22/new-ctps-available/

• Anonymous
  February 22, 2006
  Regarding the file virtualization capabilities in a managed domain environment:  Wouldn't this basically allow a regular user to install software on the machine?  None of our users are administrators here and one of our main reasons is to stay in compliance with licensing.  Right now, we dictate what software is installed, but if users are able to write to Program Files and HKLM and HKCR in the registry, regardless of whether that write is virtual or not, we'll lose the ability to prevent rogue software installs.
  
  I am quite excited about this new functionality since it will save us a lot of time tracking down those pesky perms that are needed, but I'm hoping there's some way to address my above concern.
  
  btw, thanks for this blog, I've really enjoyed it.

• Anonymous
  February 22, 2006
  Scotte. Executable code will not be virtualized. This virtualization is not designed to allow rogue software installation. But it is designed to help applications that save user settings in the programs files folder, for example.

• Anonymous
  February 22, 2006
  It looks very cool from the posted images.
  
  I don't have access to Vista but I was wondering what happens should a service (without rights to interact with the desktop) download an application (assuming it has rights to use the network) and attempt to run the application?  Will the rights be inherited from the service or will the user see a dialog?
  And assuming fast user switching is enabled - which user account will see the dialog?

• Anonymous
  February 22, 2006
  The comment has been removed

• Anonymous
  February 22, 2006
  Thanks for the reply Alex.  Would you care to elaborate on how it determines if something is executable?  Is there just some list of file types that are allowed and disallowed?  How are registry changes handled?  Will it prevent me from installing an application if I change the destination from Program Files to a folder I have full rights over?  For instance, instead of installing Word Perfect to C:Program FilesWP, if I tell the installer to go to C:Documents and SettingsMeWP, I'll have full rights to copy all the installing files, and if the registry keys get virtualized, I'll have in effect installed a rogue app.
  
  Thanks

• Anonymous
  February 23, 2006
  So what happens if I do sign my application but run it as a standard (non-admin) user? Do I still get the prompts? (maybe one with less strong warning).
  
  From the two screenshots above, it looks like the standard user will get the prompt no matter what - UNLESS the application itself has a manifest included that says it to run with full admin rights. For most consumer apps, I am not sure if running with full admin rights is the way to go.. (kind of goes against all the security steps you are taking :))

• Anonymous
  February 23, 2006
  Keeron:
  
  I think you misunderstood a bit - the default is that apps will run without admin priveleges.  When an app needs to run with full priveleges, you will get the prompt.
  
  Signing or not signing your executable sounds like it might affect whether you get a terrifyingly scary orange prompt or a friendly blue one.

• Anonymous
  February 25, 2006
  Are you curious to know what is new in the February CTP? Find out on the UAC Blog.

• Anonymous
  February 26, 2006
  I am working with the Feb CTP and I can't figure out if it is IE7 or UAC that is causing me an issue.  I need to make a cert request for an IPSec cert to our Windows Certificate Services site so I can use VPN (std Windows 2003 stand alone CA).  However, when I get to the page that I need to use, it hangs forever at "Downloading ActiveX Control..".  I have made that site a Trusted Site, tried turning off UAC, no change.  Any ideas on this?
  Thanks,
  Joseph

• Anonymous
  February 27, 2006
  With the Feb CTP, I'm seeing some applications trigger a dialog entitled "Program Compatibility Assistant".  This dialog says that "Windows detected that this program did not run correctly ... To try and fix the program, Windows has applied compatibility settings to this program.  Windows will use these settings the next time you run the program."  
  The result of these automatically applied settings is that now whenever I run the program, Windows prompts for administrative elevation, for some of the DLLs used by the application.  The app seemed to run OK without elevation with the Dec CTP.
  
  Can you elaborate on what criteria Vista uses to trigger the Program Compatibility Assistant and automatically apply elevation requirement?

• Anonymous
  March 01, 2006
  The comment has been removed

• Anonymous
  March 02, 2006
  I disagree with your description of which of the displayed approval dialogs contains stronger warning language. Your readers may well agree with you, but millions of average users will not.
  
  "This program can potentially harm your computer" is a strong warning of a dangerous outcome.  It is in clear, common-sense language, and further strengthened by the preceding sentence, which includes the warning phrase, "do not use this program."
  
  However, "This program does not have a valid digital signature that verifies its publisher" (which you say is the "stronger warning") does not describe any outcome at all. It is merely a statement of a technical fact, the significance of which is unknown to millions of PC users.  Worse yet, most people have already seen similar statements associated with major software products that are known to be safe.  To compound the problem, it is preceded by the weakly worded reference to "publishers you trust," which allows the average user to miss the whole point that the publisher's identity remains unverified.

• Anonymous
  March 02, 2006
  I believe you should be BLATANTLY VERY stern!
  
  1. If the user is scared sh*tless into not installing the program, they might not install; they might delay, ask a friend for advice, or seek alternatives. This IS a good thing!
  2. Companies knowing this would avoid applications that result in the program bringing the orange promt knowing that users might be chased away from using their product. This IS a good thing!
  
  For the Grey prompt just state:
  
  -Windows need your permission to install
  
  *Do no let the cursor default to either the SUBMIT or CANCEL button
  
  For the Orange prompt try:
  
  -This application DOES NOT have the approved Microsoft Authenticode Technology provided for Windows.
  -Windows CANNOT authenticate this application.
  -Windows STRONGLY ADVISES AGAINST installing this program without CLEAR CONFIRMATION of it's legitimacy FROM the Manufacturer.
  -Programs form illegitimate sources can potential SERIOUSLY harm your computer.
  -Do you still wish to install?
  
  *Let the cursor default to the CANCEL button
  
  I know this is a long shot, but there WOULD always be a developer to program poorly! And yes, I am aware that some application were designed for XP and not VISTA
  
  If you were to leave it as it is one would click the SUBMIT button in reflex by habit - I probably would. Colour on its own won't tell the user anything, except the user understood the manual and remembered it. Who ever reads it?
  
  Obviously, this is directed at the home user; IT pros should know what they are doing... I think, shouldn't they?

• Anonymous
  March 02, 2006
  The comment has been removed

• Anonymous
  March 03, 2006
  The comment has been removed

• Anonymous
  March 03, 2006
  Peter. Sorry if you found the entry confusing. I don't think I said that the reads were merged. You are correct that they are not. If there is a virtualized file, that is what the app will read. If there is no virtualized file the app will read from the true location.
  
  We agree we need to publish more documentation on this and we will. Since you've expressed an interest in it we'll bump it up on the priority list.
  
  If you post more info about why your app is failing someone on the team can try and help you.
  
  - Alex

• Anonymous
  March 04, 2006
  The comment has been removed

• Anonymous
  March 07, 2006
  Alex -
  
  Why have all the posts suddenly dried up?  You said, "post more information and someone will try to get back to you".  I have posted my basic needs, and since then there have been no additional entries.
  
  (I would have just sent you email, but clicking on "alex" just gets me the front page of all of the Microsoft blogs.  None of the Microsoft bloggers whose names start with "alex" seemed to be you.)
  
  Peter

• Anonymous
  March 09, 2006
  To Peter: Instead of trying to figure out how exactly virtualization works, you should fix the app so that it doesn't write to protected areas of registry or filesystem.
  
  Depending on virtualization is a very bad idea. In Vista, virtualization can be disabled by group policy. It can also change (or even completely disappear) in future service packs or OS releases. The following is a relevant quote from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/AccProtVista.asp:
  
  <quote>
  Virtualization is intended only to assist in application compatibility with existing programs. Applications designed for Windows Vista should NOT perform writes to sensitive system areas, nor should they rely on virtualization to provide redress for incorrect application behavior.
  ...
  Microsoft intends to remove virtualization from future versions of the Windows operating system as more applications are migrated to Windows Vista.</quote>

• Anonymous
  March 10, 2006
  To Alex,
  
  I would like to know the answers to the last 5 questions "Peter" stated on Saturday, March 04, 2006 6:36 PM.
  
  I believer this would be of interest to all.
  
  And yes, I know about the principles of LUA, best practices, and the fact that MSFT intends to remove virtualization from future versions etc. And I read the quote from Pavel Lebedinsky, but till applications have been rewritten... You and I know they would not ALL be updated by end of this year.
  
  Now MSFT recently acquired Apptinum, and it is available for an optional download but where does it fit in with all this?
  
  Now do try to avoid the answers or give some random statement or quoted tesxt please!

• Anonymous
  March 10, 2006
  The comment has been removed

• Anonymous
  March 10, 2006
  The comment has been removed

• Anonymous
  March 10, 2006
  The comment has been removed

• Anonymous
  March 10, 2006
  The comment has been removed

• Anonymous
  March 13, 2006
  John,
  
  Thank you.  This was a good description of the process.
  
  If I may add my two cents on the virtualizations: having programs that are "marked" not redirect or virtualize is, IMHO, a very silly decision.  In my particular case, for example, our "suite" of programs includes some that can be marked and others that cannot; the ones that we can mark (as it turns out) are the ones that we never, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, EVER want to see an elevation prompt for.  Hence, we mark them.  However, that means that those programs can't see the data files that just got written.
  
  It would be better if, when we mark an exe, we could also mark wether virtualization should be used or not.
  
  Peter

• Anonymous
  March 13, 2006
  Simply, to answer your question about Apptinum: The Apptimum technology will help customers transfer the state of their current installed applications from one PC to another, but it doesn’t improve the application compatibility on the destination PC. For example, if a user has Visio installed on their current Windows XP computer, and they buy a new computer with Windows Vista, this technology will help the customer transfer Visio to their new PC without needing to use the original install media. That said, file and registry virtualization could help this application work better on Windows Vista for standard users.
  
  Other information regarding features and availability of the Microsoft download are not yet available. More information should be posted to http://www.microsoft.com/windowsvista/ in the coming months.
  
  - Alex
  

• Anonymous
  March 14, 2006
  Peter,
  
  If file and registry virtualization are required for your legacy program to run as a standard user, and you are satisfied with the results, please contact us with this form:
  
      http://blogs.msdn.com/uac/contact.aspx
  
  There are other compatibility options we can apply to specific programs to avoid installer detection.
  
  For your new version, please ensure that all executables are marked with a requestedExecutionLevel so virtualization is disabled.
  
  Thanks,
  John (Microsoft)

• Anonymous
  March 15, 2006
  The unsigned dialog looks much more attractive than the other one, and makes me feel happy when I see it.
  
  The signed dialog looks boring and sad, and the other commenter nailed it when he said that the wording seemed backwards.
  
  All  up:
  - Attractive dialog with weak wording seems to reward me for running a bad program
  - Unhappy dialog with strong wording warns me off publishers that have done the right thing

• Anonymous
  March 22, 2006
  The comment has been removed

• Anonymous
  March 29, 2006
  Mike and Peter,
  
  The Program Compatibility Assistant (PCA) is a feature that monitors programs at runtime and looks for known compatibility issues. If it detects any compatibility issues, it then proposes a solution after the program terminates. In some cases the solution is automatically applied, like in the case you are seeing, in which the PCA dialog says: “Windows detected that this program did not run correctly ... To try and fix the program, Windows has applied compatibility settings to this program.  Windows will use these settings the next time you run the program”.  This specific PCA dialog comes up when a non-elevated program is detected to launch a child exe which fails because it’s detected to be an installer and is required to run elevated. This will be typically the case for programs trying to launch an updater.exe. The only way to get the updater to work is to apply a compatibility mode which will make sure the elevation prompt is shown for the child process. Would you mind telling us what the application in question is? We’d like to know why you are seeing the elevation prompt every time you start your app.
  
  The compatibility modes will be applied to the program (exe) by setting a registry key under ‘HKEY_CURRENT_USERSoftwareMicrosoftWindows NTCurrentVersionAppCompatFlagsLayers’ with key name = ‘full path of the exe’ and string value = ‘name(s) of the compatibility modes’ applied. This key needs to be deleted to remove the settings made by PCA.  This is the same location where the compatibility modes will be set for the program when a user tries to apply them manually through the program compatibility tab, which can be accessed by right clicking on an exe and selecting file properties.  
  
  Regarding how PCA manages to distinguish different ways of running a program, PCA intends to only monitor user initiated programs from explorer and IE. New instrumentation added into Shell enforces this. PCA will not monitor every program going through ShellExecute() or CreateProcess(). Also, PCA has other exclusion policies to exclude new programs that have a manifest with RunLevel settings for UAC. This will be best way to exclude the program from PCA.
  We need to add better documentation around this and we are also adding a PCA exclusion registry key that will be available in Beta2, where an exe can be added to be excluded from PCA. To note, there are other scenarios for PCA where the PCA dialog will show up with options to apply a solution or report that a program works correctly. If the user selects to report that a program works correctly, then PCA will not come up again for that program.
  
  thanks,
  Sathish (Microsoft)

• Anonymous
  March 30, 2006
  If you want to add an application manifest to an older executable without re-building it at all use the mt.exe program in the visual studio 2005 - or the platform SDK for VIsta. You can also load an exe in vs2005 to review its manifests.

• Anonymous
  April 03, 2006
  I hope in a future drop, the security dialog boxes can pull out the Application name from the WIN32 file version resource.  I think the average user should see "Power Point Viewer (ppviewer.exe)" instead of just "ppviewer.exe".
  
  One other thing, while "Run as Administrator" is handy I'm quite annoyed that the "Run as..." option has been removed.  I frequently need to run apps as other users not just as administrator.

• Anonymous
  April 05, 2006
  Right now we package all applications into msi to install on user machines. How can one capture these things CTP changes (virtualizes) to allow the application to run, so thtat the msi that is packages is usable in Vista. Any thoughts?
  
  Thanks.

• Anonymous
  April 12, 2006
  Sathish,
  Thanks for the additional information on the PCA.  Unfortunately it doesn't help me.
  
  >>We’d like to know why you are seeing the elevation prompt every time you start your app.
  
  I would also.  
  
  In my case, the executable that is triggering the PCA "“Windows detected that this program did not run correctly ..." dialog is a simple DirectX application.  It has been modified to comply with LUA, but it still triggers the PCA dialog.  It does load several DLLs, but the application and the DLLs do not launch any child executables.  
  
  The compatibility mode entry in the registry is "ELEVATECREATEPROCESS".
  
  Are there any other reasons for this message to come up?  
  
  I'm happy to let anyone there at MS examine the executable.
  

• Anonymous
  May 03, 2006
  The comment has been removed

• Anonymous
  May 03, 2006
  Imagine stopping at a gas station to fuel up your car, selecting Standard grade unleaded gasoline, and...

• Anonymous
  May 05, 2006
  Mike and rsclient,
  
  Sorry for late response on this.  Mike, to enable us debug your executable, please send e-mail to ‘pacsup@microsoft.com’ with information on how we can get access to the executable (e.g. zip file or a link to download) and include steps to repro.  There should not be other reasons for why PCA is triggering to apply the ELEVATECREATEPROCESS compatibility mode if it the program is not launching any child executables that are detected as installers.
  
  I will try to give more information on the other questions as follows,
  1) Can I manually trigger PCA?
  No. PCA runs automatically when it detects an older program that has a compatibility problem. However, you can use the Program Compatibility Wizard in help and support center or the Program Compatibility tab as part of properties on a program or on a setup file if it won't work or install correctly.
  
  2) How do I exclude apps from triggering PCA?
  The best option is to manifest the programs with the appropriate run level marking for UAC. This means the program is tested to work under UAC (and Vista) and marked to run either as requiring admin privileges or can run as standard user. PCA will exclude programs with this manifest. Link to information on the manifests is included as part of the UAC developer guidelines that you might have already seen:  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/AccProtVista.asp
  
  Other option is to set this registry key though the manifest option is more recommended,
  Key = HKLMSoftwareMicrosoftWindows NTCurrentVersionAppCompatFlagsCompatibility Assistant"
  Value name = ExecutablesToExclude
  Type = REG_MULTI_SZ
  
  The value should be the list of exes that need be excluded containing the full paths.
  
  Hope this helps and please send more questions on PCA to the pcasup@microsoft.com alias and I will post compiled information to the blog as applicable.
  
  Thanks,
  Sathish
  

• Anonymous
  May 08, 2006
  The comment has been removed

• Anonymous
  May 18, 2006
  The comment has been removed

• Anonymous
  May 20, 2006
  Rsclient
  
  You needed to send mail to the pcasup@microsoft.com as I mentioned in my previous response. This is the support alias setup for PCA, which is an independent feature.
  
  Coming to your questions,
  1) I will give more information on the PCA tracking and issue detection before answering your question on automating PCA. PCA is targeted to show up only for user initiated program (e.g. run from explorer). The reason was when PCA shows up after the program termination the end user will have context on the program that he/she launched. The code for deciding whether to track an exe for PCA checks specifically for this at program startup and there is no entry points for this. But, after  the exe is set to be tracked by PCA, the actual issue detection for this scenario to show PCA and apply the ELEVATEPROCESS compatibility mode depends on the event from CreateProcess(). This event will be always trigged independent of how the process is triggered. PCA will capture these events and will ignore them if it is not for the processes it tracks. If you need to check if your programs will trigger PCA on this scenario, after your run the program you can directly check the event log. This an operational type event under ‘Applications and Services Logs->Microsoft->Windows->LUA’. The event will include the PID of the process that triggered the event.   If you have more scenarios where you will need to trigger PCA in an automated fashion please send mail to the PCA support alias.
  2) PCA should not pop up for your program that is trying to add exes to the exclusion list if it not doing anything else that can trigger PCA (e.g. trying to launch an installer). Also, as you have already figured out, PCA will not track this program at all if it is not user launched (e.g. run from cmd.exe)
  
  It would be helpful if you give more information on why you are not happy with PCA showing up and if there is anything we need to fix. Specifically, if is an application that you think PCA is triggering unexpected or you have other feedback on PCA send mail to the pcasup@microsoft.com. If needed, I can setup a conference call with you.
  
  Thanks,
  Sathish
  

• Anonymous
  May 24, 2006
  Sathish,
  Thanks for the email address in your May 5 response.  Unfortunately I stopped checking back here for a while, so I didn't see your message.  Since Beta 2 just released, I thought I'd check my exe on that build before troubling your further.  
  
  The problem I was seeing with PCA causing elevation dialogs to pop up for no apparent reason does not happen on the Beta 2 build.  
  
  My app now runs fine without triggering any PCA dialogs.
  
  Thanks,
  -Mike S
  

• Anonymous
  June 19, 2006
  Is it possible to disable the right-click "Run as administrator" command for a particular program?
  The background of my question: We have developed an application with a local COM server and COM clients, the COM server controls some resources, therefore it is developed as a singleton to detect and finish a second instance of the COM server immediately.
  Normally several clients will be connected to the same instance of the COM server by the COM subsystem. But now, when one client starts the COM server with standard access rights and another client with admin rights, a second instance of the COM server will be started, because the second client runs under another account - an administrator's account. Now the singleton mechanism will finish the second instance, which will result to a hanging client until a timeout occurs after about 60 seconds.
  
  And I will go further: We will have the same problem if any process (e.g. an installer) starts the COM server with admin rights and the logged on user (with standard rights) then wants to connect to the COM server. So I think, we need a requiredExecutionLevel "lowestAvailable" or "loggedOnUser" (e.g.) to be able to fix the access rights of a particular program/process to the access rights of the loggod on user or better: to be able  to run the program as the logged on user who has elevated the process (e.g. an installer) before (the opposite of "Run as administrator").
  

• Anonymous
  June 21, 2006
  This entire thing with having to elevate user levels to run certain software, needing digital signatures, warnings about unknown publishers, and generally unneeded security settings need to be either eliminated or at least you need to allow an easy solution to turn it all off. I'm recommending to my customers not to even consider Vista until this is resolved.

• Anonymous
  June 21, 2006
  Rich,
  
  I think with UAC Microsoft is going into the right direction but the "entire thing" is not yet fully developed. As a software developer I have lost control over the access rights my software or parts of my software are running with, which will lead to the problems I have described before. And I want this control back.
  
  By the way: There is a local policy "User Account Control: Run all administrators in Admin Approval Mode" to enable or disable UAC.
  
  Thanks,
  Thomas

• Anonymous
  July 05, 2006
  You need to add [X] Remember Settings
  
  When users install our application, we do not want them to be prompted everytime.
  
  We have an Application that runs unattended and it goes in the startup folder, so it has to open and run automatically to do what needs to be done.

• Anonymous
  July 05, 2006
  The comment has been removed

• Anonymous
  August 29, 2006
  The comment has been removed

• Anonymous
  August 29, 2006
  It could be that the original setup.exe already contained a manifest w/ dependency information in it that was overwritten when you added your manifest.  Try this: Take the original setup.exe and use mt.exe to extract any existing manifest using the command:
  
  mt.exe -inputresource:setup.exe;#1 -out:orig.manifest
  
  If a manifest is generated, edit it to add in your trustInfo section.  Then add the manifest back with the command:
  
  mt.exe -manifest orig.manifest -outputresource:setup.exe;#1
  
  

• Anonymous
  August 29, 2006
  There isnt a manifest in the setup.exe.  when I attempt to extract the manifest I get an error saying the specified resource file type cannot be found in the image file.
  
  Thanks,
  Loren

• Anonymous
  August 30, 2006
  
  Loren,
  
  Could you post the contents of the manifest file you are embedding that causes the error?
  
  - Peter

• Anonymous
  August 30, 2006
  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
   <assemblyIdentity version="1.0.0.0"
      processorArchitecture="X86"
      name="setup"
      type="win32"/>
  
   <description>IAM</description>
  
   <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
     <security>
       <requestedPrivileges>
         <requestedExecutionLevel
           level="requireAdministrator"
           uiAccess="true"/>
         </requestedPrivileges>
        </security>
   </trustInfo>
  </assembly>
  
  
  I have tried a changing the name attribute to setup.exe, that didnt have any change.
  
  Another question, what happens is a user changes the name of the .exe, how will the embedded manifest know to run with the app?
  

• Anonymous
  August 30, 2006
  Hi Loren,
  
  Remove the attribute: uiAccess="true" from the manifest file.  This attribute is intended for use only by Assistive Technology applications.  The requestedExecutionLevel element should look like this:
    <requestedExecutionLevel
       level="requireAdministrator"/>
  
  The assembly name the manifest does not need to match the name of the .exe.  The fact that the manifest is embedded in the .exe is sufficient.
  

• Anonymous
  August 30, 2006
  I realize now I could have been more clear.  I see this error when I run the app in Xp in Vista the app just sits there. After deleting the uiAccess="true", the application will bring up the elevation prompt in Vista.
  
  However, the app is broken. A message saying, my app has stopped working is displayed. I understand adding the manifest will disable virtualization, does adding the manifest stop anything else that might cause this?  My app will work fine with out a manifest if run with elevated privileges.
  
  Thanks for all the help,
  Loren

• Anonymous
  August 30, 2006
  Loren,
  
  Looks like we'll need to look at this more closely.  Send an Email to: uacblog@microsoft.com with your email contact info.  Put my name: "Peter W" in the body of the message.  I should be able to help get this resolved for you.
  
  - Peter

• Anonymous
  August 30, 2006
  
  also, the error that I was seening is still seen in XP.  Adding a manifest to delcare UAC awareness shouldnt break it in XP, should it?
  
  Thanks

• Anonymous
  September 29, 2006
  If a user upgrades from XP to Vista and runs our app, data files in the c:program filesappname will be vitualised the 1st time they are written to. All well and good. Then the user disables UAC and suddenly his new data (entered since the upgrade) has disappeared! Panic! He calls support and is forced to enable UAC again. This is very unsatisfactory.
  
  When he installs the new Vista-compatible version of our app which tries to copy his data to a new c:users<appname>AppDataAppname, how does the installation program know which files to copy to the new location: those in the program files folder (if UAC is off) or those in the VirtualStore folder (if UAC is on)?
  
  My comments are based on testing with Vista Beta 2.

• Anonymous
  September 29, 2006
  Sorry, should be:
  
  ...tries to copy his data to a new c:users<username>AppDataAppname,...

• Anonymous
  September 30, 2006
  I see that RC1 has, I believe, stopped users from being able to switch UAC off? If so, that is a step in the right direction.
  
  However, there is still a problem when the user installs the new Vista-compatible version of our app (over an earlier version existing in the pre-Vista upgrade OS) which tries to copy his data to a new c:users<username>AppData<Appname> folder. How does the installation program know which files to copy to the new location: those in the program files folder (not accessed since the Vista upgrade), or those in the VirtualStore folder (accessed since the upgrade)? Still, this is a much lesser problem than that pertaining to Beta 2!
  

• Anonymous
  October 11, 2006
  Also regarding virtualization: MS docs have stated that adding a manifest to an .exe will disable virtualization, and I have indeed seen this work.  However, there seem to be exceptions, or at least one.  When I run a control panel applet, even though rundll32.exe, which the cpl is running in the context of, is marked with a manifest (with stated authority of "asInvoker" in its trustinfo section), virtualization remains enabled!  :-(  Since this is an exception, I'd guess that this is by design.  Why this exception?  This complicates things for us.  Are there other exceptions?

• Anonymous
  October 13, 2006
  PingBack from http://blog.not-a-kernel-guy.com/2006/10/13/84