ExcelApplicationScope "random" HRESULT's

Help
1

Scenario:

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:

  1. 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).
  2. 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).
  3. 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.

Current Behavior:

As in the Scenario.

Expected Behavior:

Not hooking up to closing process.

Suggested workaround/improvement:

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).

Studio/Robot/Orchestrator Version:

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

1 Like
2

Hi @andrzej.kniola

I wanted to report those, but I have trouble reproducing it on 2019.2, even with a downgraded package of Excel.

Any chance you were testing it with a Stable Enterprise? Could you try with the CE with up-to-date Excel package (2.5.2)?

The same goes for your other thread here.

Funny enough, I do remember both of those bugs from the time I was starting with UiPath (I think it was around 18.1 or 18.2), especially the one that would “eat” your running Excel (super annoying).

I couldn’t get it to do it though on 2019.2.

3

Of course, we don’t run community edition.

Not with CE. For Excel package 2.5.2, maybe, I’ll need to check with the dev responsible for the project where that issue was found.
I suppose you mean specifically this release note:

In certain situations, Excel Workbooks were closed during the execution of an automation project.

Sidenote - The Studio version itself shouldn’t matter at all, unless the description that activity packages, unless specified otherwise and part of the core activities, work independently from the Studio version, is a lie.

I fully understand it, as it’s a bloody pain to reproduce - it’s essentially a random race condition (the part about the window for this to happen is in nanoseconds might be an overstatement, but I’m pretty damn sure it’s <1ms).
We’ve so far only encountered this while running whole processes or getting very lucky with an infinite, tight loop on a VM (that’s probably something that needs to be taken into account) and it still takes hours.
Unless of course you’re running CAT’s, then it pops up immediately, because Murphy’s Law :confused:

For the other one, I’ll update there when checked with 2.5.2 (again, CE is not an option and Studio version shouldn’t affect it and 18.4 is a LTS so if it does affect, it needs a patch).