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?
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).
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.
