Running Job from Orchestrator on on RDP Windows Server (Login False) does not work - Activities never time out and job never goes to fault

Hello community.

Using the enterprise edition and an unattended robot.

Just as the subject says, this is something totally new to me.
Activities that should throw timeout error does not throw errors until at least 25 minutes have passed.
The job should go to fault but never does. The longest it has kept running for is 4 hours and that is when I turned it off.

The sessions start and manage to take some screenshots and put out a few log messages for control. Then it manages to at least execute a start process activity (the application starts to load, got screenshot proof).

After that. Nothing works. No matter what I do, the robot just freezes there. It will not go any further, it will not produce any more logs and it won’t crash when the timeout should be reached by the attach window activity. I tried to remove the attach window activity, still does not move pass this point.

When I eventually get fed up with waiting I try to kill the job to try again. But it will not work and it gives the error message

  • Could not start executor. A specified logon session does not exist. It may already have been terminated. (Exception from HRESULT: 0x80070520)

It will keep throwing this error until I try to log in to the RDP. When I do that, the screen is at first all black, then the login screen reaches the point when it shows the username and some white text flashes by underneath until it turns blue, showing an error message that says that someone else is probably logged in.

If I do not try to log in, the robot never leaves the session (waited for one hour, still logged in, would not start job from orchestrator, the scene described above happens every time).

Does anyone have any idea where I should look for answers?

And of course, it works perfectly when running it from the studio and when launching it from the orchestrator while being logged in to the RDP beforehand.


Hi there @johan.standeus

Seems like an interesting issue and thanks for the detailed account of the same.

Seems like you are using a ‘Start Process’ ? Is that for an Invoke VBA or Launching an application?

Also in both the cases if the error/exception handling in the VBA hasn’t been done properly then such an issue might occur. If it is an application that you are starting why dont you try Launch Application?

Please revert if the above is not the case and the issue still persists…

1 Like

Thanks for the reply!

I use start process for launching an application. When I tried to use Open Application, the activity returned an error saying that the path was not a correct one. Did not quite understand why and just tried start process instead which worked fine.

Starting the application is probably not the issue since the application does start.



Disclaimer: I am just taking a guess here…

I am surmising that the start process opens a child thread with no relation to Uipath whatsoever (Uipath triggers it and no more does it monitor or control the events that follow) so any next action/activity in the workflow will only continue if the process completes, hence the conundrum.

if you want to ‘handle’ the error then maybe you can have a loop in parallel with a timeout condition checking for that process/application running status and end it if it goes over the configured time period.

If you want to dissect this issue then maybe try logging in to the VM where it is being executed and check for popups or any ‘human intervention needed’ activities (unknown popups or different action being triggered which was not captured etc) and then handle it in code :slight_smile:

Hope this makes sense.

1 Like

Hi again,

First paragraph: Could try to make the open application work and see if that changes anything.

Second paragraph: I have already tried that kind of solution and it does not work. Even if an activity have a 30 sec timeout, it will not timeout within that time period. It takes 15 minutes + instead for anything else to happen. Sometimes it timeous with a crash, other times the acticity has for instance found the element it was looking for, but it took 25 minutes for the activity to go from execute to close. I tried using a delay which was supposed to delay for 6 minutes, took 20 minutes to execute instead (+14min)

Third paragraph: I have tried that already and there has been no popups etc.

When I start the process from orchestrator (logintoconsole= false) I can log in to the server by myself and then it will work fine.


Hi again,

Using open application does not change anything.


Hi @johan.standeus ,

I think this might do the trick.

Login to console will make the bot create its own windows login session without using the existing one and (not sure which Uipath version you are using as this quite the guesswork I am doing) keeping it as True might solve your problem. Not sure whether you have a business reason to do so but, keeping it as false requires you to login before the package is deployed/triggered from Orch as it is not allowed to do that as the Login to Console value false.

Can you try this for a bit?

1 Like

Hi again,

I already knows that having loginToConsole = true works the way it should.
However, in this case there are business reasons which makes this impossible as a long term solution.

Having LogInToConsole = false should not force you to log in before running the process


Yes I agree - then without looking at the workflow not sure what is the issue :frowning:

There is no executor failure either right?

Well, the workflow can’t really be the problem. There is nothing in it that should make it behave as it does. I have changed it several times and even tried publishing a much smaller process which is just going to start a browser, a notepad file, open cmd, log some messages, take some screenshots. Always aftera couple of activities, it starts to behave in this faulty manor.

I use the REFramework (uipaths own version)

It can get to the InitAllApplications without fail.
It can invoke the first workflow.
it can log that the robot will now start the application
It can take a screenshot and save it
It can start the application.

It is up to this point when things start to behave the way it does. No more logs from the robot, no timeouts. When tracking on Verbose level, activities start to execute but are never closed, faulted or goes timeout until way too much time has gone by.

There is no executor failure either.


The problem is fixed. The robot version was the cause of the error (19.4.2). After updating to another version, the problem disappeared.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.