Vista's UAC - why it screws things up

[Yovaneth]

This is an extract from a much longer piece. I wrote it to explain why it is necessary to run one of our company products (a testing tool called SilkTest) with UAC turned off, but it does give an insight into why it successfully screws up a lot of 'legacy' installations.

 

 

An overview of Vista's User Account Control (UAC) and how it affects SilkTest

 

When a user logs on to Vista as an administrator the system issues two 'tokens' which define the user's privileges. One is an administrator token with full access rights and the other is a standard user with limited rights. When an application is run, it automatically runs as a standard user unless it has been specifically promoted to the full token by user intervention. This intervention is called 'elevation'.

 

The standard token has several restrictions; two of them directly affect SilkTest in that the Windows folder and the HKEY_LOCAL_MACHINE section of the Registry are set to read-only.

 

When you need to launch an elevated process, Vista prompts you for consent by displaying the UAC dialog. It is not possible to get SilkTest to interact with the UAC dialog because the dialog is run in a different desktop, called the 'secure desktop'.

 

UAC has the dual problem of providing security while also allowing backwards compatibility. The compatibility feature is called 'virtualisation' and it automatically kicks in when an application that is running at standard level tries to do something declared as illegal by Vista (such as writing to the Windows folder). The result here is that the application thinks that the write has succeeded when in fact it never took place. Windows redirects the write to an area called the virtual store; in a default setup the virtual store is located within the user's home directory at

 

c:\users\appdata\local\ virtualstore

 

There is also a virtual registry located on the same path which works in the same way. The virtual store/registry is per-user and is only used by applications that are not elevated and not Vista-aware. If SilkTest is run at standard level and a given test e.g. requires to write to HKLM, the write action will start virtualisation and SilkTest will declare the test as 'passed' when inspection of the Registry shows that it has quite obviously failed.

--------

 

There's a whole load more chopped out but I think this gives you the basics of why.

 

-Y-