CoCreateInstance & CO_E_SERVER_EXEC_FAILURE (0x80080005)

[Nicolas Koulouris]

I have posted a while ago about a problem with an "external" application
that runs in a Custom Action and activates an interface. The call to
CoCreateInstance returns CO_E_SERVER_EXEC_FAILURE after a long timeout.

My recent findings are that the problem still exist if the activation
attempt takes place in the Windows Installer host process (this eliminates
the possibility that impersonation might not be done correctly at the
"external" process level). I have verified this by placing the code in a CA
Dll. On the other hand, a simple COM object (dummy) is activated without
problem, from a separate process or a Dll.

My indication is that some right may be lost when the Windows Installer does
impersonate the client (the interactive user), for instance the "Logon as a
Batch Job" right required to activate an interface on a remote server. There
may be other causes as stated at this URL, and they seem to rather designate
the server as being the source of the problem, namely when it is running as
a distinguished principal :

http://www.develop.com/kbrown/com/secfaq.htm#ServerExecutionFailed

One of the problems that displays a similar behavior in regard to the
timeout occurs when the server does not call CoRegisterClassObject in a
timely fashion.

Finally COM Security might be set for the specific interface
(IMessengerAddInManager) which is not wrong in essence, especially if it is
publicly distributed as part of the Windows Messenger Add-In SDK by
Microsoft. I have contacted their development team for details.

Regards,
--
Nicolas K.

[George Zheng [MS]]

Hi,

Did you monitor the event log on the client computer and the server
computer? The event is more helpful to solving your problem.

This posting is provided "AS IS" with no warranties, and confers no rights.

George Zheng [MSFT]

[Nicolas Koulouris]

Hello,

Thanks for your answer. I did monitor the Event Log but I found rather
obvious informations like this :

The server {FB7199AB-79BF-11D2-8D94-0000F875C541} did not register with DCOM
within the required timeout.

Which is exactly my problem :-) I have done another test. This time I use an
interface that resides in a exe server. When I activate it from the Windows
Installer, it hangs too, if the server process is already loaded in memory
(it also creates a second process instance). If the process is stopped prior
to activating the interface it will work.

Problem here is that I need to activate that interface in order to stop the
server!

Again here, if I activate the interface from a process like an MFC dialog
application everything works fine.

So alright, the WI accesses the interface through DCOM. But why does it hang
is my question. If the user can access an interface locally, he should also
be able to access it in a local installation through WI. If it can't, then
at least a workaround is necessary. I currently don't have one.

Nicolas K.

"George Zheng [MS]" <geor...@online.microsoft.com> wrote in message
news:Soi5elQvCHA.2304@cpmsftngxa06...