*CRITICAL* problem with EXCEL crashing - "Microsoft Excel has stopped working"

[BjörnGranacher1]

Hi we have just started with a pilot implementation of some processes in BluePrism during 6 months supported by Accenture. Now when starting to run processes fully unattended via Control Room it shows that Excel frequently, but sporadically crashes. We are using Excel 2016 and the standard "MS Excel VBO". It would be interesting to hear the experience of the community: have you also faced such problems and have you found reliable (!) solutions? The worst is that due to the synchroneous mode BluePrism will just wait forever and be in status "Running", until someone closes that crashing window. In effect it meant that our team was doing full day monitoring and restarting proceses, acting ourselves as robots. For the time we had to stop the automation, until we find a reliable solution. Therefore any experience is highly appreciated! We have now built various test scenarios and run them repeatedly on different environments: physical, VM, storing files locally or on network drives. Also experimenting with "wait" stages and killing the Excel process inbetween. The basic test case is: [Create Instance] [Show Instance] [Create Workbook] then via a counter we go from A1 to A10 and put some data, into the last we put a time stamp to have random data ....using [Set Cell Value] [Save Workbook] using also a counter for new filename [Close all instances] This is repeating in endless lopp. Crashes come between 1min and 60 min (3 to 300 files created) Happy to share our demo also via mail. We see the problem could be solved in these areas: 1) Our platform / infrastructure / Excel installation configuration --> that would be the best way to solve it and we wish we could find some problem there, but after testing on different physical and VM not yet a good conclusion 2) BluePrism MS Excel VBO it is based on code stages and maybe it could be improved? 3) taking care of it in the scripts: exception handling, introducing more save points etc. But first of all: at the moment BP is not aware of the Excel crash and secondly going this direction would mean that a process of typically 100 stages, maybe becomes a process of 200-300 stages where we put more effort into handling potential Excel crashes to achieve some minimum reliability. Thanks for any suggestions and experience! /Bjorn

[Denis__Dennehy]

I have been using the Excel interface (which has not changed much) for over 10 years - so it should be fairly robust/reliable in most instances. Some advice I would give: Send a 'Kill' to the EXCEL process before you first open the first excel document. The Excel application is notorious for leaving orphaned processes lying around in the Windows OS - even when using it manually. Blue Prism 5.0.30 onwards has a timeout option available in Application Modeller for just the kind of sycnronous 'wait forever' you mention in your description. I am not sure if that includes code stages... as Application Modeller is for GUI interfaces.

[BjörnGranacher1]

Hi Denis, thanks for the advice, really appreciated. Especially this timeout seems promising as this is the least we need to be able to handle such issues. I will include that in further testing today / tomorrow. ""Kill Excel process"" we have embeeded in some tests, but mainly inbetween close and new instance, not at the very start yet. Will try. Further, may I ask you if the good experience with Excel VBO is also based on using Excel 2016 version (even with O365 connection)? And in virtualized (VMWare) environments? Regards Björn

[BjörnGranacher1]

Now I understood what you were referring to with the timeouts. These are available with ""Wait"" stages in Object Studio, looking like old clocks.And indeed as you suspected, these are only available for the visual elements that you have spied in Application Modeler. For example you could wait for a button on a webpage or until the whole document / address is loaded. That works nicely and we use that. But it does not help for the Excel VBO which is only based on direct DLL interaction with Excel.

[Denis__Dennehy]

I have never used Excel 2016 (we are due for an upgrade to our office suite to 365 soon) - I have however used our interface on every Excel version between 2000 and 2013 all in virtualised environments. I guess if the Excel documents your are loading are in the cloud rather than local that could impact performance in some way? if so could you not copy to local for processing?

[SaiGajjala_Venk]

Hi Bjorn G, We are currently having similar problem. Excel crashes frequently for every hour, but there is no exception thrown by BP. BP just freezes until we end the EXCEL.exe process in the task manager. I was just wondering if were able to resolve this issue. Thanks, Sai

[MelissaSuarez_G]

How large is the data that you have in those Excel files and what kind of operations are you doing with that information? Are you running many formulas? Depending of what you are trying to accomplish you don't have to open Excel every time. For example, I have a process that used to crash because I was opening Excel to copy/paste data from one place to another (100,000 rows) and applying formulas to it. I change it to do the same thing using VB.net and it's working like a charm.

[Anonymous]

In the Excel VBO bundled with BP 6.0 and up, BP has added timeouts to many Excel actions. These are standard 30 seconds, but can be overridden by the developer. Once the timeout fires, BP can get the control back, and handle the error (kill Excel process?) before trying again. The only issue is that BP cannot distinguish between Excel being unresponsive while importing large datasets or doing large-scale operations, or Excel crashing. Even though this VBO requires a higher version of the .Net Framework (4.7 I seem to recall), it can be imported into a BP version 5 installation. This worked just fine when I tested it.