winapi - Prevent out-of-proc server shutdown while it has loaded in-proc server object instances -

winapi - Prevent out-of-proc server shutdown while it has loaded in-proc server object instances -

i have application uses out of process com server access com object created in-proc com server. means out of process com server has load in process com dll create final object return.

for example:

// create object resides in out of process com server container.cocreateinstance("helperserverprocess"); // grab reference object resides in in process com server dll, // hosted out of process com server object = container.generateresults(); // release object instantiated out of process server container = null; // or return, or go out of scope, etc // phone call fail, because out of process server has shutdown unloading // inproc dll hosting <object> object.dostuff();

however, 1 time container object released, final server process reference (in coreleaseserverprocess ) released, , server shuts down. results in e_rpc_server_unavailable error when trying utilize result object. @ same time in-proc dll hosted in exe server still has outstanding objects , therefor returns s_false canunloadnow.

i think adding iexternalconnection exe server 's class mill manually reference counting on remote references not help, because objects registered dll in-proc server utilize dlls class mill , seek using iexternalconnection on factory. also, if server spawns interactive kid objects in process space wouldn't trigger iexternalconnection either way.

it isn't possible modify dll's reference counting utilize coaddrefserverprocess / coreleaseserverprocess dll doesn't have access container's shutdown code in case triggers lastly release, , 3rd party dlls can't changed anyhow.

the method can think of might work adding loop after server refcount hits zero, calls cofreeunusedlibraries, , somehow enumerates loaded com dlls , waits until none loaded , ensures server refcount still zero. leak processes if loaded dll not implement canunloadnow correctly, , involves messing around low level com implmentation details avoid.

is there easier way ensure com objects instantiated class factories of in-proc servers maintain process alive, or enumerate class factories of dlls loaded current process , query them number of references?

update: method may work, sounds much sort of things aren't supposed do: intercepting every spawned thread in process, registering coinitialize hook via coregisterinitializespy, , adding server process reference every thread has com initialized.

the out-of-proc exe can delegate dll object rather homecoming directly. have getresults() homecoming object exe implements, , have implementation utilize dll internally needed. way, exe not released until caller releases exe's object, keeping exe's own refcount active. exe's object can implement same interface dll object implements. way, caller not know (or care) delegation beingness used.

winapi com