Take screenshot fails in unattended mode when RDP disconnects

Hi,

When RDP disconnects normally we receive timeout errors. In this case bot is unable to take screenshot because RDP session is disconnected . So, in such scenarios we normally place a default image in the same location where takescreenshot workflow is present in the framework folder and We add logic inside takescreenshot workflow that if bot is unable to take screenshot then in the catch section we send exception email and default image as an attachment.

But that won’t serve any purpose to my problem as I need the screenshot whenever an exception takes place.

Default image will not serve me the purpose as i need screenshot of screen where BOT got failed.

Your question has the answer I guess.

Service mode should help !

What exactly do you want a screenshot of though?

Your RDP session is disconnected, so how to do expect to take a screenshot of a disconnected RDP session? If the desktop was available to take a screenshot from then the RDP wouldn’t be disconnected and the error wouldn’t be occurring…

Am I misunderstanding your situation?

Jon_Smith… I am running my bot in unattended mode and need to capture bot failure as an exception. Need to capture the screenshot where bot fails.

I have to run my unattended bot without connecting to the bot machine via rdp.

That’s the requirement

Ok, lets just explain the situation in more detail so we can all understand what you are doing and what you want.

So the bot is running on a virtual machine somewhere, if you have an RDP session open connected to that VM the bot can take a screenshot, but if you don’t have the VM open the bot cannot take a screenshot?

Have you tried making a bot that only takes a screenshot so the error is not a factor? Try doing that and testing out if the bot can only take a screenshot when there is an RDP session connected. This could make sense as the VM can have no screen to take a screenshot of when its not connected to any RDP.

@Jon_Smith

Yeah. Precisely…

To seperate or the issue, i tried making only 1 xaml with the take screenshot activity and save image . It works fine when rdp session is open in front of me. It fails the moment i minimize the rdp session or disconnects it.

It happens for both unattended and through developer studio bot testing .

1 Like

@Nithinkrishna

Thanks Nitin. How to update user mode to service mode. Can i simply uninstall the robot in BOT machine and reinstall again using service mode as option ?

Ok, this is very clear now. Nithin was correct to suggest Service mode.

To explain your problem clearly, a virtual machine has no monitor and only displays visual screen elements when a user is viewing through an RDP session. When its disconnected its basically not displaying a screen anywhere and therefore impossible to take a screenshot.

UiPath has Service Mode which should resolve this issue for you as it will spin up a session.
Try reinstalling UiPath Robot on the VM as Service Mode.

See here for another topic discussing it.

Hi @Sumit_Ghosh1,

If you have the following robot settings, your screenshot activity will work.

Robot user settings

Why does this work?
Robot Settings (uipath.com)

Login To Console Enables the Robot to connect to the console session of the machine where it is installed. Additionally, it indicates if you can connect multiple Robots to Orchestrator using multiple users ( High-Density Robots ) or not. By default, this is set to No . To enable High-Density Robots, set the value to No .
If set to No , the Unattended Robot creates an RDP session when executing a process.

Using service mode is something new to me thanks @Nithinkrishna for the alternative.

1 Like

does not work either…
this happens when i throw procces from orchestrator. but from machine manually its going right

here my error:

System.ComponentModel.Win32Exception (0x80004005): Controlador no válido
at System.Drawing.Graphics.CopyFromScreen(Int32 sourceX, Int32 sourceY, Int32 destinationX, Int32 destinationY, Size blockRegionSize, CopyPixelOperation copyPixelOperation)
at System.Drawing.Graphics.CopyFromScreen(Point upperLeftSource, Point upperLeftDestination, Size blockRegionSize, CopyPixelOperation copyPixelOperation)
at UiPath.Vision.UiImage.FromScreenRegion(Rectangle region)
at UiPath.Core.Image…ctor(Region screenRegion)

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)

1 Like

i found this like solution when RDP is closed but no minimized

1 Like

Hey @amy93amanda

This is due to session timeout mostly.

Kindly check this error occurs after a job runs for a constant time…

Thanks
#nK

Hi
Kindly tell me where we’ll get this screen. I mean settings image you have shared here na ?

@amy93amanda

in your folder (default probably) → robots → 3 points at the right of your robot → edit → settings sheet

Hi Sumit,

Were you able to sort out or found a solution to this issue ? If yes, please share it will be really helpful.

Thanks

I am not sure whether I fully understand the problem but here’s my understanding of how taking screenshots on Virtual Machine RDP sessions work:

  • If you have an RDP session open manually and then from the Orchestrator/Assistant you start a Job on that session it will take screenshots only if you have the session open. If you close it then the session will “lose its screen” and no longer be able to take screenshots (resulting in the error you listed). Think of it like a “semi-attended” session - you started the session, Robot joined in to execute the Process on it so as long as you have it open, it can take screenshots but when you close it, it no longer has a desktop to work on.
  • If you, however, don’t have the RDP session open (there is no session for this user on the VM you want the Robot to work on) and you execute the Job from the Orchestrator - then it will take screenshots without any issues (if you have settings set as @jeevith has shown above). However, if you then intervene and connect via RDP to this session then you need to keep it open until the process ends - because if you close it/disconnect, you will once again cause the Robot to lose the desktop and no longer be able to take screenshots.

So to sum it up: if you want the Bot to run unattended - do not connect to it via RDP.
And if you have to connect to take a look at what the Robot is doing (e.g. during hypercare phase), then be prepared to keep the session open until the Job is finished.

Can you confirm if the above settings have worked for you ? Because i tried those settings already and in my case its still failing. My exact issues is that i want to capture screenshot if flow i am executing runs into an issue, and i want it to work in both while i am connected with a RDP connection with the robot machine (which is already working fine), and also it should equally work if i am executing the test cases via CI/CD or directly via orchestrator without creating a RDP connection with the Robot machine.
I have tried the settings @jeevith has suggested, but it doesnt seem to work for me. If you can help me with a solution it will be helpful, as now you understand my usecase.

Have you logged into the RDP server with the robot account? Don’t do that. If you did, then closed the RDP window without signing out, you’ve left it in a state similar to being locked. Log back in, then sign out properly. Then run your job.

Also, is Robot installed in service mode on that server? It needs to be in service mode.

1 Like

If you have the settings as @jeevith showed in his screenshot and there is no existing session (e.g. from your manual logging in) on the target machine, then if you execute a Job from the Orchestrator it will take screenshots.

As I mentioned above, it only fails if there is an existing session (created manually, either before or during Job) which is later manually closed - in this situation Robot “loses desktop” and is no longer able to take screenshots.