NOTICE: Our Community is moving. Get more information.
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 (not even by using Typekeys()) 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. If a subsequent action in the test requires SilkTest to read what it has just written, it will return incorrect information at this point because the read accesses the real Registry which has not been changed. If you step through in debug mode and the registry write action appears to have succeeded but a subsequent read of the same key returns incorrect information, you can be sure that you have triggered the virtualisation. For the majority of tests SilkTest will quite happily run at standard level. For a large percentage of tests that have failed because they have triggered Vista"s virtualisation feature, running Silktest as elevated will fix this. However, to avoid any problems with the standard token, elevation and virtualisation, it is recommended that SilkTest is always run with an administrator login. If you have a test that passes on WindowsXP and fails on Vista, please ensure that SilkTest is running as an administrator on Vista before logging a case with Borland Technical Support. We currently do not support SilkTest running in standard or elevated mode.