Attended robots - Issue with blocked Excel by "other user"

Help Robot
1

Hi Folks!

Disclaimer - I’ve checked the forum for possible solution, but didn’t find it, hence this topic.

Situation:
I have multiple unattended robots triggered by one robot (let’s call it schedule). They run on one VM, there is one user that runs those robots. All the robots are fine except one: it’s using excel macros to run reports from web app (Chrome) and SAP reports.
Issue:
When executing macro it’s get stuck with info that someone else is working on the file, which I know it’s not true.
What I did:
According to this forum I’ve:

  1. Added Kill Excel Proces EVERYWHERE I can - does not work.
  2. Had issue with move file (excel) so I’ve changed it to Invoke process in VB - helped for one/two days then it gets stuck in the same situation: somebody else is working on the file.

BUT! When I restart the VM, process runs without issues, so I have to restart the VM daily, which is not great.

Any Ideas what might cause it?

Godspeed Filip

2

Hi @filip.niedzwiecki,

Welcome to the community.

Use Kill Excel Process and set the property AppliesTo → CurrentUserOnly.

Thanks!

3

@filip.niedzwiecki

Few quick checks,

Any other processes are running on the same machine, ensure only one process is running.

And coming to your macros, just check is there anything that leaving excel related stuff sometimes that cause issue. If in you macro anything related updating or opening excel things ensure that macro should contains close as well

4

Hi @filip.niedzwiecki ,
Please check these once:

  1. Check if any EXCEL.EXE processes remain running after the job finishes. A hidden Excel instance can keep the file locked.
  2. Make sure every Excel activity is properly closed with Close Workbook/Quit Excel and use Kill Process (EXCEL) in the Finally block.
  3. If macros are creating temporary files, add a short delay and ensure the workbook is saved and closed before the next action.
  4. Store the Excel file on a local drive instead of a network/shared location if possible.
  5. Use Workbook activities instead of UI-based Excel automation where feasible.
  6. Review whether multiple unattended jobs are accessing the same file simultaneously on the VM.

Thanks

5

Thank you @iampnkz for quick reply - I have added this to the robot.

6

Hello @yedukondaluaregala.
There is only one process at a time (no background processes). Also, I’ve checked the macro and it’s shutting properly (no Excel instances open after execution).

Thank you for your reply, I appreciate.

7

Thank you @Jasmin_Bar for quick reply.

  1. No Excel “residue” after each macro (there are 3 in total)
  2. Done
  3. Yes, robot creates a lot of temp files - delays added
  4. Not possible in current situation
  5. Everything goes through macros
  6. Only one production user has access to this VM/those files.

Thanks everybody for help - the process is scheduled for Monday - I will keep you posted.

8

Hi @filip.niedzwiecki

This could be caused by a stale Excel process or temporary/lock files left behind by previous runs.

Instead of only using Kill Excel Process, I would check:

  • Task Manager for any remaining EXCEL.EXE processes.
  • The folder for Excel lock files starting with ~$ and remove them if no one is using the file.
  • Make sure all Excel workbooks are properly closed before the next run.
  • Check whether multiple robots are accessing the same Excel file at the same time.

Since restarting the VM fixes the issue temporarily, it strongly suggests that some process or file lock is remaining between runs.

9

@filip.niedzwiecki Since you’ve already confirmed there are no leftover Excel processes and only one job is running at a time, I would focus on the file lock/temp files now.

One thing you can try is, before opening the workbook, check whether a ~$filename.xlsx lock file is still present. If the workbook is definitely not in use, remove the stale lock file and then continue.If it happens again on Monday, before restarting the VM, check Resource Monitor / Process Explorer for the Excel filename. That should help identify which process is actually holding the file handle.

10

Hello All,

Update on situation.

I have not restarted VM since thursday - all processes have since (24/7) without a hicckup. Yesterday and today no issues with the robots.

Addind “kill excel → apply to → onlycurrentuser” in try catch and “kill excel for all users” seems to do the trick.

I will inform if something goes south.

Thank you very much for all the posting professionals for valuable info!

11

Hi @filip.niedzwiecki,

Good to hear that you are not getting the error now.

Since multiple users/Robot accounts can access the same server, Kill Excel for all users may not be suitable. It require admin rights and may affect other users’ Excel processes.

Thanks!

12

Update:

Sooooo, nothing worked - the issue is back, unfortunately intermittent; robot runs fine for few day but every now and then its got stuck on “Excel already open by someone else” - only restart VM works.
This robot is scheduled for migration to unattended - this should help.

Thank to all the people that took their time to write here, you’re appreciatted :sunny:

13

@filip.niedzwiecki When Excel reports a file is locked by another user even after killing EXCEL.EXE, the lock is usually held by an external Windows service rather than Excel itself. In multi-robot setups running continuous reports, common culprits are the Windows Search Indexer (SearchIndexer.exe), an antivirus on-access scanner, or an Office Document Cache / OneDrive background sync process holding open read handles on recently closed workbooks.

When the issue appears, open Resource Monitor on the VM, go to the CPU tab, expand Associated Handles, and search for the workbook filename. That will show the exact executable holding the open handle when EXCEL.EXE is already dead.

As an immediate fix, exclude the working folder from Windows Search indexing and your antivirus real-time scan path. In your workflow, before opening the workbook, test if the file can be opened with exclusive read/write access using a small retry loop around a FileStream open in an Invoke Code activity. That ensures the robot waits until any transient background handle releases rather than failing immediately in Excel.

14

Hi @filip.niedzwiecki,

Since Move File also failed on your file, it looks like Windows really has the file open, and it’s not just a leftover ~$ file. You mentioned you can’t move the file to a local drive, so is it on a network share? If it is, the lock may be held by the file server and not by your VM. That would explain why only a VM restart helps, because a restart drops the connection to the server.

Next time it happens, check these before you restart:

  1. Open Task Manager, go to the Details tab, and add the Session ID column. See if any EXCEL.EXE is running under another user or session. Your kill step might not reach it.
  2. Open Resource Monitor as admin, go to the CPU tab → Associated Handles, and search for your file name. If a process shows up, that’s what is holding it. If nothing shows up, the lock is probably on the server.

Also, in your Kill Process activity, use EXCEL as the process name (no .exe) and set Applies To to OnlyCurrentUser. If it’s left blank it defaults to All, which needs admin rights.

You can also add a small check before the macro runs, using Invoke Code or UiPath activities:

  • Try to open the file. If another program is using it, you get an error.
  • If it opens, the file is free, so close it right away and carry on.
  • If it fails, wait a few seconds and try again, up to about 10 times.
  • If it’s still locked, log a message and stop, instead of letting Excel hang.

This won’t fix a stuck lock, but it helps with short ones from antivirus or sync tools.