Hi Team,
I have two different unattended robots running under two different Windows users on the same VM.
Both robots run two different processes.
We already take our own exception screenshots in the project folder, but UiPath still tries to save the system-level exception screenshot in: C:\ProgramData\UiPath\SessionScreenshots
When both robots fail around the same time, the following error appears in Event Viewer: The process cannot access the file because it is being used by another process.
This means the auto-generated screenshot filename (based on timestamp yyyyMMdd-HHmmss-xx) is being written by both robots at the same time, causing a file lock collision.
Observations:
- Both robot users have full access to the SessionScreenshots folder
- The error happens before the workflow starts, so our custom screenshot logic never executes
- Only happens when both robots start or fail at the same second
- File-lock issue in SessionScreenshots folder
My Questions:
- Is there any supported way to isolate SessionScreenshots per robot user?
- Can we disable or redirect Orchestrator’s default system-level exception screenshot?
- What is the recommended approach for multiple unattended robots on the same VM to avoid this conflict?
Any guidance or best practices would be greatly appreciated.
Thanks!
When you are taking screenshot you always can specify the location you would like to save your screenshot in.
How are you specifying location? Is the location specified is same for both projects? And no unique identifier in the name to identify which bot placed that screenshot in?
Usually, for such cases, I would prefer to
-
specify different locations
-
if want to go for same locations, then would use process id or process name something to differentiate.
We have two separate projects:
For example Project 1 running under User 1, and Project 2 running under User 2 in same VM
Inside each project, I’m saving screenshots to a custom folder, and the bot is correctly storing exception screenshots separately for each process.
The issue is with the screenshots captured before the process starts—for example, when there is a network issue. In those cases, Orchestrator automatically takes a screenshot and saves it in the default path:
C:\ProgramData\UiPath\SessionSnapshots
This folder is created by Orchestrator for diagnostic logs.
My question is: Is there any way to change this default screenshot path?
Hi @PAVAN_KALYAN1
There is no supported configuration in UiPath to change or redirect the default SessionSnapshots folder. These diagnostic screenshots are always stored under C:\ProgramData\UiPath\SessionSnapshots by the Robot service before a process starts. The only practical approaches are to separate unattended robots onto different machines or sessions, or stagger their schedules to avoid simultaneous failures. Custom screenshot logic inside your workflows can still be directed to any folder you choose, but the system‑level path itself cannot be modified.
If you found helpful please mark as a solution. Thanks
Happy Automation with UiPath
We had some issues with that but we fixed in higher robot versions.
For 24.10.x robot, we fixed it starting with 24.10.13.
”Occasionally, taking a session screenshot caused a UiPath.Session.csharp.exe application error, which prevented robot sessions from closing correctly and new jobs could not start.”
Robot - 2024.10.13
Use this patch https://download.uipath.com/versions/24.10.17/UiPathStudio.msi that should contains that fix and retry the failed automation.
UiPath currently does not provide any supported configuration to modify, disable, or redirect the default SessionSnapshots folder.
This happens before the actual automation starts, so the location cannot be changed.
You can use separate machines or Windows sessions for unattended robots, or
Stagger their schedules to avoid multiple robots failing at the same time.
Inside your workflow you can still take your own screenshots and save them to any custom path you want — but the system-generated path itself is fixed.
Thanks for the replies, everyone. This discussion is now closed.