I have a Windows VM with a desktop application on it. I want to write an agent which will interact with this application through UI automation (via WinAppDriver). The agent should start with the machine and require as little human intervention as possible to do its job.
It's easy enough to get this working by adding it to startup programs (shell:startup), but this requires someone logging into the VM every time it is restarted. Is it possible to run such a program as a Windows Service? Keep in mind it would have to launch a Win32 app and interact with it via UI automation. Could this be done by running it as Local System account and enabling "Allow service to interact with desktop"? Or would it need to run as a specific user account?
No, it is because Windows Service runs in background and to access the UI the process should run foreground.
Related
I have a rather difficult to manage Windows closed-source Windows GUI application. It's messy (leaves files all over the place) and has a convoluted installation process.
It has been proposed that we containerize the application, but can this be done?
For UNIX applications there's an easy pattern - just give the app access to the port of the X11 server, and allow the app to write to that, but is there a Windows equivalent? Is there any way at all to containerize a Windows application but allow it to generate windows in the host Operating System's desktop?
If this is possible, are there any handy recipes to get started with this?
Currently, It's not possible to containerized Windows GUI application on a windows host.
From the blog Insider preview: Windows container image
Lars Iwer [MSFT] writes in the comments below the article:
"In the container image as it is right now, GUI elements will be rendered in session 0. UI automation should work with that (e.g. programmatically searching for a window etc.)."
So according to my understanding, you can run GUI apps but the rendered elements are not shown on any desktop which will only work for UI automation work but not for user interactive application.
Session 0:
Session 0 is reserved exclusively for services and other non-interactive user applications. Users
who are logged on to Windows and their user applications must run in Session 1 or higher.
- User interfaces in Session 0 are not supported. Processes running in Session 0 have no access to the graphics hardware thus user interfaces cannot be directly displayed on the monitor.
I have a Windows Service that automatically starts another WPF application ( from an .exe file)- I know this is not a good practice, however that is a requirement I got.
I am able now to start a UI application via Windows Service. This works fine on my local computer; I can see a UI and the application is running correctly. The application is running under the "SYSTEM" user as seen from the Windows Task Manager.
The problem only occurs when I move the code to our production computer, which is Windows Server 2012, and the account I use is given by our IT department (and it should have admin rights). After running the service, the application is running successfully; I can see it from the Task Manager. However, I cannot see the UI even though it is still running under "SYSTEM" account.
What sort of role or permission does a user need to see the UI application (or just an application in general) running under "SYSTEM" account?
I have a Unity3D application (a simple .exe) that I'm trying to automate with PowerShell DSC. However, it seems that Unity3D cannot acquire a GPU when started as a Service or background Process, which breaks my application. When started manually via double-clicking the .exe, things work fine.
Is there a way to force DSC to show a GUI when starting a Service or Process?
Thanks!
DSC doesn't currently support interactive applications during the configuration. I can think of two solutions:
Ensure that the user is logging on
The user logs on already for whatever reason
Setup the user to auto-logon during the config (and be sure to set DSC to reboot.)
Auto Logon setup KB
Ensure the app runs when the user logs on:
Setup a scheduled task to start the app when the user logs on
Schedule Task cmdlet reference
atLogon trigger reference
The app is set in the registry to run when the user logs on
I'm trying to run UI-tests (written using white). When I run them using NUnitConsole everything works fine. When I try to run them using TeamCity I get the following exception Test(s) failed. White.Core.UIItems.UIActionException : Couldn't find window with title Form1 in process 4132, after waiting for 5000 ms. What might be wrong? What could I do to make the test pass?
Not only does the build agent need to be set to interact with the desktop, but the desktop must be displayed in order for UI automation to work - desktop cannot be locked and screen saver must not be running. Is your agent on a headless machine? If you are using RDP to connect to the agent to check on things, when you close RDP, it locks the desktop. In this case, the automation will fail. Instead of using RDP, use a VNC viewer to log on to the box, rather than RDP, as VNC will not lock the desktop when you close it.
Another issue to consider is network access. If you are running TC agent as a service with access to desktop, then it will be running under service account which will not have access to network shares, etc... If this is a probelm, then you will not be able to run TC agent as a service, and will instead need to logon with a domain user and kick off the agent.bat file to start the agent.
Spent a lot of time solving this issue.
Main steps:
You need separate computer with teamcity build agend installed on it. Computer should have monitor and mouse.
The agent SHOULD NOT be launched and run as a Windows service (disable it if needed).
You should launch TeamCity build agent from .bat file (as administrator). To do this go to TeamCityBuildAgentfolder\bin and launch agent.bat file with start argument
Disable computer's screen sleep/lock after certain period of time. Your tests will require desktop for UI manipulations.
If you done everything right you should be able to see your build agent active in TeamCity's "Agents" menu.
You can also automate TeamCity agent launch (at selected user's logon):
Automate user's logon. More instructions here
Create task in Task Scheduler which will launch build agent at user's logon with administrative rights (with highest privileges)
Make sure that the user who will logon automatically has all neccessary permissions (run the scripts, perform file operations etc.)
IMPORTANT!
Running UI tests in such way is a potential security hole so make sure that the non-authorized people have no acccess to computer that runs this tests.
Remember that for running your UI test the computer SHOULD NOT be locked or be in sleep mode.
You probably have to make the Teamcity build agent interact with desktop.
Run -> services.msc -> Select TeamCity Build agent and right click -> Properties -> Log On tab -> Check "Allow service to interact with desktop"
Edit:
If that doesn't work, stop the agent service, go to Build Agent folder ( c:\teamcity\buildagent\bin ? ) and issue agent.bat start and then trigger the tests.
There is recommendation to run the UI tests on virtual machines.
Seems as most reliable solution.
Does anyone have a good guide to capabilities of Windows Services under XP? In particular, I am trying to find out what happens when a program being run as a service tries to open windows, but hasn't been given permission to interact with the desktop.
Basically, I have a program that is/was a GUI application, that should be able to run as a service for long term background processing. Rewriting the program to not display the GUI elements when doing background processing is a major effort, so I'd like to see if there is just a way to ignore the UI elements. It is sort of working now, as long as too many windows aren't opened. I'm trying to figure out what limits I might be running into. Ideally, there would be an MSDN page that discusses this, but I've had no luck finding one yet.
Generally, services should be designed to not have any visible UI. The entire point of a service is to run in the background, without UI, unattended. (Think SQL Server, IIS, etc.)
In most scenarios, a separate application controls the service's operation, should a GUI be needed. (Continuing the samples I just mentioned, SQL Server Management Studio, IIS Manager, etc.) These separate applications configure and manipulate the service (and occasionally, if needed, bounce said service).
If your service requires occasional UI, and said UI can't be isolated to a control app, then you probably should reconsider the fact that you're using a service to begin with. Perhaps a UI application which resides in the system notification area is the right pattern to use? (E.G., Windows Live Communicator.)
A service in Microsoft Windows is a program that runs whenever the computer is running the operating system. It does not require a user to be logged on. Services are needed to perform user-independent tasks such as directory replication, process monitoring, or services to other machines on a network, such as support for the Internet HTTP protocol
Usually it is implemented as a console application that runs in the background and performs tasks that don't require user interaction.
The installed services can be configured through the Services applet, available from
Control Panel --> Administrative Tools in Windows 2000/XP.
Services can be configured to start automatically when operating system starts, so you dont have to start each of them manually after a system reboot.
Creating a Simple Service - MSDN Article
Writing Windows Services Made easy - Code Project Article
Five Steps to Writing Windows Services in C - DevX Article
If you should be thinking of eventually migrating to a newer OS such as Vista or Server 2008, you will find that you cannot give a service permission to interact with the desktop at all. Therefore, from the point of view of forwards compatibility, you should design your service to not require it.
A service in Windows XP can interact with the Desktop if its "Allow Service to Interact with Desktop" property (MMC -> service properties -> Log On tab) is checked. It is also possible to do so by doing the following:
hWinstation = OpenWindowStation("winsta0", FALSE, MAXIMUM_ALLOWED);
SetProcessWindowStation(hWinstation);
hDesktop = OpenDesktop("default", 0, FALSE, MAXIMUM_ALLOWED);
SetThreadDesktop(hDesk);
But be aware that presenting UI from a service process in Windows XP will almost always lead to a security problem (see Shatter attack). You should try to break out the UI part of your application from the service.
Usually the service won't have permission to write to the window station and desktop, so it will fail; even running applications that load user32.dll can fail simply because user32 has initialization code that wants to talk to the window station and can't get access to it unless the service is running as an administrator.