Why do I get E_NOINTERFACE when creating an object that supports that interface?


I've seen a few questions from people who call the CoCreateInstance function, asking for an interface that they know the object supports, yet receiving error E_NOINTERFACE. What's going on?

You're seeing the same problem as the missing IMarshal, just from the other side.

If your threading model is incompatible with the threading model of the object you're creating, then COM marshalling kicks in. And if the marshalling stuff isn't there, the error that comes out is E_NOINTERFACE, because the marshalling interface is missing.

A common source of this is attempting to use COM objects provided by the shell from a multi-threaded apartment. Remember that shell COM objects are, for the most part, apartment-threaded, not free-threaded. If you want to use shell objects, you should do so from single-threaded apartments.

Comments (5)
  1. Anonymous says:

    Raymond,

    Speaking of shell objects: is there anything weird/different in the way the Network Connections folder is implemented?

    I’m asking because I’m unable to extract the icons of various Network Connections using IExtractIcon.

    IExtractIcon::GetIconLocation returns "netshellicons", with a large negative index. But a subsequent call to Extract fills in NULL for both small and large icons, and returns S_OK?

    BTW, the docs on IExtracIcon::Extract are wrong. They say that pIconLarge and pIconSmall can be NULL, when in fact many shell folders will choke on NULL values for these parameters.

    Dejan

  2. Anonymous says:

    "Speaking of shell objects" – that’s a pretty tenuous segue. The main point of the article was marshalling, not shell objects.

    Okay I spent a half hour writing a test app to extract icons from Network Connections items and it works fine. I call Extract and an icon comes out. I had to do this because if I didn’t, you’d accuse me of ignoring you. As if there was some requirement that I address all issues raised. I don’t get paid for this you know.

    As for implementations that have bugs in their Extract handlers: Is it the job of an interface’s documentation to describe the interface contract? Or is it to describe how people violate the contract? If the latter, then do you need to write (for every externally-implementable interface) "Since this interface is implemented by third parties, any number of bugs may exist in those implementations."? Or just list the most popular bugs?

  3. Anonymous says:

    讲述了为什么需要STA

  4. Anonymous says:

    Multi-threaded apartments do not pump messages.

Comments are closed.