0

I have a C++ 'App1' which was previously built in win32 but is now upgraded to work in x64. The App1 has .tlb files which I used to create COM interop dlls. Previously they used to be registered as win32 but now are registered as win64. The interop dlls are referenced in a c# application 'App2', this app used to be built in AnyCPU platform, but I've changed it to x64.

Here's the code in App2 when it accesses the COM objects;

 objClassType = Type.GetTypeFromProgID("App1COM.App1Application");  

 if (objClassType != null)
 {
      objApp_Late = Activator.CreateInstance(objClassType); //gets stuck in this place for ages then is thrown an exception
      radCmApp = (App1COM.AppApplication)objApp_Late;
      radCmApp.Visible = true;
 }

The exception is as follows;

Retrieving the COM class factory for component with CLSID {4B3D644C-6FC0-4805-9448-E98245F2CE89} failed due to the following error: 80080005. at

System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandle& ctor, Boolean& bNeedSecurityCheck) at

System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean fillCache) at

System.RuntimeType.CreateInstanceImpl(Boolean publicOnly, Boolean skipVisibilityChecks, Boolean fillCache) at

System.Activator.CreateInstance(Type type, Boolean nonPublic)

An instance of App1 does get created, as seen in the Task Manager, but it closes as soon as App2 hits the exception. I debugged this instance of App1 but could not find how the exception occurs, to me it seems like the exception occurs regardless where the debugger is in App1, and at a timed interval. I'm wondering if this is some internal COM issue. I get the same error if I change App2 configuration to AnyCPU.

The x64 App1 works perfectly if I run it independently. The COM link worked when App1 was in win32 and App2 was in AnyCPU/x86, now with x86 I get:

"Could not load file or assembly 'Interop.App1COM, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format."

...which is why I switched App2 to x64.

Any help would be appreciated.

Edit - Adding a pic of the App1 Document (Radial Document) as seen in the Oleviewer.exe (Grouped by Component Category\All Objects) enter image description here

Community
  • 1
  • 1
Madz
  • 1,273
  • 2
  • 18
  • 35
  • 2
    The very first thing I do when writing COM components is to first test it in a _known-good client_, such as _OleView_ (in your case _OleView x64_). If it doesn't work there, it won't work anywhere. At the same time you can **verify** that your **COM component is registered properly**. Otherwise you are just testing two unknowns and don't know where the fault lies –  Nov 27 '19 at 10:56
  • As [this](https://stackoverflow.com/questions/279112/retrieving-the-com-class-factory-for-component-with-clsid-xxxx-failed-due-to-t) mentions it seems a generic error. And hard suggest anything without knowing what you do inside App1Com – Eldar Nov 27 '19 at 10:58
  • 2
    By the way, if your c++ App1 COM server is an _out-of-process_ COM server (an **.exe** server in other words), then it does not matter on Windows x64 whether the COM server is 32 bit or not and the client 64 bit or not. MSDN: _[" On 64-bit Windows, an out-of-process 32-bit COM server can communicate with a 64-bit client, and an out-of-process 64-bit COM server can communicate with a 32-bit client"](https://learn.microsoft.com/en-us/windows/win32/winprog64/process-interoperability)_ –  Nov 27 '19 at 11:04
  • A dll has a header indicating the type of dll (like 32 bit or 64 bit). You cannot take a 32 bit dll and register as a 64 bit dll. – jdweng Nov 27 '19 at 11:21
  • @MickyD I checked it in the OleView.exe (\Program Files\Microsoft SDKs\Windows\v6.0A\Bin) and in the Type Libararies section, you can double click and view the .tlb files properties, methods and such. – Madz Nov 27 '19 at 11:32
  • 1
    @Madz well that just tells your the typelib is registered. What I meant was the server itself by **Component Category\All Objects** .....or **Object Classes\Grouped by Compnent Category\Automation Objects** –  Nov 27 '19 at 12:38
  • That is CO_E_SERVER_EXEC_FAILURE, "Server execution failed". Debugging such errors on the wrong end of the COM connection is not practical. If you're lucky then there's a more descriptive event for it in the Windows application log. Otherwise google "attach debugger at process start" to get ahead. – Hans Passant Nov 27 '19 at 13:27
  • @MickyD, I couldn't find anything in either of those locations with App1 64bit version, but with the 32 bit version there's a 'App1 Document ' node (with a small 'I' in the icon, for interface?) in Grouped by Component Category\All Objects. The problem could be that this node doesn't get created with the 64bit version... My COM knowledge is very limited, so I have no idea why it wouldn't.. – Madz Nov 28 '19 at 12:05
  • @Hans, I debug both App1 and App2, what should I be debugging instead? – Madz Nov 28 '19 at 12:06
  • Well, good, show us what the Output window looks like on the server side. – Hans Passant Nov 28 '19 at 12:23
  • @Hans added an edit with the pic – Madz Nov 28 '19 at 12:33
  • That is OleView, it is not a debugger. The Output window in Visual Studio shows debugger notifications. Hard to help you, be sure to use that Google query I recommended. – Hans Passant Nov 28 '19 at 12:39

0 Answers0