Executor start process failed; **A specified logon session does not exist. It may already have been terminated**

Dear UiPath Users,

I am experiencing a problem where scheduled jobs are failing to start. Sometimes, but not all the time, I see an error when a scheduled job begins:

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

I find that I can immediately restart the job and it will run fine. This is not ideal, especially when the jobs are set to run very early in the morning.

Here is a snippet from the robot’s settings file.

“LoginToConsole”: true,
“ResolutionWidth”: 0,
“ResolutionHeight”: 0,
“ResolutionDepth”: 0,
“ConnectionString”: “”

Here is how the robot is configured in the orchestrator:

Is this a matter of orchestrator timing out before a session can be established? Do you think that I need to increase the time out like this:

I appreciate any guidance you can provide.


1 Like

If I look at the event log of the robot during the time of this failure I see that the there is an event “The Desktop Window Manager has registered the session port”, then I see the login errors on the robot about 60 seconds later (UIPATH_SESSION_TIMEOUT = 60).

So, it seems the orchestrator is making contact, but perhaps the VDI failed to start the session?

Was it working before? There was a Windows Update that caused this but I believe an update to Studio fixed it. Either that or suppress/uninstall the Windows Update.

Also, change “logontoconsole” to “false”.
If it is true then only one robot can run on that machine at a time.

@ClaytonM Thanks for your response.

I can’t say if it was working before. This is our initial roll out of unattended bots. I was aware of the Windows update issue and the subsequent patch (2018.1.3). As a result all our robots were upgraded to 2018.1.3 and our Orchestrator is 2018.1.3 as well.

It is interesting that you mention setting log into console as false. I’ve seen that advice frequently on the forums here. However, from what I’ve gleaned from the documentation and forums, login to console should be false when your robot is running on a high density server where you can have multiple logins with different IDs. In our case, all the robots are Windows 10 VDIs so there is only ever one robot installed.

Is it still recommended to set log to console = false in settings files for a single robot VDI? Also, does setting the console value for the robot in the orchestrator make a difference? Should it also be false?


To this point,
If it is set to true, then it uses the console which only allows 1 connection. By that, I mean you will receive “resource is in use” error when you try to run a Job on a 2nd robot while a job is currently running on another robot (on the same machine). By “robot”, I mean the userid+machine combination that you use to run a job in Orchestrator.

If you only have 1 userid being used on a machine to run jobs, then it won’t affect anything and it can be true.

I hope I am clear. Regards.

Yes, @ClaytonM you your advice is clear, thank you.

I’m afraid our issue persists, but is intermittent. I notice it occurs when a VDI has been idle for a long period of time, say a day or two. I don’t see it on robots that have a job to run every day. I’ve set the UIPATH_SESSION_TIMEOUT to 120 seconds but that doesn’t seem to help.

For now, I am going to schedule a second attempt of the job (a quick asset update) as a “just in case”. But that feels like a hack. I can’t shake the feeling that this is some problem with the VDIs we have provisioned as robots.


When it happens, do you notice if no user accounts have an open session that says disconnected, meaning they logged completely off? Occasionally, Windows or IT will roll out patches which reboot the machine, logging everyone off. I seem to think there was another setting that needed to be changed, but for the life of me, I can’t remember. You might need to consult UiPath support here: Contact Technical Support

1 Like

We are having the same issue. Still troubleshooting to see what it is causing it.

We’ve tried to be very cautious of having open sessions to the robots. I don’t think that is the issue. But I also don’t think this is a UiPath issue either. I mentioned if you re-run the same process on the same robot within minutes the robot runs just fine, as though the VDI was slow to respond in creating the session. I did engage support and got the standard advice regarding “log on to console” etc. And I couldn’t reproduce the problem on demand, so we just let it go. Hopefully it works better with more performant VDIs.

Yeah. Recently, in my team’s case, we have had to deal with IT rolling out faulty patches. So we had to consult to our server admins to uninstall or remove the patch from their cycle. Apparently, updating the UiPath fixes the “logon session” issues also, but that’s another issue cause IT gets delayed on rolling those upgrades out.

Add Robot UserID in Robot machine - Computer Management - “Remote Desktop users”, if you missed to add it while installing Robot.

This is probably already common knowledge but just to add that I experienced this same issue about logon session not existing after a Windows Server update (KB4493473) on the Robot (UIPath 18.4.5).

My issue was a lot easier to resolve though - logging into the robot with an interactive session fixed it. I assume that the reset after the update caused it to be not responsive.

Hi @cclements, I am facing similar issue. Were you able to identify possible reason for this?

@Rocki_Jan @cclements
Case 1: Please try to sign out of VDI or RDP. Try not to close the RDP session directly by disconnecting. This makes the VM to hold the sessions. The robot throws the error: “A specified logon session does not exist. It may already have been terminated”.

Case 2: If you are using 2 robot licenses on a single VM, and trying to run a process 2 through user 2 robot, while a process 1 through user 1 is already running, then the user 2 robot throws the same error.


Interesting post. But I have been able to track this error a few times. I have some processes that run after the end of another process, but for some reason, after a process is finished and Orchestrator starts another one, immediately this error is returned. So from your comment, I understand that even if you get the message in Orchestrator that the process has finished, it doesn’t mean that the machine is still ready to receive another process.

I looked for some alternatives to get around this error, but here on the forum, I never found anything that made sense. Do you know if there is a Timeout that can be turned on for each process start, because I am believing that after the robot sends the success message to Orchestrator the machine is still disconnecting when the other process tries to start.

I use version 2021.4.0 and this error is recurrent, I don’t know what else to do to get it.