A Specified Logon Session Does Not Exist - KB

News Knowledge Base
1

How to troubleshoot if a Robot execution is failing with the following error: " A specified logon session does not exist. It may already have been terminated. "

Executor start process failed, reason System.Runtime.InteropServices.COMException
(0x80070520): A specified logon session does not exist. It may already have been terminated. (Exception from HRESULT: 0x80070520)\r\n " ?

There can be different cause of the issue. Please follow the below options:

  1. Check the Operating system

In case of a Windows SERVER 2016 VM on a Citrix environment we will receive this error when user is Inactive (disconnected) and Robot is connecting using RDP. (Disconnected ICA - WIP)

  1. Check the Robot / Studio version

Must be greater than 2016, 2017, 2018.3 versions

  1. Check UIPATH_SESSION_TIMEOUT

The default timeout to wait for creating windows user session is 30 seconds. On some machines this time is insufficient due to slow performance (slow connections, policies applying from domains are slow, updates, other logon scripts).

The UIPATH_SESSION_TIMEOUT environment variable should be defined on Windows system environment variables and represent the seconds to wait for a user session.
If is not defined, default timeout (30 seconds) will be used. After setting the UIPATH_SESSION_TIMEOUT environment variable the UiRobot service needs to be restarted.


To set environment variables follow the steps below:

  • In Windows, open Run and execute: SystemPropertiesAdvanced

  • Click on Environment Variables


  • In the System variables section add new variable
  • Restart the UiRobot SVC

  1. Check Remote Desktop License

Make sure that the Remote Desktop License on the server is activated. More details here.

**Note:** To check if this license is enabled go to: Server management and see if the remote desktop services role is installed

  1. Check users (Robot users) are in the right groups

Local users should be in the remote desktop group (or in admin group). Domain users can be also added to the remote desktop group on the machine (or pushed using a group policy object)

  1. Check Server resources:

When the error is displayed randomly (sometimes it works sometimes it doesn’t), make sure that the Robot machine has enough resources (e.g. CPU, memory)

  1. Check Username used to connect to Robot machine:

This error also occurs when one is connected over RDP/Console to a Robot machine with a different username (e.g. a Robot has the X - admin and currently we are connected over RDP with the Y username). To avoid this error, sign out all the RDP connections on the Robot machine.
To validate logins check Audit Logons and Logoffs .

  1. If Login to Console is FALSE , check the Encryption Oracle Remediation policy is set to Mitigated if the Robot version is less than 18.4:
  • Open CMD as admin and navigate to the folder where UiPath is installed.
  • Run command UiRobot.exe --enableLowLevel
  • Replicate the issue
  • Run command UiRobot.exe --disableLowLevel
  • It will generate an etl file on desktop. Also, check the error in Application logs of Event-viewer.
Check if the etl logs contain the following:
rdp.cpp 34 RdpWrapper: Connect: Connection failed
rdp.cpp 34 RdpWrapper: Log on Wrapper: exiting connection loop, err(rdp):-1073741537


This issue has been fixed in UiPath version 18.4 and higher.

If one can not upgrade, then below workaround can be used:

  1. Run gpedit.msc
  2. Edit the Policy: Encryption Oracle Remediation under Computer Configuration > Administrative Templates > System > Credentials Delegation
  3. Set it to Mitigated
  4. Open an elevated cmd
  5. Run gpupdate /force

Refer to following Cred SSP Encryption Oracle Remediation for more details about CredSSP related issues

  1. Make sure sufficient connection slots exist:
  • Run gpedit.msc
  • Verify the Policy:
    • Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connections: Limit number of connections
    • Windows 10: Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connections: Limit number of connections

To verify the number of existing RDP sessions, examine the .etl generated by enabling the same using the following command uirobot.exe --enablelowlevel


The DumpSessionsInfo will provide with a count of open sessions at the time of the attempt:

SessionID 1 will be open by the service for arbitration (determine if there are available resources and connections)
SessionID 0 is the services session which will always have a status of 4 - WTSDisconnected
SessionID 65536 is the RDP-Tcp session listner and should always have a status of 6 - WTSListen

Depending on the circumstances, have a console session that should be Active and if no user is connected it will display with the Username in our case there is an open console session SessionID: 6

The list of statuses contain (enum. from 0 - WTSActive).

