Blue Prism UI Automation Failing after Chrome / Edge Update to 140

[Adrian__Dones]

Hi guys,

Hope all of you are well and have a great week start.

Starting from last week (around Wednesday~Thursday) Blue Prism fails while running to identify properly the fields spied using UI Automation mode.

While trying to check in Application Modeler if the fields can still be visible, they were successfully identified, but while running the whole process, somehow the process remains blocked while trying to access those fields.

The interesting part is that after re-spying the fields using UI-Automation (just to test if a new fresh set of fields would make the cut) the bot still fails.

Just to mention, the process worked properly without any errors more than 2 years and all of a sudden it failed to work anymore.

Please let me know if this is a general issue and/or how it can be fixed.

Much appreciated all your help 🙂

[Neel1]

hello @jordan.harvey.norfolkcc  - Had a look at your snip,
You can remove --force-renderer-accessibility=complete - This was fix suggested for only Chrome/Edge version 117.

[Adrian__Dones]

Hi Jordan,

Unfortunately, for my case this workaround doesn't have:

Please let me know if I'm missing something 

Many thanks for the help

[jordan.harvey.norfolkcc]

You have it in your path too for some reason, double check the parameters in both the app model and also the launch action itself just in case you have accidentally entered something into the wrong box.

[Federico.Tobares]

Hi community,

We’d like to share that we’re also experiencing the same issue reported by others regarding element identification using the UIA method. The problem is reproducible in both development and production environments, and we believe it’s related to the recent Chrome update to version 140.x.

The most critical impact is that the DWorker remains in a waiting state without throwing an error, which forces us to manually terminate the affected process(es). This causes delays and affects the continuity of our production workflows.

As a temporary workaround, we’re rolling back the Chrome version to mitigate the issue. However, since we work with the GCP suite, this rollback introduces additional challenges.

We’re sharing this just for community awareness, to confirm that we’re facing the same situation. Hopefully, a patch or permanent fix will be released soon.

[Adrian__Dones]

Hi Jordan,

Many thanks for all your help. Works properly now 🙂

[david.l.morris]

Okay, the proposed Chrome/Edge launch/startup param --disable-features=UiaProvider works for us. I'll explain what we've found so far which lines up with what others have already said. So, I am not saying anything new here. Just confirming some things.

How to add the Chrome/Edge launch param

Let's say our app URL is this:

https://google.com/a-fake-url/for/screenshot

Then you append " --disable-features=UiaProvider" to the end like this:

https://google.com/a-fake-url/for/screenshot --disable-features=UiaProvider

So, if you made your URL have that flag/param in it just like above, then you could append further params like this which is an excessive example using all the flags together though I usually only use some of these:

https://google.com/a-fake-url/for/screenshot --disable-features=UiaProvider --remote-debugging-port=9222 --force-renderer-accessibility --start-maximized --inprivate

You do not need all of those. I'm just giving an example of having a bunch of them and that you need a space between each.

This can be a bit confusing, especially if you're not used to adding launch params. I'll show a few example screenshots below, but note that I am saying only one of these is necessary to do. It just depends on how you handle your automations and URLs.

1. Screenshot - Appending to a URL in an environment variable

This assumes that you are using an environment variable and it is directly used in the object, and then the second screenshot shows using the environment variable directly in the Navigate stage that launches Chrome/Edge. I don't do this very often unless there for sure will never be multiple environments of the target app to be used in the same Blue Prism environment.

2. Screenshot - Appending to a URL directly in Application Modeller

This is something you may want to do when just doing development. But also if you don't provide a URL to the navigate stage when launching, then it will use the value that is provided in the command-line parameters blank in Application Modeller.

3. Screenshot - Appending to a URL in the Launch action of an object

This scenario assumes that you have an input url parameter for your Launch action in an object. This would allow the process to pass in the URL it wants to use. This is super common for us because sometimes the same object needs to interact with different app environments in the same Blue Prism environment. We then also (or will) have an input for [Disable UiaProvider]. This will then be either an environment variable or a config param that is configurable in Production without a code change and is specific to the automation. This will allow us to turn it on or off per automation. Not everyone needs this, but it's an option.

And then the launch stage would look like this.

Sometimes need to re-spy elements

Sometimes attributes will have changed. I don't know the full details here about why or when they would change. I also don't know if they will change back in March 2026 or whenever this disabling feature flag no longer works. So, this may just be a temporary solution just like the flag itself. Not sure.

Example screenshots of an example we found that elements had to be re-spied. Screenshots provided by @SzymonWitek on our team. Thanks, Szymon! Note that the After screenshot below doesn't necessarily imply we will leave the Parent UIA Class Name selected but is just to show the change in attribute values.

Before:

After:

Not all RPA teams are allowed to control MS Edge updates

First, we (so far) are not allowed to delay MS Edge updates, especially when a given update includes security patch, which they frequently do. We are also not allowed to revert even though with admin access to a given machine, you could do that. Several people have rightly suggested that we need to implement control over Edge update timing. While this is absolutely a valid suggestion and it is absolutely right, many organizations simply will not allow this, no matter what it breaks. Blame whoever if you want, but some RPA teams simply cannot do anything about this. Now, I will say that this UIA issue will likely help multiple organizations have the proof for why we need to be able to control Edge updates. We plan to try using this scenario as motivation for getting control over Edge updates just like we have control over machine patching, which we didn't always have in the past.