- Release Notes
- Getting Started
- UiPath Assistant
- Installation and Upgrade
- Robot Types
- Robot Components
- Licensing
- Connecting Robots to Orchestrator
- Processes and Activities
- Logging
- Robot JavaScript SDK
- Specific Scenarios
- Windows Sessions
- Login Using Thales Luna Credential System
- Login Using NShield Key Storage Provider
- Redirecting Robots Through a Proxy Server
- Executing Tasks in a Minimized RDP Window
- Using Mapped Network Drives
- Stopping a Process
- Disable Stop Button
- Custom Package Folders and Network Paths
- CrowdStrike Integration
- Troubleshooting
- Unresponsive Robot Over RDP
- Duplicate Execution Logs
- Frequently Encountered Robot Errors
- Increased Process Execution Duration
- Enforced Package Signature Verification
- Message Too Large to Process
- Errors When Running as Administrator
- NuGet Packages Not Accessible After Migration
- User Access Control Prompt and UI Automation Activities
- .NET6 Projects Fail to Run
Stopping a Process
A process can be stopped through Kill or Cancel commands. The command can be sent from Orchestrator,Assistant or Studio.
When the Robot receives the Cancel command, it cancels the execution of the current activity and starts executing the final steps. If this takes more than 3 seconds, the process is killed.
On the other hand, when the Robot receives the command to Kill a process, it first tries to Cancel the execution and if the execution is not finished in 3 seconds, the process is killed.
During a Try-Catch workflow, when a process is stopped, the transaction status can show as successful when it actually did not complete.
If the execution is in the Try or Catch block when the Cancel command is received by the Robot, it skips to the Finally block which checks for any errors. If no errors are found, then the Finally block thinks the execution completed successfully as there are no failure events (they are blank).
If the execution is in the Try or Catch block when the Kill command is received by the Robot, it first tries to Cancel the process, skipping to the Finally block. If the logic inside the Finally block is not finished in 3 seconds since receiving the Cancel command, the whole execution is killed and the overall process is successful in the logs as no errors were recorded in the Catch block since it was skipped.
- Setting the Process status to
Successfulshould be done only inside the Try block, after the Business Logic is completed. - Setting the status to
Failedshould be done only inside the Catch block, after the error handling logic is completed. - In the Finally block, there should be only cleanup logic present, since it is executed no matter if the execution was successful or not.
BusinessError and SystemError to stay null and the overall process status is considered successful. The behavior described is intended.
BusinessError and SystemError stay null and the overall process status is considered successful, as no errors were recorded.
