Automation fails with "Cannot communicate with the browser embedded in application" after the target application updates

News Knowledge Base
1

After the target application receives an update, a UI automation that works with a browser embedded inside a desktop application stops working, even though the automation itself has not been changed. UI Automation activities are unable to attach to the embedded browser, and HTML selectors that worked previously no longer resolve. Other automations running on the same machine are not affected.

Issue Description

Some applications display web content inside a native window by using an embedded browser engine such as WebView2, Electron, or JxBrowser. UiPath automates this content using HTML attribute-based selectors when the project setting UI Automation Classic > Browser > Enable WebView2 Native Automation is set to True.

Embedded browser engines are updated often. When the target application updates the Chromium, WebView2, or Electron build it embeds, the signatures UiPath relies on to detect the embedded browser become outdated, and the robot is no longer able to attach to the web content inside the window.

Starting with UiPath.UIAutomation.Activities v24.10, this detection logic is provided through a separate package, UiPath.AppSignatures, which overrides the Chromium Native signatures included in the UI Automation driver. If a project never installs or updates this package, it continues to use the signatures that shipped with the driver. As a result, an update to the target application can break the automation even when nothing in the workflow has changed.

A typical timeline looks like this: the automation runs successfully for months, the target application is updated, and the automation then fails at the first step that interacts with embedded web content, which is often a login screen.

Note: an error with similar wording, Cannot communicate with the browser, please check the UiPath extension, refers to a different issue involving the external browser extension and its native messaging host. That error relates to Chrome or Edge running as a separate application and is not covered by this article. The key distinguishing text is embedded in application, which indicates a browser rendered inside another application's window.

Please refer to the following docs:

Symptoms

The following error appears in the job logs and names the host application that contains the embedded browser:

Cannot communicate with the browser embedded in application '<application>.exe'

When the issue is reproduced, a second error appears at the step that opens the application:

Could not open target application

Additional behavior you may observe:

  • Errors occur at Workflow level and repeat across successive retry attempts within a Retry Scope.
  • Once the retries are exhausted, a fatal System exception follows at initialization.
  • The job may report a final status of Successful while queue items remain unprocessed. This happens because the retry logic catches the failure and the run ends without completing its workload, so the job status alone does not reveal the problem.
  • The failure can be reproduced on the affected machine in both attended runs from Studio and unattended runs.
  • Other automations on the same machine continue to run correctly, including automations that target the same application as a window rather than as a website.
  • UI Explorer generates wnd selectors for the embedded content instead of HTML selectors.

Resolution

We recommend updating the UiPath.AppSignatures package before rebuilding selectors or reworking the automation. Rebuilding selectors takes considerable effort and does not resolve outdated signatures.

  1. Open the affected project in UiPath Studio.
  2. Go to Design > Manage Packages > All Packages.
  3. Search for UiPath.AppSignatures.
  4. Select the latest available version, click 'Install', then click 'Save'.
  5. Publish the project and deploy the new version to the robot.
  6. Re-run the automation and confirm the step that previously failed now completes.

UiPath.AppSignatures is updated independently of UiPath.UIAutomation.Activities. Updating it does not require any workflow changes or a full regression test of the automation. It does require UiPath.UIAutomation.Activities v24.10.6 or higher.

AppSignatures currently supports Chromium Native and WebView2 Native signatures (WebView2, JxBrowser, Electron). It does not support CefSharp, WebView2 C#, or NWBC C# managed signatures. If the target application's embedded browser uses one of those technologies, this resolution does not apply.

For automations that run through Remote Runtime over RDP, the package also needs to be deployed to the Remote Runtime host:

  1. Extract the contents of AppSignatures* from the build folder inside the .nupkg file.
  2. Copy them to C:\Program Files (x86)\UiPath\RemoteRuntime\packages\uipath.appsignatures\<version> on the remote host.

If the error continues after the package has been updated and the project republished, outdated signatures are not the cause. Please continue troubleshooting with the following checks:

  • Confirm UI Automation Classic > Browser > Enable WebView2 Native Automation is set to True in Project Settings.
  • Confirm the embedded browser technology used by the target application is one of the supported types listed above.
  • Compare the failing scope against a working automation that targets the same application, noting whether each targets the application as a website or as a window.

Root Cause

The robot machine is using an outdated UiPath.AppSignatures package. This package provides up to date signatures for embedded browsers such as WebView2, JxBrowser, and Electron, and overrides the Chromium Native signatures in the UI Automation driver. When the signatures are outdated, the embedded browser cannot be detected, so the robot is unable to attach to the web content and HTML selectors do not resolve.

When a target application update breaks embedded browser HTML selectors, updating AppSignatures on its own resolves the issue, with no UI Automation package upgrade and no workflow changes needed. Before the v24.10 decoupling, this same type of failure required a full UiPath.UIAutomation.Activities upgrade.

See: About the AppSignatures package

How to verify:

  1. Check whether the project references UiPath.AppSignatures at all, and at what version.
  2. Establish whether the target application updated shortly before the automation began failing.
  3. Open UI Explorer against the embedded content. A wnd-only selector tree, where HTML attributes were previously available, indicates the embedded browser is not being detected.
  4. Install or update the package, republish, and re-run the exact step that failed.

Other causes worth ruling out first include: target-application DOM changes breaking HTML selectors; browser extension startup delay; browser extension allowlist and native messaging host misconfiguration; target application path/argument drift; a mismatch between browser-mode and app-mode scope configuration.