Use Com class from LocalSystem

Question

I'm using a Com object. The com server should be used from a Windows service running as a specific account. But when running in this account it can't load the com, giving me this exception: Creating an instance of the COM component with CLSID {36998A63-857C-4B87-BC5E-72B7B3573F80} from the IClassFactory failed due to the following error: 80010105.

I tried changing the account to LocalSystem, that still fails, but changing the Windows service to log on as my own account works.

I guess it has to do with the com server being installed on my account. I install the com using "it's name.exe /regserver". I tried running the command as LocalSystem and it then fails with an assert. I don't have the code, so I don't know where the problem is, is there a permission I should should check? I also tried switching embed interop type in Visual Studio.

Any help?

Answer 1

I just found this, from our friend Hans Passant, on a Microsoft newsgroup thread. It's so good and pertinent I hope Hans won't mind me quoting it.

Ah, the dreaded RPC_E_SERVERFAULT. RPC installs an SEH handler in the stub that catches any SEH exception the occurs in the COM server. Even the really bad ones like AV. The client is notified about the exception with 0x80010105. Which is awful, there's no way to get any information whatsoever about the exception. Even worse, the server just keeps running, now typically with a radically messed up internal state due to the exception. There's nothing you can do about it but trying to debug the COM server to find out why it is throwing exceptions. If it is a black box to you, you'll have a heck of a time without support from the COM component vendor.

Answer 2

The error you are seeing is RPC_E_SERVERFAULT, which means that there has been a unhandled Win32 exception (e.g. perhaps an access violation) in the out-of-process COM server. If you have neither source code nor debug symbols for the COM server, you're unlikely to be able to diagnose this or fix it yourself. (EDIT: Unless it's something obvious like a mismatch of "bitness" on a 64-bit machine :-))

Options:

• if you ought to be able to activate the server and consume its COM objects in the context of your service's account, then you will need to raise this with the vendor of the server and get them to diagnose and fix it;
• you can use DCOMCNFG.EXE (Identity tab) to configure the COM server to run under your identity instead of the default (which is "the launching user"), and see whether this avoids the faulting problem (it sounds from what you say that it probably will).