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.

Yary
  • 101
  • 2
  • 2
    As you may already know, without the code, we'll just be providing guesses. – jscott Dec 13 '16 at 01:50
  • Does the old system have a web server with any configuration differences between it and the new system (in case the original developer had leveraged some functionality not immediately obvious.) Have you confirmed the .Net 2.0 patch levels are consistent between the old and new systems? There was a specific hotfix for .Net 2.0 that message applied to (kb973746). – Enigman Dec 13 '16 at 02:15
  • Without seeing the code that caused the error you're not likely to get an exact answer here. Though, you're likely running into version compatibility problems. The code needs to be updated. – Colyn1337 Dec 13 '16 at 07:03
  • There are web servers on both the old and new systems- IIS- and I will check the patch levels & update the question... (and If I had the source code, I'd post in StackOverflow!) – Yary Dec 13 '16 at 16:08

1 Answers1

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.

Yary
  • 101
  • 2