1

I have a .net program that interacts with Excel spreadsheets using the standard Microsoft.Office.Interop.Excel library. The program takes a file path as a command-line argument, and it runs fine on its own.

I also have a Windows Service that implements a file listener to detect changes in a certain directory. When a new file is detected, the Excel program is called along with the file path.

This execution starts off fine, but once the Excel program tries to open the file:

wb = excel.Workbooks.Open(FileName);

it crashes with the following error:

System.Runtime.InteropServices.COMException (0x800A03EC): Exception from HRESULT: 0x800A03EC
   at Microsoft.Office.Interop.Excel.Workbooks.Open(String Filename, Object UpdateLinks, Object ReadOnly, Object Format, Object Password, Object WriteResPassword, Object IgnoreReadOnlyRecommended, Object Origin, Object Delimiter, Object Editable, Object Notify, Object Converter, Object AddToMru, Object Local, Object CorruptLoad)

Note that the code runs fine on its own, but when the program is called by the Windows service, it fails.

I've done plenty of searching for this issue, but none of the solutions I've found apply to my case. Notably, I've tried changing the component services (according to this post), but there is no Excel component in my DCOM Config at all.

Any suggestions are greatly appreciated!

Benjamin Braun
  • 15
  • 4
  • How is your service running? Is it running under an interactive user account? – Ian Robertson Jul 22 '19 at 17:24
  • is your service running as a specific user? – CarCar Jul 22 '19 at 17:27
  • 1
    Office automation is not designed to run under headless service accounts, and even if you are successful, you will end up with Excel processes lingering in the background (not gracefully shutting down) and run out of memory as a result. You can get third party components which are designed to work on a headless service. – Ian Robertson Jul 22 '19 at 17:30
  • @Ian Robertson Thanks for the suggestion! I've tried running the service under my personal user account, but I ended up with the same error. I guess I'll start looking for workarounds. Thanks again. – Benjamin Braun Jul 22 '19 at 18:23
  • You may want to run the DCOM config as 32 bit to see if Excel is there. (If I remember right 32 and 64 bit configs are independant.) Also, I believe even if you do this, someone needs to be logged into the system for it to work properly. And even then, the logged in user may see popup dialogs from Excel. - At least for the scenario that i needed it set up for. – Wiz Jul 22 '19 at 19:27
  • I couldnt remember the component I turned to when Excel let me down, but I had a brainwave this morning! https://products.aspose.com/cells/net – Ian Robertson Jul 23 '19 at 06:41

1 Answers1

2

The error code 0x800A03EC (or -2146827284) means NAME_NOT_FOUND; in other words, you've asked for something, and Excel can't find it.

Just a thought: are you trying to open an excel file relative to the installation path of the application? Keep in mind, when running a windows service, the working directory isn't the same as where the application is installed.

Services are started from an application called Service Control Manager. This application lives in the system directory %WinDir%\System32

So, if you start your application from console, the working directory is the same as the directory where your application is installed. If the excel file is a local file, or relative to the installation path of the application, it will run just fine. However, when running as a windows service, it will look for the file in, or in a relative path from the %WinDir%\System32 directory.

If the above is the case, try using an absolute path (preferably configurable in the appsettings for example) or set the working directory properly.

Thomas Luijken
  • 657
  • 5
  • 13