In an Excel application scope, I wanted to create an xlsx file into a shared folder and write a datatable’s data into it. It works well running from UiPath Studio in DEV, but it fails on file creation with “System.Runtime.InteropServices.COMException (0x800A03EC): Microsoft Office Excel cannot open or save any more documents because there is not enough available memory or disk space.” error when I run it from Orchestrator in UAT.
I checked the accesses, the robot user has r/w access to that folder. (It doesn’t work, even when I change the folder’s path to "C:\Temp") The process only uses Excel once, there’s no running Excel instance before it tries to execute the stage. GC Collect doesn’t help no matter where I put it. I’ve deleted everything from %Temp%. I’ve disabled protected views in Trust settings. I’ve reinstalled MS Office. I’m really running out of options here. Does anyone has other ideas on the resolution?
UiPath v2020.10, Excel 2016, Excel Pack 2.9.3 and 2.7.2, Windows Server 2012
This is happening with a supposedly newly created xlsx file. The strange thing is that I copied the code to a new process, and when I tried to run that on the UAT environment, it worked. That exact same snippet doesn’t work in the framework.
This is indeed quite strange. Do you mean that if you create a new ReFramework project, update it’s dependencies to the latest versions, and then try to do just the Excel processing bit, that it will cause the same error?
Actually, I’ve just figured out the solution. This was intended to be a dispatcher robot, and somehow, I thought that there’s no way an Excel might be open when the process wants to create that new file. This was a false assumption from my side, as the REFramework reads the config file using Excel. Due to the speed of process execution in Studio these two Excel activities (reading config then creating a new Excel file) doesn’t interfere with each other. However, when run from Orchestrator the execution speed is much faster, hence while Excel is closing the config (or has it in the background), the process attempts to create the new Excel file, and that’s not working out like that.
tldr: Always kill the Excel app after reading the config data.
First, make sure there are no “hanging” EXCEL.EXE processes on the machine from previous runs (e.g. use a Kill at the beginning of the process).
Then, if this is being caused by a race condition of Excel shutting down from a previous file while trying to start it for a second there are two things to try:
Easiest, but still carries small potential for race condition: 2.9.3 added a “InstanceCachePeriod” property where UiPath keeps the handle to the original Excel file in memory to reuse for this time period before shutting Excel down. By default it’s 3s to handle loop situations, but you can increase this to a much larger value (e.g. 60s). This means after the config data is loaded, the EXCEL.EXE will be kept alive for this period of time for reuse in a future “Excel Application Scope”. Once that time period elapses it will then shut down, which is why there is always a small risk of the race condition.
** Safest but slightly more work:** the potential for this race condition where Excel is shutting down from one file while trying to use it for a second will always exist. The way this can be guaranteed to be avoided is to place everything that will use Excel inside a parent “Excel Application Scope” save the output “Workbook” into a variable, and then place all other “Excel Application Scopes” inside this now parent activity passing in the variable to the “ExistingWorkbook” property. This will ensure that everything is done in the same EXCEL.EXE process and there is no race condition.
I’ve put “kills” before and after the Excel activities, still no luck.
REFramework by default doesn’t use Excel application scope to read config data. I’ve tried to redesign it a bit to Excel Application Scope, but I wasn’t able to make it work.
Unfortunately, I need to work with two different Excel files (config and a new one that’s about to be created). I don’t see why an Excel kill and a 10s delay between reading the config and creating a new Excel file doesn’t work out.
In theory that should work. Have you confirmed that Excel is able to start on that machine from another process? The error message implies that Excel is refusing to start because there aren’t sufficient resources on the machine (low memory).
Yes, when I extracted the Excel file creation snippets to miniprocess, that was able to run successfully and create the file for me on the exact same machine.
Lack of resources cannot be the reason as it is a terminal server with 32GB RAM an only 10GB is used out of it.
I have changed the reading of the config data into an Excel scoped one. Now it is throwing the exact same error for reading the configs. Is it possible that something’s not quite adding up within the REFramework?