25-03-23 01:15 AM
Hi All,
From long back iam facing the issue internal:Error:could not identify process owing the current foreground window. I see this error coming up in Activate & focus stages of the application .The application which iam using is running in IE enabled mode of edge .The windows were spied using win32 mode where the Activate stage is used and the elements are spied in AA Mode &UIA Mode where focus stage is used
FYI-IE Html mode is not working to identify the elements of application.
only one user logins to the VM as so many answers for this issue says that multiple users logins to same VM causes the issue.
cant we use frequent Activate & focus stages in the same screen which causes the foreground
please help me in finding the correct resolution for the issue.
Thanks in Advance.
25-03-23 02:34 AM
Hi Mahesh
Normally this type error will also occur if the screen gets locked so ensure that screen is not locked while running the bot
Is it happening while running in attended mode i.e. from process studio?
Then check the window you are spying as you referred as the IE compatible so check the window you spied is outermost window element
Hope this helps
Regards
25-03-23 06:13 AM
Hi Narayana,
Thanks for your reply
We see this error while bot is running in unattended mode and also previously the entire window was not spied using win32 mode so i have spied entire outer window using win32 mode still we are facing the same issue.
In unattended mode i guess screen wont lock right?
Thanks
Mahesh.
25-03-23 06:45 AM
Hi Mahesh
Their is possibility of screen getting locked and more detail Please refer to the different threads available
Going through these you may get better idea what could be the reason and solution
Regards
25-03-23 03:44 PM
Hello mahesh reddy : First Idea would be to narrow down the search - to identify where exactly you have these foreground issues - reach out to your RPA Support/Control Room Team - Tell them to enable the full logs for a day or few runs, if its set by default to Errors only for prod. Try extracting the logs from control room.
Once you have an Idea which part of the process/applications stages are getting hampered due to these foreground issues - ensure right standards are being followed while interacting with those target application from activating and focusing, dynamic wait stages point of view.
Second Idea would be to have the monitoring placed for a single run : If your team does have access to control room virtual box where you can see the process running inside prod VM that would essentially narrow down your options on where and when exactly this error is getting encountered. VMSphere, Bomgar are few tools people use to see the production runs, if they have to - enquire if you team has similar set up.
More on these could be found here : https://portal.blueprism.com/system/files/2017-11/v6%20Data%20Sheet%20-%20Remote%20Access%20Tools.pdf
For all the possibilities associated with this error refer support centre knowledge base : https://portal.blueprism.com/customer-support/support-center#/path/Automation-Design/Studio/Process-Design/1137420332/Why-do-I-get-error-Could-not-identify-process-owning-the-current-foreground-window...
------------------------------
Kindly up vote this as "Best Answer" if it adds value or resolves your query in anyway possible, happy to help.
Regards,
Mukesh Kumar - Senior Automation Developer
NHS England, United Kingdom, GB
------------------------------
04-04-23 08:42 PM
Mahesh,
I would agree with others, both in this thread and across the BP Communities, that this is almost certainly related to a screen-lock situation. The 'nice' thing is that you can sketch up a real quick check for it, using actions from the Login Agent object. You can check the screen-lock status, and, if locked, clear the lock. The only external requirement, so to speak, would be the password of the credential signed into the Runtime/Resource (necessary to unlock the screen).
By default, all of our Runtimes are supposed to have the screen-lock option deactivated, but I have documented instances where specific machines screen-lock inspite of the expectations.
If you want, I can screenshot the snippet I built to address this same issue, but there is really nothing to it.
Good luck,
Red
10-04-23 03:10 PM
It's great to see the BP Communities coming together to provide helpful solutions to technical issues. The proposed solution of checking the screen-lock status and clearing the lock using actions from the Login Agent object is a practical approach that can be easily implemented. It's important to document and address any unexpected behavior, such as screen-lock activation, to ensure smooth operation of the runtime.