32-bit COM client encounters exception on consecutive calls to 64-bit surrogate-hosted COM object that makes calls to native code

Question

---

EDIT: Question updated from information gleamed from comments below

---

Client: 32-bit COM client

Server: 64-bit COM in-process server configured to run out-of-process. Server makes calls to native c++ code

I am trying to run an out-of-process COM object with the help of dllhost. The 32-bit test client runs fine with each individual test case. However when I try to run the cases consecutively using a batch file, it crashes with the InteropServices.COMException: RPC failed (HRESULT 0x800706BE) . Each test case is a program with the following structure

var ComType = Type.GetTypeFromProgID("My.COMClass");
var ComObject = Activator.CreateInstance(ComType);
ComType.InvokeMember("SomeFunction", BindingFlags.InvokeMethod, null, ComObject, null);
Marshal.ReleaseComObject(ComObject);

The crash happens when I run the test in with the following fashion

//test1.bat
TestA.exe
TestB.exe //crash
//test2.bat
TestB.exe
TestA.exe //crash

There is no problem when I run each test individually. I also noticed that if I wait for the dllhost process to completely finish (and disappear) before calling the next test, the whole batch file will run without problem.

//test3.bat
TestA.exe
pause //wait a few seconds then press enter
TestB.exe //ok

Since each test run perfectly individually I assumed the code was fine and it's just a problem of how I executed the tests however I couldn't find anything about this problem so I'd appreciate any insight on this

The 64-bit COM server is actually just a COM wrapper for a C++ dll, we wrote the wrapper based on this. It's also worth mentioning that my original C++ dll was working normally before attempting the COM wrapper

Answer 1

I have found the cause of my problem. It's because my original C++ dll is creating threads to handle concurrency on its own and According to Inside COM+: Base Services, COM object code isn't supposed to do that

Since the system automatically spawns threads as necessary to enable concurrent access to the component, you should avoid calling the Win32 CreateThread function. In fact, calling CreateThread to enable concurrency in a component is strongly discouraged because in most cases this will interfere with the system's threading pooling algorithm

I'm still not entirely sure how the thread handling can lead to this problem so it would be great if someone can share a more detailed explanation but for now, it's fine as long as I remove the multi-thread code in the C++ dll.