Excel-automating .Net code has "Catastrophic failure" error from Interop on new server

0

I'm migrating from a Windows Server 2008 R2 box with Excel 2003, to a different box running Windows Server 2012 R2 with Excel 2013.

Part of the migration is moving code that reads text files and spits out Excel files by running excel in the background. These are .Net 2.0 programs written by someone not around now (I could contact the author but have no budget to ask for help... I should be paying you, dear reader!)

The directories of the tool & input files are the same on both machines, and when I run the command on the old server, it writes an Excel file in a few seconds. When I run it on the new server, it gives me this error:

Unhandled Exception: System.Runtime.InteropServices.COMException (0x8000FFFF): Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))
   at Microsoft.Office.Interop.Excel.ApplicationClass.get_Hinstance()
   at Pareto_Reports_v10dot5.Pareto_Reports.Main(String[] args)

ProcessExplorer shows a new Excel process- so the tool did get as far as launching it- with this command line:

"C:\Program Files\Microsoft Office\Office15\EXCEL.EXE" /automation -Embedding

When I look up the "Catastrophic Failure" error, I see posts about IIS and code in development, but I'm running this working-in-other-environment exe from the command line- those other posts don't seem to apply.

If you need any further info, just ask...

Edit- the old machine has .Net versions 2.0.50727.4927 & 3.0.30729.4926 & 3.5.30729.4926

The new has versions 2.0.50727.4927 & 3.0.30729.4926 & 3.5.30729.4926 & 4.0.0.0 & 4.5.51641 (all versions viewed from regedit)

I don't have the source code. Will ask about getting it; if it's still around then this question will change quite a bit.

Was hoping it was a simple issue of some new security feature in Excel 2013 or Windows 2012, but apparently not so simple.

migration
automation
.net
microsoft-office
asked on Server Fault Dec 13, 2016 by Yary • edited Dec 13, 2016 by Yary

1 Answer

0

There were two points of failure:

Calling Interop.Excel.ApplicationClass.Calculate() triggered something in the workbook that required a VBAProject module "Microsoft Windows Common Controls 6.0 (SP6)". I was able to bring that over from the old server, by running this on the new server:

cd C:\Windows\SysWOW64
copy \\Old-server\C$\Windows\SysWOW64\MSCOMCTL.OCX .
regsvr32 MSCOMCTL.OCX

The 2nd crash required changing the C# source code. It was attempting to log the value of Interop.Excel.ApplicationClass.Hinstance which was throwing an exception. I don't know what Hinstance was exactly or why it went away, but since the code did nothing with it other than log the value, erasing it fixed that issue.

answered on Server Fault Dec 15, 2016 by Yary

User contributions licensed under CC BY-SA 3.0