Excel application scope suddenly unable to open files: HRESULT E_FAIL

Hello UiPath community,

A workflow I was working on suddenly started outputting this bug:

Excel Application Scope: Error HRESULT E_FAIL has been returned from a call to a COM component.

I looked around on the forums and I found many others with this issue, but only regarding Chrome not excel.

The 3.5 fixes I found in those articles were:

1 Use IE instead of Chrome
2 Uninstall UiPath Studio and Reinstall
3 Uninstall and reinstall .NET Framework 4.6 (Most agreed this as a fix)
3.5 Did you type your Path correctly

I tried all solutions to no avail and even uninstalled and reinstalled UiPath excel activities along with some PC restarts after uninstall and reinstall.

Using Excel and even on a fresh workflow and a Hardcoded filepath (not typed but selected from desktop) the error persisted across all excel files

Has anyone encountered this issue? This is halting a bot from going into production I appreciate any help.

No workflow to share, The error is not workflow specific as even a fresh workflow with just an excel app scope yields the same error.

I donā€™t know what causes this error, but a work around seems to be to add a delay of just one second right before the application scope and another as the first thing inside the scope.

If you using the Two excel application scope , one after other then try using delay between them
that will solve the issue

Unfortunately this did not work. Using this simple workflow excel continues to return a com HRESULT E_FAIL

ExcelisBrokenHelp.zip (13.2 KB)

Did you try unistalling and reinstalling the Excel-package?

Yup.
uninstalled-> saved and ā€˜ranā€™ the obviously broken workflow.
installed ā†’ saved and ran differently broken workflow.

I restarted my machine after the .NET refresh as well

I am currently trying 4.6.2 instead of 4.6

Hi, is this happening on your developer machine or a server? Do you know what changed right before the problems started? What are you UiPath versions?

Developer Machine:

UiPath: 19.10
UiPath System.Activities: 19.10.1
uiPath.Automation.Activities: 19.10.1
Excel activities: v2.7.2

.Net Version has been 3.0 through 4.7 (Due to Azure dev environment with Visual Studio)
Trying to narrow down which one UiPath is using to 4.6.2 since others in the 2018-2019 time period had success with this.

A colleague of mine also just encountered this error with Excel exclusively. The Delay trick did not work either.

The only changes I made were in the Config file but I reverted the changes easily. Additionally my colleagueā€™s issue couldnā€™t be caused by my config file. The bots are attended no server setup yet.

The changes i meant are on the environment itself, like MS Office changes, protection software like antivirus etcā€¦ Unless you are on an old OS like windows 7, you should not need to manually install any version of .NET framework, as this will add an extra set of possible issuesā€¦ to be honest if this pc is for uipath only, it would be even better.

ah, I understand. I am on windows 10
Sadly I am unable to manipulate Antivirus/protection software due to business restrictions.
An update may have been pushed to my computer recently Iā€™ll check the update logs.

Thanks for your engagement.

1 Like

As you suspected changing, or refreshing .NET did not change anything. I did a fresh install of UiPath too after the changes. Iā€™m at a loss for what to try next.

Our RPA team goes as far as to check that the Excel process (exe) is stopped after closing an Excel application scope before opening another.

Wow. I am incredibly surprised that somehow even during restarts across 2 days there was a phantom excel process open in Task manager. I killed it and tried again and it worked.

Thank you so much I will adjust my workflow to try account for this.

Yeah, 60% of our ā€œcodeā€ is self defense against the apps and VDI we are automating and running on. RPAā€™s dirty secret is that robots are pretty unreliable compared to traditional application platforms.

To be honest is a very important part of the processes that they will clean up the environment so next processes or executions will be fine to runā€¦ A lot of those processes that will end up being alive are not something that is 100% avoidable, so it is best practice to have some processes killing at the end of them. :slight_smile:

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.