locked
ATL Sink in .NET process

    Dotaz

  • Hello,
     
    I have an Win32 MFC application with GUI. This GUI invokes a ATL COM client/DLL that acts as a sink to a connectable ATL COM server. Everything works well. So I have 3 components here- MFC GUI app, COM client/sink and COM event server.
     
    Now, I need to replace this native MFC C++ GUI application with .NET application. So I imported the COM dll that acts as sink into my .NET application and all interfaces were available as expected. When I make a specific method call in this COM dll/object, this method establishes sink connection with COM server (using AtlAdvise) without any issues. However, when the COM server raises an event, the call reaches the sink, but it fails in InvokeFromFuncInfo (specifically it DispCallFunc fails) from ATLCOM.h giving Access Violation error (0xC0000005). So to represent this:
     
    1. .NET GUI ---create instance--->>> COM DLL (SINK) ---establish connection --->>>> COM Event Server
     
    2. COM Event Server ---raise event--->>>ATLCOM.h (in COM sink DLL) fails in DispCallFunc with Access Violation (0xC0000005).

     

    The above flow works perfectly well with my MFC GUI.
     
    Is there anything required for this connectionable object or sink that I may not be setting in my .NET appliaction? How can I at least delve deeper to see what is going on?
     
    thanks!
    Vikram

    1. března 2012 18:42

Všechny reakce

  • you need show some code to explain your error.

    6. března 2012 9:11
  • Below I have given some code snippets and explanation:

    ///Event Server (ATL COM, Visual Studio 6.0)////////

    //Event
    CServerConn::UpdateInfo(BSTR bstrName, BSTR bstrAddress)
    {
     return Fire_UpdateInfo(bstrName, bstrAddress)
    }


    ///Fires event
    class CProxy_ISvrConnEvents: public IConnectionPointImpl<T, &DIID__ISvrConnEvents, CComDynamicUnkArray>
    {

     HRESULT Fire_UpdateSimInfo_New(BSTR bstrHost, BSTR bstrAddress)
     {
      int nConnections = m_vec.GetSize();
      for (nConnectionIndex = 0; nConnectionIndex < nConnections; nConnectionIndex++)
      {
       IUnknown* pIUnknown= NULL;
       CComPtr<IUnknown> sp = pIUnknown = m_vec.GetAt(nConnectionIndex); 
       IDispatch* pDispatch = reinterpret_cast<IDispatch*>(sp.p);
       pDispatch->Invoke(...);

      }
     }
    }

     


    /////Event Sink DLL (ATL COM, Visual Studio 6.0)///////////

    HRESULT hSvrConn = pISvrConn.CoCreateInstance (__uuidof(SvrConn));
    HRESULT hSvrSink = pISvrSink.CoCreateInstance (__uuidof(SvrSink));
    AtlAdvise((IUnknown)pISvrConn, (IUnknown*)pISvrSink, DIID__ISvrConnEvents, pdw);
    ///Subscribed to event here

     

    ///.NET C# Application (Visual Studio 2010)
    int hr1 = CoInitializeEx(IntPtr.Zero, CoInit.MultiThreaded);
                CoInitializeSecurity(IntPtr.Zero,
                    -1,
                    IntPtr.Zero,
                    IntPtr.Zero,
                    (uint)RpcAuthnLevel.None,
                    (uint)RpcImpLevel.Impersonate,
                    IntPtr.Zero,
                    (uint)EoAuthnCap.None,
                    IntPtr.Zero);
    ///Above 2 lines needed for Advise in Sink to work

    //Interop assembly- create instance
    SvrDLLLib.SvrConnect svrConn = new SIMDLLLib.SvrConnect();
    svrConn.StartOperations(); //Start process. Expect events raised in sink dll

     

    When event is raised, InvokeFromFuncInfo from ATLCOM.h gets called in event sink. But DispCallFunc call fails giving Access Violation error.

    Another strange thing is, if I develop a simple console C++ application in VC++ 6.0 and use it instead of .NET C# application, it works. However, same C++ code written in Visual Studio 2010 does not work and fails at same location with same error.
    So looks like Visual Studio is adding some extra layer, but I can't tell what it is.

    8. března 2012 20:17
  • Hi Vikram

    We have an almost identical problem and wondered how you are getting

    on with this. Have you fixed it or created a workaround?

    Thanks

    13. prosince 2012 11:12
  • I doubt .net is anything to do with it! old theory, not remember it fully now. COM component sometime require window message processing to work fine, is that valid in your case, i am not sure!

    from your code:

    int hr1 = CoInitializeEx(IntPtr.Zero, CoInit.MultiThreaded);
                CoInitializeSecurity(IntPtr.Zero,
                    -1,
                    IntPtr.Zero,
                    IntPtr.Zero,
                    (uint)RpcAuthnLevel.None,
                    (uint)RpcImpLevel.Impersonate,
                    IntPtr.Zero,
                    (uint)EoAuthnCap.None,
                    IntPtr.Zero);

    i doubt you require same in C# code!. could you remove and try

    13. prosince 2012 11:47