locked
CoCreateInstance failing RRS feed

  • Question

  • Hi, I’m trying to use a 64-bit DLL from a 32-bit application.  I have set up an out-of-proc COM service that is 64-bit that loads the DLL in question and wraps its functionality with COM objects.  The code that creates the object is as follows:

     

    hr = ::CoCreateInstance(__uuidof(MyClass), NULL,

                            CLSCTX_LOCAL_SERVER | CLSCTX_ACTIVATE_64_BIT_SERVER,

                            __uuidof(IMyClass), (LPVOID*)&m_pMyClass);

     

    This fails regularly with E_NOINTERFACE, but it appears to be a communication issue.  I break in the server code on creation (I use a custom class factory), and the IID passed in is bogus.  It’s passed in by reference, and it appears to be a NULL reference.  The Locals window shows the value as {????????-????-????-????-????????????}.  This fails down in ATL’s code when it tries to test to see if an interface with that IID is in the map.  But just to see if I could hardcode the thing and make it work for the present, I substituted the proper IID in the class factory.  I can watch that IID go down into the ATL code and succeed, but even though my class factory return S_OK, when I get back to the client side, it still gets a return value of E_NOINTERFACE, and object creation fails.  I am stumped and don’t know where to look.  Any help would be greatly appreciated.


    Best regards Daniel
    Tuesday, January 18, 2011 9:57 PM

All replies

  • On 1/18/2011 4:57 PM, SPAMfighter wrote:

    Hi, I’m trying to use a 64-bit DLL from a 32-bit application.  I have
    set up an out-of-proc COM service that is 64-bit that loads the DLL
    in question and wraps its functionality with COM objects.

    This fails regularly with E_NOINTERFACE

    How is your interface marshalled? Is it an automation-compatible interface (in which case you need to register a type library for it) or non-automation interface (in which case you need to build and register two proxy/stub DLLs for it - one 32-bit and another 64-bit)?


    Igor Tandetnik

    Tuesday, January 18, 2011 10:32 PM
  • Hi Igor,

     

    I'm working with Daniel on this. We are using non-automation. We have a proxy/stub DLL, but we aren't using two... that's probably the problem. It took a little bit of research to figure out how to successfully build the 64-bit version of the proxy/stub DLL, but that has done the trick.  Thank you so much for your insightful question!

    Is there perhaps a resource you could point us to for this? Without some nifty tricks, it appears we will have to rebuild the 32-bit version of the proxy/stub, and then rebuild the 64-bit version of the proxy/stub, because the two builds need to overwrite each others auto-generated files, and without issuing a rebuild each time, they come up with linker errors because they just try to use the previously auto-generated files... in any case, this is an acceptable solution, and you have just saved the last few clumps of hair I had left from being pulled out :-)

     

    Thank you!

    Chris


    Chris Ellis Developer SPAMfighter
    Wednesday, January 19, 2011 4:54 PM
  • On 1/19/2011 11:54 AM, ChrisEllisSPAMfighter wrote:

    I'm working with Daniel on this. We are using non-automation. We have
    a proxy/stub DLL, but we aren't using two... that's probably the
    problem. It took a little bit of research to figure out how to
    successfully build the 64-bit version of the proxy/stub DLL, but that
    has done the trick.  Thank you so much for your insightful question!

    Is there perhaps a resource you could point us to for this?

    No idea, sorry. I've never actually done anything like this. I just made an educated guess, from first principles, that you would need two different flavors of proxy/stub DLL.

    The proxy/stub DLL needs to be loaded into both the client and the server processes. And since in your case they have different bitness, and the DLL must match the bitness of the loading process, it stands to reason that you would need two of them.


    Igor Tandetnik

    Wednesday, January 19, 2011 5:09 PM