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

robot

#1

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.

Chris


#2

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?



#3

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.


#4

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


#5

@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?

Chris


#6

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.


#7

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.

Chris


#8

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: https://www.uipath.com/contact-technical-and-activations


#9

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


#10

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.


#11

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.


#12

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