Project Dependencies for EXE Installations

Observed Behavior

The Robot is unable to download or run processes created in Studio v2019.2 or lower which have dependencies on the Official or Go! feeds, and not found locally or on Orchestrator.

Cause

When Studio is deployed through the UiPathStudioSetup.exe (usually the Community Edition setup) installer, the User Mode Robot is installed. As such, the Robot is only able to download and install project dependencies if they are found locally or on the Orchestrator instance it is connected to.

Solution A

All project dependencies need to be manually downloaded from the Official feed and uploaded to the Orchestrator instance it is connected to.

Solution B

Enable the Official feed from Studio and restart the Robot Service (UiPath.Service.UserHost). Open the Robot Tray or Agent Desktop and start the process from there. The corresponding dependencies are now properly downloaded.

Robot Fails to Start Execution

Observed Behavior

In this scenario, the Robot fails to start execution of a process, and throws the following error:

Executor start process failed, reason System.Runtime.InteropServices.COMException: A specified logon session does not exist. It may already have been terminated.

Cause A

The Robot machine does not have enough available resources (such as CPU, RAM, or Disk Space), so the Robot Executor is unable to start a process.

Solution A

Check or perform the following:

• The Robot machine has enough resources (such as CPU, RAM, or Disk Space).
• The connection time using the mstsc command-line function. It needs to be greater than 60 seconds, otherwise the error is displayed.

Cause B

The logon session cannot be created at the moment. This can happen in the following situations:

• Login to Console is set to true for HD Robots. In this case, the Robot Service attaches to the current Console Session. This is not recommended for HD Robots, because there can only be one active Console Session at a time.
• Multiple RDP sessions on Windows Workstation versions (not Servers). Windows Workstation versions can only handle one RDP session at a time per machine, whereas Windows Server versions can handle multiple RDP sessions.

Solution B

In this case, you need to perform one of the following:

• Set Login to Console to false. This means that the Robot Service initiates an RDP connection from the Robot machine onto itself and attaches to it. This is the recommended method for HD Robots.
• Check the Windows version, it needs to be Windows Server. Read more about Setting up Windows Server for HD Robots.
• Check if the Studio/Robot version you are using is greater than 2018.1.3, which fixed an issue caused by the KB4088876 (Windows 8.1 or Windows Server 2012 R2 Standard), KB4088875 (Windows Server 2008 R2 SP1, Windows 7 SP1), KB4088787 (Windows Server 2016, Windows 10 Version 1607), and KB4088776 (Windows 10 version 1709) Windows updates. Read more about Software Requirements.
• Increase the UiPath_Session_Timeout environment variable on your server. The default value is 30 seconds, which might be insufficient due to slow performance on some machines. Please note that the Robot Service needs to be restarted after modifying this variable.
• Check if your Remote Desktop License is active on the server. You can find out more on this page.
• Check if the Robots are in the right groups. Local users need to be in the same Remote Desktop group.
• Check if the username of your RDP connection to the Robot machine is not different than the configured one. To avoid this error, sign off all the RDP connections on the Robot machine.

Password Not Provided

Observed Behavior

Creating a Robot in Orchestrator without filling in the password field makes it unable to start process execution. Changes made to privileges on the Robot machine can also trigger this issue.

Starting a process from Orchestrator or the Robot Tray or Agent Desktop displays the following error message:

Executor start process failed, reason System.UnauthorizedAccessException: Access is denied.

Cause A

The Robot was created without a password.

Solution A

Edit the Robot as explained here and make sure the following fields are properly filled in:

• Domain\Username - The username used to connect to the machine on which the Robot is installed. If the user is under a domain, you are required to also specify it in a DOMAIN\UserName format. Use the Whoami command in the Command Prompt to easily find it.
• Password - The machine’s Windows password. Not required for Attended Robots.

Cause B

The Service Mode Robot is not running. Find out more about Robot deployment types.

Solution B

Make sure the Robot Service is running:

