26-03-24 09:11 AM
Hi all.
Our production environment is struggling with error message "Could not identify process owning the current foreground window" when trying to bring an application to the foreground. This used to be something that occured every once in a while and was usually fixed by retries, but the last week or two it has become a big problem and is now affecting multiple processes, causing these to fail. No significant changes have been made to the environment, that I am aware of.
I have gone trough this article: BPE error "Could not identify process owning the current foreground window" when trying to focus an application
This is exactly what is happening, but I am unable to find the cause.
I have gone through the windows policies in the Login Agent User Guide and all policies are correct.
The issue only occurs when running on the runtime resource, not when I manually run it.
Our process template takes a screen shot if a system exception occurs. However, the screenshot fails every time this error occurs with the error message "No access".
There is only the one robot logged in to the runtime resource at any time.
When I log in to the production machine to troubleshoot, reboot it or make any changes to the affected processes, the processes seem to run ok for the rest of the day, but the error then comes back the next day. All runtime resources are rebooted every night at 3 AM.
I have tried changing the process objects involved to application mode Foreground after coming across this same problem in one of the RPA forums, and as mentioned above the processes all ran ok for the rest of the day, but this morning they started failing again.
The article says: "Often such a transfer is blocked by Windows User Access Control (UAC) or the Integrity Level (IL) with which the application has been launched, preventing the current application from running under the present logged-in user context to get access to the foregrounded application. " Is there anything I can do to check if UAC or IL is the cause? I am unfamiliar with this and not sure what to do.
I am at my wits end and sincerely hope you can help us solve this.
26-03-24 03:12 PM
Hello,
I Would check few things here. At present what stage Automation is throwing this exception like focusing the button or text box? or activating the application...
Identify the stage having the issue
Check any other alternative to overcome this issue
If the issue is moving the process to the foreground you can try C#code to move the process to the foreground
Below stackoverflow some code reference:
https://stackoverflow.com/questions/2636721/bring-another-processes-window-to-foreground-when-it-has-showintaskbar-false
26-03-24 03:20 PM
Since it is happening all the automation, there might be some common code or similar code is used across all the automation, So I would suggest add the screenshot and check the Vm status(To verify it is locked) before the stage where this error is happening.
Also check with the team who manages the VM and see any updates are pushed to the VM or Windows.
30-03-24 10:24 AM
This is usually the case of certain Group Policy Objects having a forced update at a scheduled time.
Sadly, each organisation IT policies are different, so I'm afraid the only ones able to pinpoint which policies are causing it would be your domain admins.
One other way to solve it (albeit not a surefire one) is to demise the virtual machine and spin up a new one in its place.
I have found that sometimes this solves the problem.
Lastly, there is the option of trying to run on a physical resource and see if it happens there as well.
If so, then it means the group policy causing it is domain-wide, and as such should be easier to find.
Have you tried looking through the windows event logs to find any events that might be causing this?