Unable to cast COM object of type exception

Question

I have the following code:

public void Test(IMyInterface iInterface)
{
  iInterface.CallMethod ( );
}

Which works fine. However, if I change the code to be threaded:

private IMyInterface myInterface;
public void Test(IMyInterface iInterface)
{
  myInterface = iInterface;
  new Thread ( new ThreadStart ( CallInterfaceMethod) ).Start ( );
}

public void CallInterfaceMethod ( )
{
  myInterface.CallMethod ( )
}

When i use the thread I receive the exception:

Unable to cast COM object of type 'System.__ComObject' to interface type 'IMyInterface'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{GUID}' failed due to the follow error: No such interface supported

But the interface should be supported just fine? Anyone have any thoughts on what is going on here?

Ambiguous

blogs.msdn.com/b/oldnewthing/archive/2004/12/13/281910.aspx – Devaluate

Answer 1

This nasty, nasty exception arises because of a concept known as COM marshalling. The essence of the problem lies in the fact that in order to consume COM objects from any thread, the thread must have access to the type information that describes the COM object.

In your scenario described, the reason it fails on the second thread is because the second thread does not have type information for the interface.

You could try adding the following to your code:

[ComImport]
[Guid("23EB4AF8-BE9C-4b49-B3A4-24F4FF657B27")]
public interface IMyInterface
{
    void CallMethod();
}

Basically the declaration above instructs the .NET framework COM loader to load type information using traditional techniques from the registry and locate the associated type library and go from there.

You should also restrict the creation of the COM object to a single thread (to prevent thread marshalling) to help solve this issue.

To summarize, this error revolves around type information and thread marshalling. Make sure that each thread that wants to access the COM object has the relevant information to unmarshal the object from the source thread.

PS: This problem is solved in .NET 4.0 using a technique called "Type Equivalence"

Gordon

Thanks for the reply. Your explination makes sense and looking up the ComImport decleration on the MSDN seems to also make sense. Cheers. – Ambiguous

It's my pleasure:) I've run into this issue before and it was a nightmare to try and solve, until the lightbulb went off and I ended up consuming the COM object from the thread that created it. – Gordon

[+1] Thanks a lot guys! For me the error was that [STAThread] was missing. This question and answer led me to find it after reading the threading problem. – Yahairayahata

The ComImport and Guid was it! I was struggling with the same casting exception (nothing to do with threading) to make my wrapper unit testable and to isolate COM component. Thanks! – Bloodletting

Answer 2

I got an advice and it helped me!

Find in the main thread (Program.cs) the line [STAThread] and change it to [MTAThread].

Imposition

It worked like a charm.Can you please explain the change ? – Rachellrachelle

Answer 3

I've been developing a C# application which uses 7-zip through COM interfaces. I ran into this funny thing where I was able to extract archives from a worker thread in one instance, but not another, getting this same exception.

I found that, so long as you initialize the offending COM object in the thread where it is used no exception is thrown. My solution was to dispose the objects which utilized COM interfaces and re-initialize them when passing them between threads.

Kanchenjunga

Answer 4

Well, for one, you are making a cross-thread call to an object without locking it, this automatically will cause some issues. Your code should look more like:

private IMyInterface myInterface;
private static readonly object _myObjectLock = new object();

public void Test(IMyInterface iInterface)
{
     myInterface = iInterface;
     new Thread ( new ThreadStart ( CallInterfaceMethod) ).Start ( );
}

public void CallInterfaceMethod ( )
{
     lock(_myObjectLock)
     {
        myInterface.CallMethod ( );
     }
}

From what I understand, the error you listed can sometimes occur when the resource cannot be accessed, which, with a cross-thread operation like this, would most likely happen. Don't quote me on it though, I'm no COM expert.

Truthfully, I don't think I would approach calling this method in this fashion, way too many risks in doing so. Have you considered using a ParameterizedThreadStart and passing the object through that way? You'd still need to safely lock your objects for the cross-thread operations, but it would be safer.

Furthermore, check to make sure that your "myInterface" class can still call the "CallMethod()" method. Interfaces have no implementation, you may be running into problems when you set "myInterface = iInterface".

Aero

Than you for the answer, but using ParameterizedThreadStart does not work either (With or without the lock). Also I have checked, myInterface can still "CallMethod" once it has been set (myInterface = iInterface). – Ambiguous

There's two bits of misinformation in this answer: 1. Cross-thread object access doesn't always automatically cause problems. Locking should not be necessary with read-only accesses, for example. 2. Regarding the last paragraph, you cannot pass around interfaces as objects, so even if you assign a non-null object to a variable with a interface (static) type, and the code compiles, then all these methods can be called. Think of the static type (interface) as some kind of façade for another implementation type. – Defamation