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 (61)

  1. Scotte says:

    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.

  2. Alex says:

    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.

  3. Dasher says:

    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?

  4. Dasher says:

    Something else that just popped into my head.  Does this work with the new InfoCards?

    Supposed I have 2 InfoCards – one for one low right account on my domain, and another for an Admin Account on my domain – does the UAC allow me to select one over the other?

  5. Scotte says:

    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

  6. Keeron says:

    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 :))

  7. David says:

    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.

  8. Are you curious to know what is new in the February CTP? Find out on the UAC Blog.

  9. Joseph says:

    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

  10. Mike S says:

    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?

  11. Joseph says:

    I’m a bit confused – how is this implementation of UAC any different than the Run As option in Windows XP? If the user wants to run the application and they are a standard user – they have to have an administrator’s password? doesn’t this defeat the whole security aspect?

    Scenario – User currently needs local admin privileges to run Quark Xpress on Windows XP. How does Vista change this? If they’re a standard user they still can’t run the program, if they’re an admin they can install any software they want so long as they click on the run as admin security box.

    I just want a way to say always run Quark Xpress as an administrator for a standard user, here’s the admin account and password to use for that user, and the standard user never sees any of that, but they can’t install Elf Bowling either.

  12. Rich says:

    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.

  13. Q says:

    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?

  14. Q says:

    In addition,

    -consider making the orange prompt red – its visually stronger! The grey prompt orange, and if the program has been run once before grey!

    -having a link to take the user to either an internet webpage (that can easily be updated) or a help page on the PC itself.

    The bottom line is that if the average user needs to be educated on security. If they were, half securities problems would be solved automatically!

  15. Peter says:

    I’m a developer struggling with updating a (partly dead) application to not fail in Vista — and I have a few words about File Virtualization and the horrible, awful state of the documentation.

    Most importantly, there isn’t any.  There are vague, useless, and incorrect statements like the ones in this blog: they give a hint as to what should happen, but when an actual Vista machines doesn’t work like that, there isn’t enough detail to be helpful.

    Secondly, what information that does exist is wrong.  For example, this very blog says:

    "For example, if an application attempts to write to “C:program filesappnamesettings.ini” and the user doesn’t have permissions to write to that directory, the write will get redirected to “C:UsersusernameAppDataLocalVirtualStoreProgram Filesappname.”

    And yet, the writer later say — whoops!  That that isn’t correct — that some writes will be denied entirely (.exe files, for example, will not be virtualized)

    The writer also says that read will be merged — the user will see both the "read" program files directory and the virtualized one.  However, this is directly contradicted by the statement and picture about the "Compatibility files" button.  If the reads are really merged, why wouldn’t we just see them?

    In fact, I have yet to see a single merged read actually work.  Windows explorer doesn’t merge; the Command box "dir" command doesn’t merge; notepad doesn’t merge.  

    So to summarize:

    [a] you need actual documentation

    [b] you need for the blog fluff to be correct

    Your truly,

    A disgruntled developer who hates Vista

  16. Alex says:

    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

  17. Peter says:

    Alex, (and all other blog writers)

    Here’s a hint on replying to people who hate your documentation: when replying, try to add to the knowledge of the complaining person.

    What I need to know is: under what conditions are writes redirected?  I do know that it will happen sometimes (because I see it); I also know that it does not happen other times (because you said so).  What I don’t know, and what you haven’t made any more clear, is under what conditions a write will be redirected and under what conditions a write will not be redirected.

    What I also need to know is under what conditions a read will be redirected.  If program "a" writes file "FILE.TXT", and several weeks and reboots later program "b" reads file "a", will program "b" read file "FILE.TXT"?  

    What if program "b" does a ‘stat’ on "FILE.TXT"?

    What if program "b" does a "dir" command on the directory?

    When will these reads be redirected?  When will they not be? What I know is that there is a claim that they "will" be redirected; what I observe is that no read that I have ever tried has ever been redirected.  

    What I don’t know, and what you haven’t made any more clear, is under what conditions a read will be redirected and under what conditions a write will not be redirected.

    Now forgive me if I’m wrong, but this is basic information about a basic operating system function.  Y’all have been working on this OS for years; it is pathetic that at this late date there isn’t even a hint of documentation on MSDN.

    Personally, I’m a little under the gun.  You may not be shipping Vista until near Christmas next year.  However, I need to not only ship with Vista — but I need to ship with Vista on OEM computers, and their deadlines are already coming up fast.  The more time I waste because every single piece of Microsoft information is wrong or misleading the more irritated I get.  

    You said that if I posted information about my app that someone might be able to help.  Well, what I need are answers to the questions I posted:  

    when will reads be redirected?

    when will writes be directed?

    and the other obvious questions that follow:

    is the redirection exactly and totally 100% on a per-login-id basis?  If not, what exactly it is based on?

    will all reads and all writes that are redirected be redirected to the same place?  

    how do I find it (or them)?    

    Peter

  18. Peter says:

    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

  19. Pavel Lebedinsky says:

    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>

  20. Simply, says:

    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!

  21. Peter says:

    Pavel

    Hmmm … so after a week of "we’ll have someone help" the only actual comment is, "don’t use virtualization" without a single answer to any question.  That’s not very helpful.

    The application in question is one that we’re trying to get rid of; every hour spent on it is an hour not spent on the new version which, FYI, I’m also working hard on working in Vista.

    My goal is to "fix" it by changing some application settings and not to recompile it.

    So: the ‘new’ code is nice and shiny clean; the ‘old’ code is what I need to fix.  I don’t want to recompile the old code if I can possibly help it (a full QA pass is about four months and takes six people; budgeted is one person for five days).  If only I had the answers to the questions posed, I might avoid all of that.

  22. John (Microsoft) says:

    Peter,

    Windows enables file and registry virtualization only for processes that meet the following criteria:

      1) The process token is for an interactive standard user.
      2) The executable is 32-bit (disabled by default for 64-bit processes).
      3) The executable does not specify a requestedExecutionLevel in its application manifest.

    Furthermore, we do not virtualize if the caller is impersonating or is from kernel mode. Virtualization is only for legacy application compatibility and we only virtualize when writes fail for access denied. If you specify any execution level in your application manifest, we disable virtualization for your processes. You should do this. Mark your runtime executables with asInvoker and your per-machine installer/updater executables with requireAdministrator. See the following link for details on how to do this (search for asInvoker):

        http://msdn.microsoft.com/library/en-us/dnlong/html/AccProtVista.asp

    Most system executables specify an execution level, disabling virtualization. This includes explorer.exe, cmd.exe, and notepad.exe. You will not see virtual files at all (merged view) in processes with virtualization disabled. The “Compatibility Files” link appears in Explorer windows if at least one virtual file exists for the user for that directory. Clicking the link simply redirects you to the corresponding virtual store directory.

    When we virtualize files, they are redirected to %LOCALAPPDATA%VirtualStore and are per user. File virtualization is only allowed in %SystemRoot% (%windir%), %ProgramFiles%, and %ProgramData% (coming later) with some subdirectories excluded. We do not virtualize files with certain name extensions including .exe, .dll, .sys and many others (long list). We also do not virtualize files that administrators cannot write to, which is true of most system files. We are still adjusting the inclusion/exclusion policy, and we will let you all know when we publish the final list.

    We enable registry virtualization only for the SOFTWARE hive. Each key has flags that can be set to control virtualization. Run “reg flags /?” for more information on the flags. We redirect virtual registry keys to the per-user classes hive (%LOCALAPPDATA%MicrosoftWindowsUsrClass.dat) under HKCUSoftwareClassesVirtualStore.

    We will post a future entry dedicated to file and registry virtualization.

    Thanks,
    John (Microsoft)

  23. John (Microsoft) says:

    Peter,

    Windows only enables file and registry virtualization for processes that meet the following criteria:

      1) The process token is for an interactive standard user.
      2) The executable is 32-bit (disabled by default for 64-bit processes).
      3) The executable does not specify a requestedExecutionLevel in its application manifest.

    Furthermore, we do not virtualize if the caller is impersonating or is from kernel mode. This technology is only for legacy application compatibility and we only virtualize when writes fail for access denied. If you specify any execution level in your application manifest, we disable virtualization for your processes. You should generally do this. Mark your runtime executables with asInvoker and your per-machine installer/updater executables with requireAdministrator. See the following link for details on how to do this (search for asInvoker):

        http://msdn.microsoft.com/library/en-us/dnlong/html/AccProtVista.asp

    Most system executables specify an execution level, disabling virtualization. This includes explorer.exe, cmd.exe, and notepad.exe. You will not see virtual files at all (merged view) in these processes. The “Compatibility Files” link appears in Explorer windows if at least one virtual file exists for the user for that directory. Clicking the button simply navigates to the corresponding virtual store directory.

    We store virtual files in %LOCALAPPDATA%VirtualStore in a structure mirroring the global namespace for the volume. Therefore, they are per user. File virtualization is only allowed in %SystemRoot% (%windir%), %ProgramFiles%, and %ProgramData% (coming later) with some subdirectories excluded. We do not virtualize files with certain name extensions including .exe, .dll, .sys and many others (long list) nor files that administrators cannot write to, which is true of most system files. We are still adjusting the inclusion/exclusion policy, and we will let you all know when we publish the final list.

    We enable registry virtualization only for the SOFTWARE hive. Each key has flags that can be set to control virtualization. Run “reg flags /?” for more information on the flags. We store virtual registry keys in the per-user classes hive (%LOCALAPPDATA%MicrosoftWindowsUsrClass.dat) under HKCUSoftwareClassesVirtualStore.

    We will post a future entry dedicated to file and registry virtualization.

    Thanks,
    John (Microsoft)

  24. John (Microsoft) says:

    Peter,

    Windows only enables file and registry virtualization for processes that meet the following criteria:

      1) The process token is for an interactive standard (non-admin) user.

      2) The executable is 32-bit (disabled by default for 64-bit processes).

      3) The executable does not specify a requestedExecutionLevel in its application manifest.

    Furthermore, we do not virtualize if the caller is impersonating or is from kernel mode. This technology is only for legacy application compatibility and we only virtualize when writes fail for access denied. If you specify any execution level in your application manifest, we disable virtualization for your processes. You should generally do this. Mark your runtime executables with asInvoker and your per-machine installer/updater executables with requireAdministrator. See the following link for details on how to do this (search for asInvoker):

        http://msdn.microsoft.com/library/en-us/dnlong/html/AccProtVista.asp

    Most system executables specify an execution level, disabling virtualization. This includes explorer.exe, cmd.exe, and notepad.exe. You will not see virtual files at all (merged view) in these processes. The “Compatibility Files” link appears in Explorer windows if at least one virtual file exists for the user for that directory. Clicking the button simply navigates to the corresponding virtual store directory.

    We store virtual files in %LOCALAPPDATA%VirtualStore in a hierarchy mirroring the global namespace for the volume. They are per user. File virtualization is only allowed in %SystemRoot% (%windir%), %ProgramFiles%, and %ProgramData% (coming later) with some subdirectories excluded. We do not virtualize files with certain name extensions such as .exe, .dll, .sys and many others (long list) nor files that admins cannot write to, which is true of most system files. We are still adjusting the inclusion/exclusion policy, and we will let you all know when we publish the final conditions.

    We enable registry virtualization only for the SOFTWARE hive. Each registry key has flags that can be set to control virtualization. Run “reg flags /?” for more information on the flags. We store virtual keys in the per-user classes hive (%LOCALAPPDATA%MicrosoftWindowsUsrClass.dat) under HKCUSoftwareClassesVirtualStore.

    We will post a future entry dedicated to file and registry virtualization.

    Thanks,

    John (Microsoft)

  25. Peter says:

    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

  26. Alex says:

    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

  27. John (Microsoft) says:

    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)

  28. Vlad says:

    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

  29. Peter says:

    Well, wouldn’t you know it — this is probably a dead topic, but if you scroll up, you’ll see a question posted by ‘Mike S’ about the Program Compatibility Assistant.  Now my program is triggering it and I really, really, really don’t want it too.

    Too bad there’s no (deleted) documentation.

    I’d like to re-ask the question that Mike S asked:

    Can you elaborate on what criteria Vista uses to trigger the Program Compatibility Assistant and automatically apply elevation requirement?

    And also ask two more:

    1. When the PCA runs, and it updates some settings — what exactly is it doing (with a view to rolling it back)

    2. Are there any actual areas of Vista that have documentation that extends beyond "here’s something new — it works".

    And some comments on the Program Compatibility Assistant:  why does it run when I double-click a program, and when I right-click a program and select ‘Open’, but not when I run ShellExecute or ShellExecuteEx on it?  Nor when I run it from the command line?  

    And one last question: how did you manage to make a distinction between the different ways of running a program, and how can I learn to do the same thing?

    Peter

  30. sathish (Microsoft) says:

    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)

  31. Roger says:

    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.

  32. 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.

  33. c says:

    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.

  34. Mike S says:

    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.

  35. rsclient says:

    Sathish,

    I would echo ‘Mike S’ and say ‘thanks for the additional information’, but you didn’t actually provide any.

    You say that the ‘PCA’ program only detects actual errors — but this is wrong.  The installers we make work perfectly every time; PCA itself is buggy.  Incorrect information is not ‘new information’ and simply detracts from my store of real information.

    You say that the ‘PCA’ program only runs in some cases — your exact words were ‘New instrumentation added into Shell enforces this’.   This is not new information; this is information that I told you.  I didn’t really need for you to tell it back to me.  What you could have added, but didn’t, was how I can force this ‘PCA’ to run outside the shell (for example: so I can automate my process).

    You said how the program adds in a registry: what you didn’t say was whether this is a guarantee ("we will not save any information anywhere but in this one spot") or just a lazy description of part of the PCA program.  As it stands, the only way I can know that I’ve gotten rid of all PCA traces — QA has this ‘thing’ about runing from a known good state — silly thing — is to reformat my drive and reinstall Vista.

    And a minor nit: you say "can be accessed by right clicking on an exe and selecting file properties".  This is not correct; it’s plain old "properties" and not "file properties".

    You say that there will be an ‘exclusion key’ in the ‘beta 2’ — but of course, there’s no documentation on it, nor do you say if a running program can add the key in itself.  The statement is therefore useless.

    Lastly you say, "we need better documentation".  Once again, this isn’t actually information: it’s something that I already knew and which I told you.  It doesn’t help me to simply get back information that I already know: I’m looking for new information.

    Peter

    PS — why no answer to ‘Mike S’.  He has the same issue I do: a program runs perfectly, but that (emphasis) PCA dialog comes up for no good reason.  His goal and mine are the same: we want our programs to run without any scary dialogs from Microsoft showing up.

  36. UACBlog says:

    Imagine stopping at a gas station to fuel up your car, selecting Standard grade unleaded gasoline, and…

  37. Sathish (Microsoft) says:

    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

  38. rsclient says:

    Sathish

    Please try to not answer questions with obvious fluff.  My response to your two items (using your numbering scheme) is:

    1. PCA is not run automatically.  Microsoft added code — which you are keeping secret — at least to the Explorer, and possibly to other programs.  That’s why it shows up when a user runs a program by double-clicking in an area that the Explorer has control, but not other places.

    For example, running a program via ShellExecute does NOT run the PCA, nor does typing in the command from a CMD.EXE prompt.  

    That’s why I wanted to know how to trigger PCA: because I want to automate my process.  I simply don’t want any repro steps to include human intervention.

    Now: is there a way to do this?  Your answer is no, but then you added extra (emphasis) that isn’t even correct.

    2. Thanks for the the registry entry, but it doesn’t answer my question: if *my program* adds this entry in *while its running* will the PCA not (emphasis) put up that awful dialog box?  Or does it have to be done ahead of time?

    Please try answering our actual questions — we have real issue here, not the pretend ones you are answering.

    (and as always: it seems that rude questions get answers, but polite ones do not)

  39. rsclient says:

    Ten days later, still no (emphasis) answers.

    It seems that "UAC" means that your fertilizer doesn’t smell — you say any damn stupid thing, and the moment you get asked any questions, just retreat into silence.

  40. Sathish (Microsoft) says:

    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

  41. Mike S says:

    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

  42. Thomas says:

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

  43. Rich Muller says:

    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.

  44. Thomas says:

    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

  45. Tony Karam says:

    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.

  46. @Tony Karam – that checkbox won’t happen.  It’s too open for abuse – just like SUID.  Does your app really need to run as admin on every startup?  Perhaps it should be a service instead.

  47. Loren Bland says:

    earlier Roger said:

    "If you want to add an application manifest to an older executable without re-building it at all use the mt.exe"

    I have an older app that I have tried to add a manifest to using this tool. I executed:

    mt.exe -manifest setup.exe.manifest -outputresource:setup.exe;1

    But when i try running the application I get an error saying the application failed to initialize (0xc0000005)

    am I using the tool wrong?

  48. UAC says:

    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

  49. Loren Bland says:

    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

  50. UAC says:

    Loren,

    Could you post the contents of the manifest file you are embedding that causes the error?

    – Peter

  51. Loren Bland says:

    <?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?

  52. UAC says:

    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.

  53. Loren Bland says:

    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

  54. Peter says:

    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

  55. Loren Bland says:

    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

  56. was says:

    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.

  57. was says:

    Sorry, should be:

    …tries to copy his data to a new c:users<username>AppDataAppname,…

  58. was says:

    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!

  59. Gordie says:

    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?

Skip to main content