Troubleshoot and debug unattended runs with screenshots

Symptom

A script that can be executed successfully in attended mode does not run successfully in unattended mode.

It is usually failing with a message such as: "There was a problem running the action 'Click'. The link could not be clicked on the web page."

Cause

Typical failures in unattended runs are caused by one of the following:

• Script not tested in attended mode before switching to unattended

• Different configuration used by the unattended session

  • A different Windows account used by unattended run than that used to create the flow

  • Screen resolution (see how to change the screen resolution)

  • Browser configuration

    • User

    • Popup blocker

    • Extensions (missing/ not activated)

• Screens are not loaded entirely (missing delays)

• A UAC prompt that blocks UI automation when the session begins

Solution

As there could be different causes, the solution below describes how to add screenshots before and after a failing action to get some visual feedback. Looking at the screenshots carefully after an unattended script failure could help to find one of the causes listed above. It also describes how to compare display resolution and scale settings.

If you already have screenshots in your flow and they are failing to execute, you may have a User Account Control (UAC) dialog blocking the execution of your flow. Please login to the machine which is reproducing the problem with the account you're using to execute the flow and see if you have such a blocking dialog. If you do, change your startup routine to prevent this from occuring.

Adding screenshots to troubleshoot

Start by logging into the computer that reproduces the problem with the account you are using in your connection. Verify that there is no UAC prompt that may be blocking UI automation.

If there is nothing that would block UI automation, take a screenshot before and after a failing step in unattended mode can help to get visual feedback.

The failing step should continue on failure so that a screenshot can be taken after the failure.

1- Look for the "Take screenshot" action

 2- Drag and drop the "Take screenshot" action to the script side

3- Edit the action, use "File" instead of clipboard, and "before" in the file name location 

4- Then copy/paste, and change the screenshot file name with after in it 

5- Surround the failing step with the screenshots

6- Change the onError behavior of the failing step

6a- Edit the step and click on "onError" at the bottom

6b- Set the flow run to "Continue flow run" and "Go to next action"

7- Save, run locally to test that screenshots are produced, and relaunch an unattended run.

8- Check the unattended screenshot files. 

Check screen resolution and scale differences

To compare the resolution settings between attended and unattended run executions, add the below actions in your script before running in both modes:

• Copy/Paste the below code snippet in a PAD designer: this will create the necessary steps to capture the resolution settings and output them in a timestamped file.

DateTime.GetCurrentDateTime.Local DateTimeFormat: DateTime.DateTimeFormat.DateAndTime CurrentDateTime=> CurrentDateTime
Text.ConvertDateTimeToText.FromCustomDateTime DateTime: CurrentDateTime CustomFormat: $'''yyyy_MM_dd_hh_mm_ss''' Result=> FormattedDateTime
Workstation.GetScreenResolution MonitorNumber: 1 MonitorWidth=> MonitorWidth MonitorHeight=> MonitorHeight MonitorBitCount=> MonitorBitCount MonitorFrequency=> MonitorFrequency
@@copilotGeneratedAction: 'False'
Scripting.RunPowershellScript.RunPowershellScript Script: $'''Add-Type @\'
using System; 
using System.Runtime.InteropServices;
using System.Drawing;
public class DPI {  
  [DllImport(\"gdi32.dll\")]
  static extern int GetDeviceCaps(IntPtr hdc, int nIndex);
  public enum DeviceCap {
  VERTRES = 10,
  DESKTOPVERTRES = 117
  }
  public static float scaling() {
  Graphics g = Graphics.FromHwnd(IntPtr.Zero);
  IntPtr desktop = g.GetHdc();
  int LogicalScreenHeight = GetDeviceCaps(desktop, (int)DeviceCap.VERTRES);
  int PhysicalScreenHeight = GetDeviceCaps(desktop, (int)DeviceCap.DESKTOPVERTRES);
  return (float)PhysicalScreenHeight / (float)LogicalScreenHeight;
  }
}
\'@ -ReferencedAssemblies \'System.Drawing.dll\' -ErrorAction Stop
Return [DPI]::scaling() * 100''' ScriptOutput=> MonitorScaleOutput
File.WriteText File: $'''c:\\test\\resolution_%FormattedDateTime%.txt''' TextToWrite: $'''height: %MonitorHeight% width: %MonitorWidth% frequency: %MonitorFrequency% bitCount: %MonitorBitCount% scale: %MonitorScaleOutput%''' AppendNewLine: True IfFileExists: File.IfFileExists.Overwrite Encoding: File.FileEncoding.Unicode

• Review the output file path from the last action, check that local execution is successful and save.

• Run the script in both attended and unattended modes, then check whether the resolution and scale output have the same values in both modes.