1. Click the Windows Start button, then search for and open Services.msc. The Services window is displayed.
2. Find the UiPath Robot service and double-click it. The UiPath Robot Properties panel is displayed.
3. From the Log On tab, select the Local System account option.
4. Click the Apply button and close the window to confirm the changes. This ensures the Robot Service is running and has all the privileges it needs for executing processes.

Cause C

The Robot machine no longer has administrator privileges.

Solution C

Log in to the Robot machine with the same set of credentials with which you created the Robot in Orchestrator. If a process fails to start from the Robot Tray or Agent Desktop, then you need to contact your network administrator to allow admin rights for that user account.

No Connection to the Robot Service

Observed Behavior

In some situations, you are not able to start the process execution. This can happen whether or not the Robot Service is running.

Starting a process from Orchestrator or the Robot Tray or Agent Desktop displays the following error message:

Get settings from service failed, reason System.Exception: Could not connect to UiPath Robot Service.

Cause A

The Robot Service is not running.

Solution A

In this case, you need to manually start the Robot Service, as follows:

1. Click the Windows Start button, then search for Services.msc and open it. The Services window is displayed.
2. Find the UiPath Robot service and right-click it. The context menu is displayed.
3. Click Start to activate the Robot Service. This makes the Robot Service start at Windows logon.

If these steps need to be repeated every time the Robot machine starts, then you need to increase the services timeout value in Windows, as explained below.

Cause B

The Robot Service takes too long to start.

Solution B

Windows reports services which do not load in a specified time. By default, this timeout value is 30 seconds, which can be insufficient for the Robot Service. To increase this value, you need to:

1. Open the Windows Registry Editor.
2. Navigate to the
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
   registry key, and select the Control subkey.
3. If the ServicesPipeTimeout value is NOT available, then create it as follows:
   3.1. Right-click the Control subkey, and select DWORD (32-bit) Value from the New menu. A new blank DWORD Value is created.
   3.2. Type ServicesPipeTimeout as the name of the new value.
4. Double-click the ServicesPipeTimeout DWORD Value. The Edit DWORD (32-bit) Value window is displayed.
5. From the Base section, select the Decimal option.
6. In the Value data: field, type in 180000. This makes the default ServicesPipeTimeout 3 minutes. It should be enough time for all Windows services to properly load.
7. Close the Windows Registry Editor and restart the computer for the changes to take effect.

Cause C

The Robot machine has incorrect permissions. In this case, the Robot Service might also appear as running.

Solution C

Permissions to services are granted from the Windows Registry Editor, as follows:

1. Open the Windows Registry Editor.
2. Navigate to the
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet registry key.
3. Right-click the Control subkey, and click on Permissions. The Permissions for Control window is displayed.
4. Select the user under which you are logged in from the Group or user names section.
5. Enable the Allow option for Full Control in the Permissions section. This grants the necessary permissions to the Robot.
6. Click Apply and OK to confirm the changes and close the window.
7. Restart the computer for the changes to take effect.

In case you are restricted from making the changes above, please contact your network administrator.

Robot Fails to Download Package

Observed Behavior

Robot fails to download a new package version if the %UserProfile%\.nuget\Packages folder already contains a package version with the corresponding project .nupkg file in it and one without it.

Cause

This issue occurs in a particular scenario:

• Have Studio/Robot v2019.4 or later installed. Download and run a package from Orchestrator. The package is installed in the %UserProfile%\.nuget\Packages folder and contains the corresponding .nupkg file.
• Uninstall the current version of Studio/Robot.
• Install a Studio/Robot version lower than 2019.4. Download and run the previous package from Orchestrator. The previous package is not removed, and the new one does not contain the corresponding .nupkg file.
• Upgrade Studio/Robot to v2019.4 or later. Downloading the package again fails with the following error:

The Robot fails to download the package because of the missing .nupkg file corresponding to the project.

Solution

Delete the previously installed packages from the %UserProfile%\.nuget\Packages folder and download it again.

Session is not Disconnected

After a workflow started by the Launch Workflow Interactive activity is executed, the session is not disconnected. This occurs if the Robot is running on a VDI environment, and the LoginToConsole and KeepSessionConnected options are enabled. Please note that, starting with v2018.2, the Launch Workflow Interactive activity has been deprecated.