Different COM thread model used to activate an object for an application running under Local System account compared to same application running under

  • Thread starter Thread starter bogdan_mabo
  • Start date Start date
B

bogdan_mabo

Guest
Hello,

I have an application that can be executed as regular application or as a service under Local System account: app A.

This application launches a second application: app B. The app B uses CoCreateInstance to create an in-process COM object with code in dll D.

The com object derives from CComMultiThreadModel and is registered as supporting Free apartment threading.

When I am using registration free mechanism [manifests files for B and D], the app B fails to create the COM object if app A is started as Windows service [E_NOINTERFACE]. If I execute the app A [requires elevated privileges] from command line it works ok.

NOTE: It works ok either way if I use the regular registration mode - through Windows registry.


In debug I can see that when app A starts as service, then the COM framework attempts to create the COM object in a different apartment ... the object is created in a different thread. While when started from command line it is created in same apartment and same thread.

In both cases, CoGetApartmentType returns [APTTYPE_MTA, APTTYPEQUALIFIER_IMPLICIT_MTA] before the call to CoCreateInstance.

I am pretty sure that it fails because it does not know how to marshal the interface. The question is, why this different behavior?


Some additional details:

  • The code attempting to create the COM object starts on a TppWorkerThread as a result of a RPC call from a third application C.
  • This happens on Windows 10 [did not try any other OS]
  • I tried to call CoInitializeEx(nullptr, COINIT_MULTITHREAD) before the CoCreateInstance but the result was the same.



Thank you,

Bogdan



Vasilescu Bogdan

Continue reading...
 
Back
Top