Media Recording Not Working

News Knowledge Base
1

Resolution when Media Recording is not working.

Issue Description: The media recording feature in Orchestrator is not working. When a job faults, no recording of the last steps of the automation are captured.

Root Cause: The media recording feature can fail for a few reasons but failures will come in two varieties,

  • Failure on Orchestrator (For example, it cannot write to the storage location)
  • Failure on the Robot machine (It could have an issue with posting the media files to Orchestrator or it might not be able to capture the media files)

Diagnosing / Resolving

  1. Make sure to read the documentation and that media recording has been enabled
  2. A recording will only be capture if an automation ends in a faulted state. For example, if using the REFramework, a recording probably will not get captured as by default, the automation typically catches exceptions.
    • The automation can always be modified to re-throw an exception if they are being caught.
  3. Make sure that the Robot throwing the error has the 'Create' permission for execution media. This can be checked by looking at the Roles associated with the Robot (by default Robots will have the 'Create' permission.
  4. Create an automation that will end in a faulted state. For example, have the automation do a ten second delay and then have it immediately throw an exception.
  5. Run the automation and then check the Robot Event Viewer logs (Event Viewer->Windows Logs->Application and search for errors from event source 'UiPath')
    • If you seen an HTTP exception such as "ScreenshotUploader: UiPath.Service.Orchestrator.Clients.OrchestratorHttpException: An error has occurred." that most likely means that the issue is on Orchestrator
  6. If there are no errors, check the event viewer logs on the Orchestrator machine (Event Viewer->Windows Logs->Application and search for errors from event source 'Orchestrator')
    • A common error would be something like: "System.UnauthorizedAccessException: Access to the path 'C:\Program Files (x86)\UiPath\Orchestrator\Storage\Orchestrator-2401BF1A-33E6-414E-818F-BDD9C3F5DA43\ExecutionMedia\Robot-4' is denied."
    • An error like this would me that the Application Pool running Orchestrator does not have permission to write to the target folder.
    • Another error that could be encountered is that the target destination drive is full.
  7. If the Robot Event Viewer logs and the Orchestrator Event viewer logs do not give a hint to the error, enable the Robot trace logs for more detailed information.
    • After enabling the logs, reproduce the error.
    • Check the event viewer logs on the Robot machine for new warning messages (Hint: search for 'ScreenshotUploader' or 'ScreenCapture')
    • When a screenshot is taken, the following messages should be seen in this order:
      • Saving screenshots for job FaultProcess/de869b35-8e9e-48f1-a043-0be68c8908a7 in folder: C:\Users\admin_1\AppData\Local\UiPath\Screenshots\de869b35-8e9e-48f1-a043-0be68c8908a7
      • ScreenshotUploader: 1 photos, skipped 0, 0 MB total size
      • Request uri: https://orchestrator/api/robotsservice/UploadScreenshot
    • Look out for the following types of messages
      • Info - ScreenshotUploader: 3 photos, skipped 2, 0 MB total size - This means the Robot tried to take three screenshots but was only able to take one. Hence it skipped the other two.
      • Warning - ScreenCapture: invalid screen DC handle, skipping screenshot - This means a screenshot could not be taken. See next step.
  8. If after enabling trace messages the following warning message is seen: "ScreenCapture: invalid screen DC handle, skipping screenshot" this means that the Robot is running in a session that is a disconnected state. This means the RDP session went into a disconnected state.
    • This can happen with long running processes. In a case like this, check group policies to see if there is a screensaver enabled our session timeouts are enabled.
    • Another time this can happen is if a user logs into the Robot machine while it is running and then disconnects (putting the session into a disconnected state). If a user logs into a Robot machine while it is running, they need to remain logged in for the rest of the duration of the automation.
    • Similar to above, if an automation is started while a user is logged in and then they disconnect, this will also put the automation into a disconnected state.
    • Another possibility is if the fault is immediate. In this case, the GUI might not be fully loaded. Try adding a delay at the start of the automation (If the fault is immediate, the recording will probably not help with the issue that is trying to be recorded.).