- Release Notes
- Getting Started
- UiPath Assistant
- Installation and Upgrade
- Robot Types
- Robot Components
- Licensing
- Connecting Robots to Orchestrator
- Processes and Activities
- Logging
- Robot JavaScript SDK
- Specific Scenarios
- Restarting Robot Components
- Windows Sessions
- Login Using Thales Luna Credential System
- Login Using NShield Key Storage Provider
- Redirecting Robots Through a Proxy Server
- Executing Tasks in a Minimized RDP Window
- Using Mapped Network Drives
- Stopping a Process
- Disable Stop Button
- Custom Package Folders and Network Paths
- CrowdStrike Integration
- Robot Citrix Apps Virtualization
- Troubleshooting
- Unresponsive Robot Over RDP
- Duplicate Execution Logs
- Frequently Encountered Robot Errors
- Increased Process Execution Duration
- Enforced Package Signature Verification
- Message Too Large to Process
- Errors When Running as Administrator
- NuGet Packages Not Accessible After Migration
- User Access Control Prompt and UI Automation Activities
- .NET required during installation
- Assembly Cannot Be Loaded From Network Or Azure File Share
- Activities cannot find .NET Runtime
Frequently Encountered Robot Errors
In this section you can find more details about the most frequently encountered robot errors and how to resolve them.
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
UiPathStudioSetup.exe
(usually the
Community Edition setup) installer, the Robot is installed in User Mode. 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
UiPath.Service.UserHost
). Open the UiPath® Assistant and start the
process from there. The corresponding dependencies are now properly downloaded.
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 Standalone Windows versions (not Servers). Standalone Windows 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
system environment variable on your server. The default value is 60 seconds, which might be insufficient due to slow performance on some machines. Please note that the environment variable is set in Seconds and 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.
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 from the UiPath® Assistant 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 theWhoami
command in the Command Prompt to easily find it. - Password - The machine’s Windows password. Not required for Attended Robots.
Cause B
The SCM-managed Robot Service is not running. Find out more about Robot deployment types.
Solution B
Make sure the Robot Service is running:
- Click the Windows Start button, then
search for and open
Services.msc
. The Services window is displayed. - Find the UiPath® Robot service and double-click it. The UiPath® Robot Properties panel is displayed.
- From the Log On tab, select the Local System account option.
- 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 UiPath® Assistant, then you need to contact your network administrator to allow admin rights for that user account.
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 from the UiPath® Assistant 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:
- Click the Windows Start button, then
search for
Services.msc
and open it. The Services window is displayed. - Find the UiPath® Robot service and right-click it. The context menu is displayed.
- 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:
- Open the Windows Registry Editor.
- Navigate to the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
registry key, and select theControl
subkey. - If the
ServicesPipeTimeout
value is NOT available, then create it as follows:- Right-click the
Control
subkey, and select DWORD (32-bit) Value from the New menu. A new blank DWORD Value is created. - Type ServicesPipeTimeout as the name of the new value.
- Right-click the
- Double-click the
ServicesPipeTimeout
DWORD Value. The Edit DWORD (32-bit) Value window is displayed. - From the Base section, select the Decimal option.
- 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. - 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:
- Open the Windows Registry Editor.
- Navigate to
the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
registry key. - Right-click the
Control
subkey, and click on Permissions. The Permissions for Control window is displayed. - Select the user under which you are logged in from the Group or user names section.
- Enable the Allow option for Full Control in the Permissions section. This grants the necessary permissions to the Robot.
- Click Apply and OK to confirm the changes and close the window.
- Restart the computer for the changes to take effect.
In case you are restricted from making the changes above, please contact your network administrator.
Observed Behavior
%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:
.nupkg
file corresponding to the project.
Solution
%UserProfile%\.nuget\Packages
folder and download it again.
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.
Observed Behavior
When using a Data Table in the "Wait For Task and Resume" returns the following error: "Exception: Type 'System.Collections.IEnumerable' cannot be serialized."
Cause
DataRow is not serializable, so it is not able to serialize DataRows while persisting the workflow. This can also be seen if we create a DataRow variable and try to wait (persist) after that.
Solution
Execute “Create Form Task” activity and build a list of task object(output) while looping through DataRows(System.Data.DataRow).
After that, we can loop through the list of task object(output) using “Parallel For Each” or “For Each” and execute “Wait for Task and Resume”.