Click here to Skip to main content
15,034,432 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hello all,
I am sorry if this question has already been asked. And sorry for the long post.

Here is my problem.

I have a 64-bit application.
I have a 3rd party 32-bit unmanaged DLL.
I need to establish communication from the 64-bit managed application to the 32-bit unmanaged dll.
Here are the things I've tried:

1. I created a 32-bit wrapper class library, called COM1, and added a COM class that calls the 32-bit unmanaged dll's exposed functions.
The project had "Register for COM interop" enabled.
When I referenced the 32-bit DLL (COM1.dll) to my 64-bit application and executed the application, I received the following exception:
"Could not load file or assembly 'COM1.dll'...An attempt was made to load a program with an incorrect format."

2. I created a 64-bit wrapper class library, called COM2, and added a COM class that calls the 32-bit unmanaged dll.
The project had "Register for COM interop" enabled.
When I referenced the 64-bit DLL (COM2.dll)to my 64-bit application and executed the application, I was able to load the 64-bit dll but I received the following exception when i called one of the functions exposed in the unmanaged dll (via the 64-bit wrapper dll):
"An attempt was made to load a program with an incorrect format."

I understand that i cannot call a 32-bit dll directly to my 64-bit application.
What I am trying to do is call the 32-bit dll through IPC mechanism; in this case COM.
But, obviously, I am making some mistake here.

I tried the above steps using a WCF application as well where i replace the COM wrapper with the WCF service.
But I get the same result.

Can someone give me a working code or tell me what am I doing incorrect in the above-mentioned steps?

Thank you for reading and giving your time.
Really appreciate your help.


What I have tried:

'My COM class

<comclass(comclass1.classid, comclass1.interfaceid,="" comclass1.eventsid)=""> _
Public Class ComClass1
Public Declare Sub InitializePort Lib "I2CDrvrs" (ByVal I2cAddr As Byte, ByVal evalBoardUsed As Byte)
#Region "COM GUIDs"
' These GUIDs provide the COM identity for this class
' and its COM interfaces. If you change them, existing
' clients will no longer be able to access the class.
Public Const ClassId As String = "bd248311-07ca-4d09-a5d1-d4c6b4df0256"
Public Const InterfaceId As String = "f8de730a-d845-44c3-b029-fc556d2e7f0c"
Public Const EventsId As String = "abaf2635-6f30-46f7-a7a9-5a44bef46f9b"
#End Region

' A creatable COM class must have a Public Sub New()
' with no parameters, otherwise, the class will not be
' registered in the COM registry and cannot be created
' via CreateObject.
Public Sub New()
End Sub
End Class

'My 64-bit application
Public Function foo() As Boolean
COM1.ComClass1.InitializePort(2, 2)
Catch ex As Exception
End Try

Return True
End Function
Updated 14-Jan-17 18:49pm
Richard MacCutchan 18-Nov-16 3:27am
You cannot mix 32 and 64 bit code in the same address space.
BishP 3-Dec-16 5:52am
Yes, I am not trying to call the 32-bit dll from the same address space. I am trying to call it via IPC, COM in this case.
Richard MacCutchan 3-Dec-16 6:51am
The issue is the same, you are trying to mix 32 and 64 bit, and I do not think it will work.
BishP 3-Dec-16 7:00am
So is there a way to call the 32-bit dll's APIs from my 64-bit application?
Richard MacCutchan 3-Dec-16 7:23am
Not that I have ever heard of. You could possibly do it by using sockets but it would be a lot of work.
BishP 3-Dec-16 8:48am
Thanks, Richard. I was trying this technique from this blog:
Richard MacCutchan 3-Dec-16 9:27am
Looks like quite a lot of work.
BishP 3-Dec-16 10:11am
Thanks for your patience, Richard. :)
I will post a solution if I find one.
Matt T Heffron 15-Jan-17 1:05am
As stated above you cannot mix them in the same address space.
You need to run the 32 bit COM server as a separate process.
(An out-of-proc COM server.)
Long ago I knew the magic incantation to tell COM to run a DLL in a separate process, but those memory cells are not operational. :-)
My recollection was that it was a fairly simple variation to registering the COM server.
COM would run the service in its own process and would do the marshalling between processes.

1 solution

I have found a rather simple solution to my problem. I implemented a client-server model using Socket Class' methods and properties. I start a 32-bit managed-service code working as the server. The server calls the functions of 32-bit unmanaged dll. So in a way the server acts as a wrapper for the unmanaged dll. I use my 64-bit application as client. I pass a string to the server from my client. The string contains information on the function to be called and its arguments. I parse the string in server and call the appropriate function in the unmanaged dll.
Dave Kreskowiak 15-Jan-17 1:07am
Yep, you Windows does not support mixing two different architectures in the same process. Your COM server runs in the same process as the client, and you cannot mix 32- and 64-bit code in the same process.

As you've already found out, the only solution is two separate processes, one 32-bit and one 64-bit.
Richard MacCutchan 15-Jan-17 3:01am
Why not just convert the 32 bit library to 64, or the 64 bit application to 32?

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900