Welcome to MSDN Blogs Sign in | Join | Help

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.

Published Monday, December 13, 2004 8:51 AM by oldnewthing
Filed under:

Comments

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

Tuesday, December 14, 2004 1:32 AM by Dejan Jelovic
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

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

Wednesday, December 15, 2004 11:25 AM by Raymond Chen
"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?

# Not a kernel guy » Shortcuts, shell and COM apartments.

Wednesday, October 04, 2006 12:20 PM by Not a kernel guy » Shortcuts, shell and COM apartments.

# [翻译]为什么需要单线程套间(STAThread)

Saturday, September 22, 2007 9:23 PM by 神奇小子

讲述了为什么需要STA

# User interface code + multi-threaded apartment = death

Thursday, April 24, 2008 12:20 PM by The Old New Thing

Multi-threaded apartments do not pump messages.

New Comments to this post are disabled
 
Page view tracker