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

Date:December 13, 2004 / year-entry #419
Tags:code
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20041213-00/?p=37043
Comments:    5
Summary: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...

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. Dejan Jelovic says:
    December 14, 2004 at 1:32 am

    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. Raymond Chen says:
    December 15, 2004 at 11:25 am

    "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. Not a kernel guy » Shortcuts, shell and COM apartments. says:
    October 4, 2006 at 12:20 pm

    PingBack from http://blog.not-a-kernel-guy.com/2006/10/04/76

  4. 神奇小子 says:
    September 22, 2007 at 9:23 pm

    讲述了为什么需要STA

  5. The Old New Thing says:
    April 24, 2008 at 12:20 pm

    Multi-threaded apartments do not pump messages.

Comments are closed.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index