Invalid Class String - Has always worked but suddenly this error

[mark_in_atx]

I have a WBT script that begins with:

oApp = ObjectGet('', 'Excel.Application')

I have used this program for months with no problems. Now every time I run it I get error "1727: COM: Invalid class string"

The WBT runs fine on my other computers, it seems as if something happened on this computer to de-register (?) excel.application, even though Excel seems to work fine.

Any ideas on how to fix this issue? My only guess is there was some kind of Windows Update that messed things up.

[JTaylor]

Maybe uninstall and reinstall Excel?

Jim

[mark_in_atx]

I looked and sure enough there was an Office update a few days ago. I went to the Control Panel:Programs:Programs and Features and then Change:Repair Microsoft Office. A few minutes later the repair was done and everything works A-OK!

[td]

I remember reading ~someplace~ (don't recall where) that this has been an issue with a recent Office update for some users. It has something to do with corrupted registry entries and I do remember that the recommended solution was to do exactly as you have done.

[stanl]

Not sure what version of Office you have but with 2016 GetObject(,"Excel.Application") is pretty useless.  The workaround seems to be using


System.Runtime.InteropServices.Marshal.GetActiveObject("Excel.Application")


which implies writing the .wbt to include the CLR.

[td]

It depends on the version of the OS, as well.  Generally, for pre-Office 16 version, if Excel is given the chance to register in the ROT, you can get GetObject to access a running Excel process on Windows 10.   The key is to run the script with the same integrity level as the Excel process. In most cases, this would require running the script in a file with the ".wbt_if" extension.  I have not tried this with Office 16 because I am stubbornly refusing to give MSFT more money but I suppose...  It is inevitable. It would be nice to investigate what is going on in Office 360 16.   Also, the OP would have gotten an 1129 error if he had encountered ROT or UAC issues.

[stanl]

I just ran this simple test for GetActiveObject() with a spreadsheet open and get invalid class string

Code (WINBATCH) Select Expand



ObjectClrOption ( 'useany', 'System')
oM = ObjectClrNew('System.Runtime.InteropServices.Marshal')
Message("InteropServices",oM)
oXL=oM.GetActiveObject('Excel.Applicaton')
Message("Excel GetObject",oXL)
oXL=0
oM=0
Exit


[td]

I get the same error with dotNet but  "GetObject(,"Excel.Application")" works just fine as long as I run the script and Excel with the same integrity level.

[stanl]

I get the same error with dotNet but  "GetObject(,"Excel.Application")" works just fine as long as I run the script and Excel have the same integrity level.

As I have no need or requirements for GetObject() - but since I originally received the same error as the OP it was worth exploring.  I set up a 32 bit ROT viewer and saw that Excel was included when I opened a workbook. GetObject(,"Excel.Application") and GetObject(,"Excel.Application.16") both error with Oleinitiate.  Like I said it is 32 bit Office 2016 on Win10, my UAC is off and I run just a .wbt.  But GetObject(path+file) works so I at least know the file has been opened.  Bottom line you can Google a bit of frustration with GetObject() and Excel 2016, so we're probably beating a dead horse here and the OP is happy the issue is solved.

[td]

If you using an admin account, are using the WBT extension for your script file, and have UAC "off" (UAC prompting is turned off) on Windows 10, it is almost guaranteed that "GetObject(,'Excel.Application')" will not work. That is because Excel is running with medium integrity and WinBatch is running with high integrity.

The FCL has its own set of trust levels and the guess is that you would need to fiddle with that in order to access a ROT object via the framework.   IIRC, you can find some reference to that in MSFT's documentation for the method you are calling.

[stanl]

Got it. Just hard to believe Excel is lacking in integrity ;D

[td]

I guess you can't trust what MSFT is doing with all the Office 360 user data they collect.

[stanl]

I guess you can't trust what MSFT is doing with all the Office 360 user data they collect.

I put my 10 bucks down for the Abelsoft Win10 Privacy Fix. It looks neat but I suppose a decent programmer could replicate it.

[td]

Not familiar with that bit of software.  I re-wack the appropriate registry keys and rename a few files after every MSFT update and software install.   For ten bucks it might be worth a purchase just to see what I missed.