Solution to Excel Automation VB.NET/C# error running as a service 0x800A03EC - Microsoft.Office.Interop.Excel.Workbooks.Open

Overview of issue

When automating excel using a non-interactive session as a service or windows task scheduler it failed with an exception System.Runtime.InteropServices.COMException (0x800A03EC).

This did not happen when the same task was ran from the command prompt as the same user. The stack trace showed it was when we tried to open the excel sheet Microsoft.Office.Interop.Excel.Workbooks.Open

Automating Excel like this is strictly warned against by Microsoft as it is a pain. There are so many possible issues you have to work through.

Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behaviour and/or deadlock when Office is run in this environment.

Microsoft strongly recommends that developers find alternatives to Automation of Office if they need to develop server-side solutions. Because of the limitations to Office's design, changes to Office configuration are not enough to resolve all issues. Microsoft strongly recommends a number of alternatives that do not require Office to be installed server-side, and that can perform most common tasks more efficiently and more quickly than Automation. Before you involve Office as a server-side component in your project, consider alternatives.
Considerations for server-side Automation of Office

However you may manage despite all these strong words to not do it. In our case we had some complex excel documents with complicated formatting that was populated through a datasource that was latterly removed before saving. I didn’t fancy trying that in OpenXML, also we were required to produce old xls type files for output.


I’ve compiled a list to check off from a number of forums, forgive me for not fully referencing it all but links to some of the posts are shown at the end.

Another well presented summary that I found after writing this can be found here: Interactive Excel permissions

The final part of the puzzle was the following post:

I had already blogged essentially the same info below, then found the above resources, I’ll keep my version, just in case those pages vanish from the web.

Add Local Launch and Local Activation permissions to the Microsoft Excel Application DCOM Config

  1. Stop the windows service automating excel
  2. From run start bar, type dcomcnfg
  3. in the Component Services dialog that opens navigate to console root>>computers>>MyComputer>>DCOM Config branch of the tree in the UI
  4. Locate “Microsoft Excel Application” and right click properties of itimage
  5. Find the Security Tab, add the user running the service and grant rightsimage by clicking on the edit button of Launch and Activation Permissions, I granted “alllow” to Local Launch, Local Activation. Go to task manager and check no copies of excel are running in memory by end tasking any excel.exe running under all users.
  6. The above post says to change the Identity tab to “The Interactive User” radio button, you could try this too, although it was the permissions in my case that made things come to life.image
  7. Restart the service automating Excel

Create the mysterious directory

Due to what is thought to be a bug/oversight, a folder is required to exist by Excel when it is ran as a service. Most people find this step solves their problem.

Create a directory “Desktop” if it does not already exist under
“C:\windows\SysWow64\config\systemprofile\Desktop” (for 64 bit operating systems)
– then grant Read & Execute, List folder contents, Read permissions to the user running the service to this folder

More permissions to set

”C:\windows\SysWow64\config\systemprofile\AppData\Local\Microsoft” (for 64 bit operating systems)

For the user running the service grant: Modify, Read & Execute, List Folder Content, Read, Write permissions to the above folders.

Obviously also check, as you normally would that the service user has read execute permissions on the executable directory of your service and any folders it needs to run.

Source post: Run Powershell script as Scheduled task, that uses Excel COM object

UNC Paths

This goes for all services, ensure that paths do not rely on mapped drives. Translate any mapped drives into UNC paths.

N:\myfolder\ should be something like \\mynetworkserver\nfsshare\myfolder

Mapped drives may not be available to a service user.

Comments (9) -

  • Thank you, almost 4 **** days I am on this, I created this **** mysterious folder for 32bit but not for 64 ...
  • i've tried ur solution but i still got an error like this

    "System.Runtime.InteropServices.COMException (0x800706BE): The remote
    procedure call failed. (Exception from HRESULT: 0x800706BE) at
  • hi, i've been tried your solution
    but i still got an error like this
    "System.Runtime.InteropServices.COMException (0x800706BE): The remote
    procedure call failed. (Exception from HRESULT: 0x800706BE) at

    can you help me? Frown
  • Thanks for placing this in the public domain.  It helped me mightily.
  • Great step by step guide. without these informations we never imagine all that misterious things to do to make all ork
  • One of the simplest things to do is, try to open excel/word file, after each change in configuration, service manager etc. This is because after change in any setting, Microsoft application may required re-configuration which may need user interaction. By opening a word/excel file once, ms office application with user interaction/user response/dialogue will perform required actions.
  • Just as a side note, recently had this issue with our work corporate system, which uses remote servers to occasionally process Excel and Word documents.

    If anyone can't find the settings in the DCOMCNFG console, check what version of Word you are using compared to the OS version (i.e. 32 bit VS 64 bit).

    Our server was a Windows 2012 server running 64 bit, but Word was running in 32 bit mode.  As such when running DCOMCNFG nothing showed up.  You need to run DCOMCNFG -32 to see the 32 bit settings and change the user in there.  Once we did this it solved the problem instantly.
    • Tim
      Good point over 32 vs 64 bit!

Add comment