topic Could not identify process owning the current foreground window in Product Forum

Could not identify process owning the current foreground window

Tetiana_shkavro — Mon, 31 Jul 2017 13:56:00 GMT

Hello! We have tuned process that successfully running on Windows Server 2012 RDP Session. Session is always on on server. This process starts by scheduler and there are some independent sequent interactions with few applications (PUTTY, IBM® WebSphere and Internet Explorer). So, when the process runs in active RDP session it finishes successfully. It also starts and finishes successfully in minimized session window. But when we disconnect RDP session, wait process to start and finish and then login into session again, interactions with some apps have been failed. The process fails with the message: "Could not identify process owning the current foreground window". This concerns most of all to interactions where we use €œGlobal sent keys€ actions. For example operations with Internet Explorer where we use Read and Write stages are finished fine. What could be the reason of this issue?

RDP is an unsuitable

John__Carter — Mon, 31 Jul 2017 14:13:00 GMT

RDP is an unsuitable virtualisation technology and is specifically not recommended. https://portal.blueprism.com/system/files/product/productpublic/4.2/Blu… The reason for your error is that the desktop UI is destroyed when the RDP connection is closed. This does not stop the remote machine (or BP) from working, but any activity that requires the desktop UI, such as mouse clicks, keystrokes, activate or screenshots (ie surface automation) will not work. So if you have a process that does none of these things, it will work fine. The confusing thing is that when you reconnect RDP, the desktop is re-established, everything seems normal, and it's hard to see what the problem was. As a test try running a process that captures a screenshot - the resulting image will be entirely black because the desktop is not there. In addition to it's inability to host a persistent desktop, RDP also does not offer much in the way of security or audit. One possible work around is to use Login Agent to get your machines logged in, and run your processes without watching via RDP. This 'lights out' operating is how it should be in Production anyway.

John, thanks a lot for your

Tetiana_shkavro — Mon, 31 Jul 2017 17:45:00 GMT

John, thanks a lot for your answer! We will try to follow your advice.

Hi,

Ravindersaini — Wed, 30 Aug 2017 00:21:00 GMT

Hi, I this resolved? If yes could you please share with us the solution. I have tried running through login agent,but i still get the foreground error. Regards, Ravinder Saini

Is there a good way to debug

coreydrees — Wed, 18 Oct 2017 18:59:00 GMT

Is there a good way to debug this with login agent?

create a batch script that

PravinBenjamin — Wed, 18 Oct 2017 23:16:00 GMT

create a batch script that launches power shell and takes a screen print of window add it scheduled task execute remotely also create a batch script to check to open powershell and check if workstation is locked or unlocked put the generated file in network share when robot is running.

Hi. Please share the…

LanAmaranto — Fri, 22 Dec 2017 08:41:00 GMT

Hi. Please share the solution for this issue. Thank you.

RE: RDP is an unsuitable

SumanthB — Wed, 25 Sep 2019 11:09:00 GMT

Hi John,

I have similar situation, I have configured the Login-Agent and it is working fine.
However, UI tasks are still getting failed in the server. Is there any workaround for this.
I have scheduled Login-Agent 5m before actual Bot Run.

Please advise.

------------------------------
Sumanth B
Developer

------------------------------