COM client gets the class object, but always fails on CoCreateInstanceEx with E_NOINTERFACE

Baseline as it is, thank you for your useful comment.  I have since reviewed the installation keys and values relating to this, so far without finding any smoking guns.  For simplicity, all builds, installs and process startups and debugging sessions have always been performed under the same administrator account.

It would seem that with both client and server specifying RPC_C_AUTHN_LEVEL_NONE, COM would always allow calls from anyone (see Essential COM, page 298).

My install uses a script shown below, which substitutes the various <xxx> parameters with the actual names, ids and other strings for any particular install, and puts each resulting line into the registry HKCR .  My uninstall uses a similar script.

"AppID\{<appid>};<comment>",
"AppID\{<appid>};RemoteServerName=<server>",
"AppID\{<appid>};RunAs=<account>",
"AppID\{<appid>}\References\{<classid>};<iname>",
"CLSID\{<classid>};<iname>",
"CLSID\{<classid>};AppID={<appid>}",
"CLSID\{<classid>}\LocalServer32;<module>",
"CLSID\{<classid>}\TypeLib;{<libid>}",
"CLSID\{<classid>}\ToolboxBitmap;shell32.dll,74",
"CLSID\{<classid>}\ProgID;PkgServer.<iname>.1",
"CLSID\{<classid>}\Control;",
"PkgServer.<iname>.1;<iname>",
"PkgServer.<iname>.1\CLSID;{<classid>}"

I am continuing to review this install script and how it is actually applied to the registry, as a possible source of trouble.  None found so far.  

OK, no solution so far, but I have tried a number of things that may have narrowed the possibilities.  Also, I have often found insights into difficult problems through the discipline of explaining the problem to others, even if no one else has anything to add.  So here's what I can now add to the discussion...

(1)  To rule out security conflicts, I cut out my (internal) explicit security settings, and rely only on defaults from OLEview and dcomcnfg.  Then I set launch and activate security to allow "Everyone".  This had no apparent effect.

(2)  Some posts (that I googled for) on this topic have suggested COM may be caching earlier renditions of the component, and ignoring all later changes to its interfaces.  I tried two things to rule this out.  First, I renamed all GUIDs throughout the component, and second, moved all development and testing to an entirely different machine that hasn't seen this COM component before.  These actions had no apparent effect.

(3)  I established that both client and server enter a COM STA, i.e. free threading and MTA are not in use.  Various posts on the topic convincingly argue that my problem can be caused by inconsistent threading models.  However, this does not appear to be the case.

(4)  Another convincing article suggests that proxy stub code may be required to properly marshal method calls between client/server running in separate processes.  Although I expected default marshalling to handle this without further attention, the article explains in some detail how it is that my QueryInterface( ) can be called correctly, return the correct result, yet its invoking CreateInstance( ) call still return "Interface not registered".  No other ideas have explained this anomoly, along with all the other symptoms, so it appears to be highly worth exploring.

So today, I am following up on the proxy stub theory, with two methods suggested by the article: (a) explicity installing the typelib into the registry, and failing that, (b) creating a COM proxy stub DLL for this component and installing it into the mix.

I will post the results of these attempts later today.

Just a couple of things...

1.) Have you seen this: http://msdn.microsoft.com/en-us/library/ms687289(VS.85).aspx  ?
The CoCreateInstanceEx requires structure of item A (see attached code below).
pResults must be array pointer to struct containing your piid. That doc (link above) states that only piid should be sent in. Common return vars, as it says quote on quote, will be "E_NOINTERFACE" if not applied as stated. pITf must be null, and hr must be 0. Make sure you initialize and pass them correctly.
Of course, if you can log some debug data, that would help as well. (Such as the 3 items for this initialization, to ensure they are what they should be)

2.) Do you have the stack trace for that debugger run that took place earlier? If so, please post the stack trace (not assembly -- well i guess that too if u want), so we can see which method calls are taking place. If you can, add debugging symbols to VStudio and set your project debug. That way stack trace will show exactly what we need to see.

No one else has responded, so I will do what I can to help - which may not be much, but am trying nonetheless.
Let us know of the results of: " (a) explicity installing the typelib into the registry, and failing that, (b) creating a COM proxy stub DLL for this component and installing it into the mix.".

Item A:
 
HRESULT CoCreateInstanceEx(
  __in     REFCLSID rclsid,
  __in     IUnknown *punkOuter,
  __in     DWORD dwClsCtx,
  __in     COSERVERINFO *pServerInfo,
  __in     DWORD dwCount,
  __inout  MULTI_QI *pResults
);
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:

(1)  Yes, I know about CoCreateInstanceEx( ), and how to define and setup its various parameters correctly.  I have also used CoCreateInstance( ), since only local servers are being used, but it fails the same way as the former.  Both of these are wrappers for an equivalent CoGetClassObject( ), CreateInstance( ) sequence, which I have also tried, and also fails with "Interface not registered" .  All of these methods are performed in the context of CoInitializeEx (0, COINIT_APARTMENTTHREADED).  I have thoroughly reviewed the client in this area and have confidence in its correctness.  

(2)  A stack trace for the server, i.e. inside the pertinent QueryInterface( ) call, would be very helpful.  I can get that for any application I run directly from the VS debugger, but the server is run by the svhost (??).  If you know a way around that limitation (real or imagined), please summarize the approach.

(3)  I have registered the typelib and interaces with the registry and retested, still failing the same way.  The proxy stub dll is the next thing to try.  The article I have referenced on this can be found at: http://blogs.msdn.com/eldar/archive/2006/02/28/540981.aspx