so I have a process that’s runs just smoothly if it’s started from Studio. However, when I start it from Orchestrator, it fails everytime. In the Initialise part of the process I close Chrome browser if it’s open. I get this error message:
Close Application: Cannot terminate the process which owns the current node.
However, my problem is not exclusively connected to this activity. If I remove this activity, the next activity is a Read Range activity that reads an xlsx file on my machine. But I get some kind of remote exception…
So it seems that only log message activiy isn’t crashing my process when starting from Orchestrator. Every activity that has to read or manipulate something on my local machine is faiing. Could there be a problem with authorization? I am the only user on my machine and I have admin rights…
Hi
I am facing exactly same issue as Rajid.
Close application for chrome works well while run with studio but error occurs while run with OC.
The robot is an unattended robot in production and the credential matches.
Login to console setting is set to true and the selection is no.
Please help
Below for the exception-
System.Runtime.InteropServices.COMException (0x80040228): Cannot terminate the process which owns the current node.
at UiPath.Core.Activities.ObsoleteTaskAsyncCodeActivity`1.EndExecute(AsyncCodeActivityContext context, IAsyncResult result)
at System.Activities.AsyncCodeActivity.System.Activities.IAsyncCodeActivity.FinishExecution(AsyncCodeActivityContext context, IAsyncResult result)
at System.Activities.AsyncCodeActivity.CompleteAsyncCodeActivityData.CompleteAsyncCodeActivityWorkItem.Execute(ActivityExecutor executor, BookmarkManager bookmarkManager)
We were experiencing this issue with one of our BOT’s. The automation worked absolutely fine attended, and in debug mode, but refused to work unattended.
After hours of debugging and adding additional log messages, we found the trigger for “Cannot terminate the process which owns the current node” was somewhere inside a “for each” activity.
The for each was looping through a data table containing 6 rows, and triggering a “Throw” if the data we were looking for was in the DT.
The “fix” was to put a 2 second delay as the first activity inside the loop. I am still not sure how this has fixed it, I can only assume “something” was going too fast (our logging showed that the sequence was running in a matter of milliseconds).