A Specified Logon Session does not Exist - KB

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)

2.  Check the Robot/Studio version.

Must be greater than:

https://www.uipath.com/release-notes/uipath-v2016.2.6655
https://www.uipath.com/release-notes/uipath-v2017.1.6656
https://www.uipath.com/release-notes/uipath-v2018.1.3

3.  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

4.  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

5.  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)

6.  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)

7.  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: https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/audit-logon and Logoffs: https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/audit-logoff


8. 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, we can 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 link for more details about CredSSP related issues 


9. Make sure sufficient connection slots exist:

  1. Run gpedit.msc 
  2. Verify the Policy: 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 <Unknown> in our case there is an open console session SessionID: 6

The list of statuses can be found here (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 here. 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.
     

10. Network Level Authentication should be disabled if CREDSSP is not configured. Note that Force clients was not supported in versions 18.3 and below.
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.

11. Check the following registry keys:

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

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

12. 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

Solutions:

  • 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). Link
  • Upgrade to 18.4 which uses credential provider

13. Terminal Server Security Layer set to RDP seems to fail with other policy combinations

Solution: 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).