Accessing a file from an Excel COM object is not performed when the NT service starts in Vista

We use COM objects to access Excel spreadsheets in the NT service (through the Windows Scripting Host). This worked fine before Vista, but starting with Vista, we get this error:

Microsoft Office Excel cannot access the file 'c: \ myfiles \ test.xls'. There are several possible reasons:

  • The file name or path does not exist.
  • The file is being used by another program.
  • The book you are trying to save has the same name as the current open book.

I tried changing the NT service login settings to use my own account, administrator account and local system. I looked at the local security policy and found nothing. I spent days searching Microsoft KB to no avail.

If the script is executed from a console application, it works fine. The file is opened and processed without problems. An error only occurs when executing from a service context.

If the service runs on Windows XP or Server 2003 SP1, it also works fine. Only in Vista does this fail (and now we have received reports of this crash in Server 2003 Service Pack 2)!

The code for which it stands is exceptionally simple:

dim xl_app Set xl_app = CreateObject("Excel.Application") xl_app.Workbooks.Open mypath,0,1 

I suspect this person may have one problem: http://bytes.com/forum/thread819740.html

+6
c # windows-vista vbscript com
source share
2 answers

some additional questions:

  • What version of Excel are you using?
  • Did you try to run the elevated service?
+1
source share

I have a "view" solved this problem. If you use "dcomcnfg" to change the account to run the excel application for the user account or the "interactive user", excel launched from the service runs in that account and now it can access the file system.

The problem is that this is a global setting. If you use: * "This user": then excel ALWAYS opens with this user AND always opens without a user interface in session 0, even for interactive use of excel. IE its always invisible. * "Interactive user": now excel always runs in an interactive user ad, which, I think, will not work for a service that starts at startup without a NO interactive user.

This should have a specific security setting. Hope others have other ideas.

0
source share

All Articles