Community
Participate
Working Groups
On Windows Vista (and reportedly also on Windows 2003 server), when the agent controller is installed as a service, processes that are launched by the agent controller are unable to create UI on the desktop, even if the service checkbox ("Allow service to interact with desktop") is checked. You can verify this problem by trying to run a manual test with an AC service on windows (the UI never appears, and the launched test hangs, waiting for the user to complete the test in the UI that they can't see.) Some simple googling reveals that this change was a deliberate security hardening, and that services in Vista are completely prohibited from interacting with a logged on user's desktop session. All services run in session 0, and interactive user logons never run in session 0, so the "desktop" that a service can access (if the checkbox is checked) is never one that is visible to a logged on user. This implies that we need to come up with a replacement strategy for simple agent controller launch on Vista (perhaps eliminating the service and replacing it with doc on adding the ACServer a startup/logon script in windows as we do in all other OS?) http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=896322&SiteID=1 http://www.derkeiler.com/Mailing-Lists/securityfocus/focus-ms/2006-08/msg00019.html There doesn't appear to be a component that represents the windows service portion of the agent controller, so please feel free to move/reassign this defect as appropriate.
Is something needed in 4.2.2 to address this, or do we release note this along with the other Vista limitations? Is there no testing on Windows 2003 Server that would have shown if the problem exists there?
I don't believe this should block the 4.2.2 "Vista tolerance" release. I think we can release note it, but we need to investigate and plan a better solution moving forward. Windows 2003 Server (EM64T and IPF) are supported platforms for the Agent Controller, but are not supported platforms for the Manual Test View (which is the only part of TPTP itself that fails on 2003 Server & Vista.) However, the implicit contract we provide to consumers of the AC API is clearly different for Vista & 2003 Server when it comes to AC as a service and agent invoked UI. The use cases are quite different in reality. In many cases (2003 Server, especially), it's not expected that a user sits in front of the machine at all -- it's a backend server that we'd like to use to do testing, but user interaction is not expected. For Vista, on the other hand, we expect to have users in front of some types of Vista boxes, and the use cases that expect user interaction with agent initiated UI are much more valid.
Created attachment 57366 [details] Screen capture When running a manual test via the Agent Controller running as a service, the user is presented with this dialog despite allowing the service to interact with the desktop (see <Agent Controller service> >> Properties >> Log On). The user can only close the dialog and the test execution run indefinitely.
(In reply to comment #1) This defect should follow the same path as 170572 for 4.2.2/4.3.1 (e.g. readme note).
Please set target field. Thanks.
4.2.2 readme
Updates made to 4.2.2 and 4.3.1 readmes
Although this defect requires a readme entry for the short-term, we need to provide a fix since this defect is blocking Manual Test function. As such, reopening.
Note that we can't "fix" the defect as described in the current headline ("Agent Controller as a windows service on Vista can not create UI"), because Vista explicitly prohibits this functionality. For a long term solution, we can discuss other alternatives, but I don't see an obvious solution. Some possibilities include: 1) Removing the windows service and instead providing only the functionality that we provide on other operating systems (requiring users to manually set up the Agent Controller to run automatically on a given machine at *login time*) [Note: not *startup time*] Note that prior to this Vista restriction, there were already problems with the AC service spawning UI in other windows versions. For example, if the machine was running, but no one was logged in. Also if fast user switching was enabled in XP and multiple users were logged in, or if multiple users were logged in via remote desktop on one of the server OS's. I am open to other suggestions.
*** Bug 171687 has been marked as a duplicate of this bug. ***
(In reply to comment #9) Although removing the Agent Controller service support would solve this problem, I think this is useful function that is used in consuming products. I can be convinced to live with a readme entry documenting this limitation and the work-around. I would like to see further investigation when time permits. For example, why are the symptoms seen when "Allow service to interact with desktop" is checked.
Igor, would you please see if we can fix this problem? In the meantime, I have added the readme entry
I agree that we should consider how to address the usability issue caused by this. However, I don't think we should spend any more time investigating the cause of the issue itself -- the links in comment #0 explain in technical detail that this functionality is simply no longer possible from a service in Vista. https://bugs.eclipse.org/bugs/show_bug.cgi?id=171416#c0 In response to the comment "Yes, we NEED an option to allow Service to interact with desktop!!!", this response explains the rationale for removing the capability in Vista: > No you don't. Error messages of the service belong into the Application event log. > Communication with an app in an interactive session should be done through normal IPC, i.e. sockets, pipes, COM, Remoting. > As multiples sessions are running because of terminal services or remote desktop > connections there is no one to one relationship between a service and an interactive > window station with one desktop. You can have one per interactive session. >Which one should the service talk to? What if nobody looks at any desktop of the machine > your service runs on - nobody notices that messagebox or whatever UI stuff. > Relying on that "feature" is just not adequate anymore. Get rid of it, there will be no alternative. An option to consider moving forward will need to involve a process that is launched from an interactive session. One could imagine registering something to run as an auto-run login process (via startup group, or one of the many registry keys that allow processes to launch automatically.) We could have a windows native binary launcher that is built to not show a console window, and we'd end up with a similar user experience to what we have today, except that the AC wouldn't start on a machine until someone logged in. That difference is a step backwards for AC uses that don't require UI, but a correction for those that do (because today they'll crash and burn if no one is logged in yet.) We'll also have to deal with multiple simultaneous logins to the same machine in a server environment (which will be a larger problem.) This goes to the core issue of the Vista change -- if we run a service on a machine with more than one active desktop, which one should be used...
The current implementation of the new Agent Controller uses a "TPTPProcessController" agent for launching applications. If we can somehow have the "TPTPProcessController" agent started from a normal user login session, then any launch request will be using the same desktop as the "TPTPProcessController" agent. This can be done either by starting this agent manually, or (ideally) started as a user-service (not Local System Account) which can interact with the desktop. Currently this agent is started automatically with the AC. I am not sure if we can workaround this problem by changing the "Log on as" property of the AC service to use a normal user account rather than "Local System Account".
On my Vista system I installed the AC as a service started by "Local System Account". I tried to run the manual test client and an "Interactive service dialog detection" dialog popped up for permission to show the manual test client UI. After I clicked "Show me the message" the UI appeared and I can complete the manual test.
Relying on this mechanism doesn't really solve the problem for several reasons. First, it requires user intervention on the (possibly remote) machine. That seems okay for manual test, but fails for AutoUI, and for several consuming products that need to run things remotely in an automated fashion. Also, the support you describe is already deprecated, and the detail section of the notification window says that "This problem happens because of partial incompatibility with Windows Vista. Please contact the program or device manufacturer for more information." Lastly, accepting the "show me this message" prompt doesn't actually allow the UI to be displayed in the user login window station. Instead, it fast switches to the (otherwise blank) desktop of winsta0 until the service initiated window is dismissed, which is a undesirable user experience. This document at microsoft.com describes suggested ways to address this issue. Perhaps we can use CreateProcessAsUser to launch the ProcessController in the user's window station, though it's not immediately clear to me how we'd determine which user to launch as. http://www.microsoft.com/whdc/system/vista/services.mspx
I have thought of the "CreateProcessAsUser()" approach before but the only possible way of knowing which user to launch as is to enable security where user ID and password have to be entered. If Windows can provide an API to query the session which a user has logged into, then we might be able to get the Windows station associated with that user and set that in the STARTUPINFO structure parameter when calling "CreateProcessAsUser()".
I am starting to think that this is not a Windows Vista specific problem. Consider these scenarios: Scenario 1: Windows XP 1. Logon as Administrator 2. Install AC as a service and start AC 3. Logoff the current user 4. From another machine launch manual test client or AGR remotely using the AC above Scenario 2: Linux 1. Logon as root 2. Install AC as a system service (rc5, inetd, cron, etc.) 3. Logoff 4. From another machine launch manual test client or AGR remotely using the AC above Scenario 1 resembles the behaviour we are seeing on Vista. There is no desktop associated to Session 0. Scenario 2 also exhibits a similar behaviour where there has to be some user action required to enable desktop interaction (e.g. export DISPLAY=...) Therefore I think the solution (if any) has to be common between Windows and Linux.
Since we don't have a proper design for now I would like to move this bug out of 4.4.
Reassigning to the newly created WindowsService component.
Hi Bing. I have transferred my bugs to you for triage. Thanks.
In TPTP 4.5, the Manual Test type was moved from a General Availability (GA) component to an As-Is component. As-Is components are primarily provided for prior users but imply no support (for example, defects, news group, and mailing lists) or commitment to triage or resolve opened defects. As such, the Test Project no longer requires this defect. Joe, is there a consuming product that requires this defect? If not, can you please return this defect as WONTFIX.
(In reply to comment #22) > In TPTP 4.5, the Manual Test type was moved from a General Availability (GA) > component to an As-Is component. As-Is components are primarily provided for > prior users but imply no support (for example, defects, news group, and mailing > lists) or commitment to triage or resolve opened defects. As such, the Test > Project no longer requires this defect. > > Joe, is there a consuming product that requires this defect? If not, can you > please return this defect as WONTFIX. > This is still a valid defect despite that the Manual Test type was moved from a General Availability (GA) component to an As-Is component. There have been several users impacted by this defect when trying to launch/profile an application with an UI when running the Agent Controller as a service.
(In reply to comment #23) > This is still a valid defect despite that the Manual Test type was moved from a > General Availability (GA) component to an As-Is component. +1 There are also several consuming products that are affected by this problem.
Mass update of P1 enhancements and defects targetted to future to P2.
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. Since this defect is more than 2 years old, it may be no longer relevant. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this defect is resolved as WONTFIX. If this defect is still relevant and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
Reopening since still relevant. Kathy, please triage.
