Testing install procedure of a program requiring administrative privileges

Question

I'm trying to write automated test, to ensure that the installer for my program works okay.

The program can be installed for all users (requires admin privs), or for current user (does not require admin privs). The program can also autoupdate itself, which in some cases requires admin privileges, and in some cases doesn't.

I'm looking for a way where I can have an automated test click "Yes, Allow" on the UAC dialogs, so I can write tests for all different scenarios, on many different operating systems, so that I can be confident when I make changes to the installer that I didn't break anything.

Obviously, the installer process itself cannot do this. However, I control the complete machine, and could easily start some sort of daemon process with administrative rights, that the testprogram could make a socket connection to, to request it to "please click ok on the UAC now".

Answer 1

I actually figured out how to do this while looking to answer a similar question about UAC. Here is what you can do:

1. Write a service that runs as SYSTEM.
2. Open the process token of the winlogon.exe instance running in your logon session.
3. Use that token to launch a helper process on the Winlogon desktop via CreateProcessAsUser.

At this point, you have a helper process running as SYSTEM in your logon session on the Winlogon (secure) desktop. From here you can use some kind of IPC mechanism to communicate from your automated test program to the helper process. In the helper process you can EnumDesktopWindows to find the UAC prompt. This is as far as I took it; I didn't actually try to simulate clicking Yes or No, but I don't see any reason why it wouldn't work. Also, I only tested on Windows 7 32-bit; I believe the UAC architecture is identical to Vista, but I didn't test on it.

It took me a while to figure all this out; I can provide some code if you want.

EDIT: Just as a follow up I added code to use FindWindow() to find the "Yes" button and I was able to successfully send it a BM_CLICK message; the UAC prompt went away and the application was allowed to run.

Answer 2

An alternative solution might be to turn UAC off

Answer 3

The least bad solution I've found so far is to run the tests in a VMWare session, and control the mouse/keyboard trough the vmware sdk. Would love to hear about other solutions

Answer 4

Remote Desktop to it or run it as a guest VM (using Virtual PC or whatever, just don't boot to it.) This is also the best way to take a screenshot or video of the UAC prompt.