Screenshot on unattended VDI

We are using Orchestrator to run workflows on remote VDI’s (backoffice, unattended).

We are unable to get either the UiPath screenshot activity nor custom code to take a screenshot to work. Note we have used both in other environment configurations.

How can you capture a screenshot running a workflow on an unattended VDI?

Thank you,
Scott

1 Like

@Scott Hope attached file use full

screenShot.zip (2.1 KB)

indra, this works if you have a VDI open… but not if you are disconnected from it (backoffice, unattended mode). No screenshot is created.

Thank you,
Scott

@ddpadil

Hi,

Taking screenshot of a VDI when you run job from orchestrator should not be an issue.

Anything specific on your VDI environement? High density robots?
Any exception message/workflow to share?

Cheers

Hi @Scott,
When you have a third party application like snagit in VDI. And try to take screenshot, it opens up a window to drag an area on screen(same as snipping tool).
Request you to check the VDI if it is the issue.

Regards,
Vikas

Nothing out of the ordinary as far as I know. I am simply running the code that was provided. That code works fine on my local machine. And it works fine on our VDI’s as long as someone is connected to it. But if you disconnect, to let a robot run in unattended mode, it fails to generate the screenshot.

2 Likes

To troubleshoot it, it is important to know at which stage it fails and with which error message.

issue are coming from :

  • Get Screenshot, issue with Selector. You could try removing the selector, this will take all the Desktop screen
  • Save image, Insure that the path is correct and that the user that you use as robot as access to this path prefer local path for testing

Saving screenshot for unatended robot should be fine unless something specific to your environement would make it otherwise.

Cheers

I will say this again.
I am using the code that was provided in the sample above.
That code does not use a selector and so takes a screenshot of the entire screen (which is fine).
This code WORKS (and does not generate any errors) locally or when a VDI is open.
This code does NOT WORK when a VDI is closed (not logged into).

I am adding some logic to capture error information and will post it.
I appreciate your thoughts.

Thank you.

1 Like

Important detail, when you say you run the workflow when VDI is open and it is working, do you use system tray or Studio?

in case you would be using studio, very likely what could be happening is that you are saving the screenshot using a relative path (.screenshot\untitled.png). When you are running it from studio, it will save the screenshot on the project location as it is the current context of the workflow execution.

However when you publish your project and trigger it from orchestrator or system tray, the context will become the package is stored after it is synced with the orchestrator (on 2017.1 it will be attempted to be as saved %programdata\UiPath%ProjectName&Version\lib\net45\untiltled.png and fail because you cannot save file at this location.

A simple way to spot the location for a relativepath is to log something like under

new FileInfo(“Untitled.png”).FullName

if you do not have any try catch, running from the system tray should be showing your an error related to the path.

If you do not use relative path you have no error occuring from system tray with TryCatch, the problem is elsewhere

Cheers

This is all using Orchestrator.

The error received is “Object reference not set to an instance of an object.”

The Try consists of:

UiPath.Core.Activities.TakeScreenshot (no parameters except Output storeScreen)
Aystem.Activities.Statements.Assign (strImagePath = directory + filename)
UiPath.Core.Activities.SaveImage (strImagePath, storeScreen)

Again. This code works fine in attended mode… just not in unattended mode.

Thanks,
Scott

Hi Scott,

is there an active desktop for the robot (code) to work on when in unattended mode?

I’ve had a similar problem and it was solved by setting the attribute Interactive Logon =True for the AD-account used by the robot. Check with your AD-team, maybe it’s the same problem.

Regards,
/Klaus

Thanks, Klaus.
I’m not sure abou the AD settings, but will investigate.
The uipath.settings file has “logintoconsole” set to false as a recommendation for managing screen resolution.

Cheers,
Scott

Klaus ~ I don’t have an answer from support on this… but I’m pretty sure if this was set incorrectly we would not be running on the VDI’s at all. We have a well established infrastructure and run bots all the time. The only thing we seem to be having a problem with is this image capture. And the only variance is in whether the VDI is “open” or not.

Since there’s no actual video output, I’m trying to understand if there is something in the way an unattended execution handles its video that makes grabbing a screen capture not work… and if so, if there might be something we could code to address that. It is quite vexing…

Thanks
Scott

Hi @Scott
I have been using unattended robots and capturing screenshots like when a fault occurs, and that is without the Launch Interactive. It seems to work fine for me.

If you are talking about Image recognition then yeah, we had issues with that until I discovered the Launch Interactive activity and got the resolution set correctly. Everything works now for the processes that required it - OCR, Image clicks, Clipping Regions, etc

I don’t know if that will help answer any issues but just letting you know that we haven’t had any issues like you are describing.

Interestingly enough, I tried one time to record video while the unattended robot ran and it only recorded a black blank screen. :man_shrugging:

2 Likes

Thanks, Clayton… that is helpful to know. That’s exactly what we are trying to do… just without consistent success. It is becoming apparent to me that there must be something about our VDI’s that is non-standard…

Hi Scott,

I have the same issue on unattended robot on disconnected VDI when doing screen capture.
Any further update from you or other experts here?

I wonder if the graphic session of the VDI is destroyed once it is disconnected (as i read from other thread about RPA on VM/VDI/RDP) so it is not possible to capture the screen into picture.

But same, I need a solution for this too, I require to use screenshot to capture any exception encountered by the bot.

Regards,
Ben Wong

1 Like

Hi Ben.

Unfortunately, we never found a work around for this. Ultimately, we are scrapping VDI’s and transitioning to an RDP solution where this doesn’t seem to be a problem.

In general, we have had a MUCH better experience with the server solution.

Good luck!
Scott

Hi Scott,
the word “resolution” keeps popping up. Maybe it’s “just” that…

One of my collegueas was working on a Navision/PDF process where everything worked fine locally, but after moving to ORCH 2018 it failed. After some frustrating days he was able to figure out that the resolution was too low in runtime and this cramped all his windows to a minimum.

He found out, that when an unattended robot (at least in his case) was called into action the screen resolution was set to 640 x 400 (or similar crazy (default?) setting). This of course made FUBAR in his full-screen robot. He was able to see this in action by shadowing the robot using TeamViewer or a similar remote tool.

The solution was to make sure the screen resolution was the set to the expected 1920x1080. This was done on the robot in ORCH which now has a runtime-tab where you can specify a desired resolution for this particular robot.

May be it helps.
Greets
/Klaus

3 Likes