In a tight loop, ExcelApplicationScope can “randomly” (~once every couple of thousand iterations, depending on circumstances) produce a wide array of different HRESULT ComExceptions due to hooking up to a running Excel process in incompatible state.
Example produced error below, but they can vary greatly:
Execution error : UiPath.Excel.ExcelException: The server threw an exception. (Exception from HRESULT: 0x80010105 (RPC_E_SERVERFAULT)) ---> System.Runtime.InteropServices.COMException: The server threw an exception. (Exception from HRESULT: 0x80010105 (RPC_E_SERVERFAULT))\r\n at Microsoft.Office.Interop.Excel._Application.get_SheetsInNewWorkbook()\r\n at UiPath.Excel.WorkbookApplication.Initialize(WorkbookArguments args)\r\n --- End of inner exception stack trace
Looking through interop documentation, that method is a simple int getter that could fail if, and only if, the excel application process instance it refers to is corrupted or in unusable state. The HRESULT in this case does not point to the real cause, but a random call that failed due to an issue elsewhere.
Steps to reproduce:
- Run an infinite loop with an invoke to a separate workflow with ExcelApplicationScope with f.e. ReadRange or AppendRange (the activities inside themselves don’t matter much).
- Encounter a situation where the preconditions for the error align and an iteration of excel scope hooks up to a just closing excel process, but it’s too late to keep it alive (seems to be a window in nanoseconds).
- Observe random HRESULT being thrown on the next interop call that is invoked. Result looks the same as if the process would be killed from TaskManager at the right moment.
As in the Scenario.
Not hooking up to closing process.
From developer perspective, safest is to untighten the loop (add a small delay, 100ms should be enough) after closing ExcelApplicationScope/Workbook. This only works if you do not use parallelization.
From activity perspective, a bool property for running as a new process would enable tighter control to avoid this situation and also enable safe parallelization (which is currently not really safe with heavily parallelized Excel, even if each track is guaranteed to work on separate files).
Last stable behavior: Unknown
Last stable version: Unknown
OS Version: Server 2016
Others if Relevant: (workflow, logs, .net version, service pack, etc):
Excel package 2.5.0, Excel 2016