Disconnect reasons can be seen in the following EventViewer Log:
EventViewer (Local) > Application and Services Logs > Microsoft > Windows > TerminalServices-LocalSessionManager > Operational

The disconnect reasons and hex values can be found RDS Session Host Server Disconnect Codes . Decimal values and corresponding errors can be found below.

  • 0 No additional information is available.
  • 1 An application initiated the disconnection.
  • 2 An application logged off the client.
  • 3 The server has disconnected the client because the client has been idle for a period of time longer than the designated time-out period.
  • 4 The server has disconnected the client because the client has exceeded the period designated for connection.
  • 5 The client's connection was replaced by another connection.
  • 6 No memory is available.
  • 7 The server denied the connection.
  • 8 The server denied the connection for security reasons.
  • 9 The server denied the connection for security reasons.
  • 10 Fresh credentials are required.
  • 11 User activity has initiated the disconnect.
  • 12 The user logged off, disconnecting the session.
  • 256 Internal licensing error.
  • 257 No license server was available.
  • 258 No valid software license was available.
  • 259 The remote computer received a licensing message that was not valid.
  • 260 The hardware ID does not match the one designated on the software license.
  • 261 Client license error.
  • 262 Network problems occurred during the licensing protocol.
  • 263 The client ended the licensing protocol prematurely.
  • 264 A licensing message was encrypted incorrectly.
  • 265 The local computer's client access license could not be upgraded or renewed.
  • 266 The remote computer is not licensed to accept remote connections.
  • 267 An access denied error was received while creating a registry key for the license store.
  • 768 Invalid credentials were encountered.
  1. Network Level Authentication should be disabled if CREDSSP is not configured.
Check the etl logs for below meesages: 
rdp.cpp 34 RdpWrapper: Connect: Connection failed
rdp.cpp 34 RdpWrapper: Log on Wrapper: exiting connection loop, err(rdp):-1073741537

  • Run gpedit.msc
  • Verify the Policy: Computer COnfiguration\Administrative Template\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Securit
  • Double click on Require user authentication for remote connections by using Network Level Authentication
  • Set it to Disabled.
  1. Check the following registry keys:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
fPromptForPassword 1 (TRUE)
fInheritAutoLogon 0 (FALSE)

Prompt for password can also be here: SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\fPromptForPassword. If its defined here, that could mean a group policy is enforcing this. The Group Policy should be disabled.

This will require authentication to happen twice, which is not supported.
Solution : Set fPromptForPassword to 0 and fInheritAutoLogon to 1.

  1. Autologon with non-securely stored password not supported

If autologon password is set up using the following deprecated method, console logins might not work:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultPassword

Resolutions:

  • Disable autologon (delete DefaultPassword, DefaultUserName, AutoAdminLogon)
  • Use the newer method to store the password: delete DefaultPassword, use netplwiz.cpl to configure Autologon (which stores the password in LSA private store). Read How to Setup Auto Login in Windows
  • Upgrade to 18.4 which uses credential provider
  1. Terminal Server Security Layer set to RDP seems to fail with other policy combinations

Resolution: Set the SecurityLayer REG_DWORD under Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp to 2 (TLS)
This is actually more secure than using RDP (Value 0).

  1. For newer versions 19.10 and up Network Level Authentication is a requirement:

In order for RDP sessions to work correctly the following policy needs to be enabledComputer Configuration – Administrative Templates — Windows Components — Remote Desktop Services — Remote Desktop Session Host. — Security — “Require user authentication for remote connections by using Network Level Authentication” .



1 Like
2

Hello! We have another case where the same issue occurs and the reason is different.
Our configuration:

  • the robot machine is a terminal server
  • RDP protocol disabled for the users by security policy
  • RD Web is configured on the terminal server and in the RD Web the RDP is referenced back to itself.
    In this scenario a Remote App is executed by the client on the terminal server. The remote app on the terminal server starts an RDP session to itself.
    Thus when a user connects there are 2 RDP sessions displayed in the Task Manager for the same user. When the user logs off, only one session is closed and the other remains in disconnected state.
    Consecutively when an RPA process is started from Orchestrator, it fails with the same error, as it sees a disconnected RDP session and cannot connect to it.

The solution in this case is to have separate server for the RD Web access, thus the session on the terminal server will be closed normally and the disconnected session will remain on the separate server.