Can create object using C++ CoCreateInstance, but not using C# Activator.CreateInstance

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Brian Rogers

    Can create object using C++ CoCreateInstance, but not using C# Activator.CreateInstance

    Hello everyone,

    I apologize for the cross and re-post, but I am still searching for an
    answer.

    Why can C++ can create this object, but C# can't?

    I am trying to create an instance of the default FTP asynchronous pluggable
    protocol adaptor, so I can analyse the traffic between urlmon.dll (IE) and
    the FTP server. The language I am attempting to use is C#.

    The CLSID for the adaptor (as referenced in the protocol registry key) is
    {79eac9e3-baf9-11ce-8c82-00aa004ba90b} and is stored as CLSID_FtpProtoc ol.

    If I use the following unmanaged C++ code, I can create an instance of the
    filter.

    HRESULT result;
    LPUNKNOWN _pUnk = NULL;
    CoInitialize( NULL);
    result = CoCreateInstanc e( CLSID_FtpProtoc ol,
    NULL,
    CLSCTX_INPROC_S ERVER,
    IID_IInternetPr otocol,
    (LPVOID*)&_pUnk );

    If I use the following C# code, I receive an error. (OutOfMemoryExc eption)

    Guid IID_IInternetPr otocolInfo = new
    Guid("{79eac9e3-baf9-11ce-8c82-00aa004ba90b}") ;
    objType = Type.GetTypeFro mCLSID(IID_IInt ernetProtocolIn fo);
    Activator.Creat eInstance(objTy pe);

    Any thoughts would be greatly appreciated.

    Thanks,
    Brian.




  • Nicholas Paldino [.NET/C# MVP]

    #2
    Re: Can create object using C++ CoCreateInstanc e, but not using C# Activator.Creat eInstance

    Brian,

    If you are trying to access the asyncronous pluggable protocol adaptor,
    you shouldn't be creating it directly, but rather, you should be using the
    IMoniker interface.

    However, that doesn't mean that one ^can't^ create it directly, as it
    should just be another COM object. It could be that there is something in
    the constructor of the class that detects some sort of context (just a
    guess).

    As a workaround, you can have unmanaged code that creates the object,
    and then passes the pointer to managed code.

    Hope this helps.


    --
    - Nicholas Paldino [.NET/C# MVP]
    - mvp@spam.guard. caspershouse.co m


    "Brian Rogers" <none@none.co m> wrote in message
    news:%23wfupbBu DHA.2060@TK2MSF TNGP10.phx.gbl. ..[color=blue]
    > Hello everyone,
    >
    > I apologize for the cross and re-post, but I am still searching for an
    > answer.
    >
    > Why can C++ can create this object, but C# can't?
    >
    > I am trying to create an instance of the default FTP asynchronous[/color]
    pluggable[color=blue]
    > protocol adaptor, so I can analyse the traffic between urlmon.dll (IE) and
    > the FTP server. The language I am attempting to use is C#.
    >
    > The CLSID for the adaptor (as referenced in the protocol registry key) is
    > {79eac9e3-baf9-11ce-8c82-00aa004ba90b} and is stored as CLSID_FtpProtoc ol.
    >
    > If I use the following unmanaged C++ code, I can create an instance of the
    > filter.
    >
    > HRESULT result;
    > LPUNKNOWN _pUnk = NULL;
    > CoInitialize( NULL);
    > result = CoCreateInstanc e( CLSID_FtpProtoc ol,
    > NULL,
    > CLSCTX_INPROC_S ERVER,
    > IID_IInternetPr otocol,
    > (LPVOID*)&_pUnk );
    >
    > If I use the following C# code, I receive an error. (OutOfMemoryExc eption)
    >
    > Guid IID_IInternetPr otocolInfo = new
    > Guid("{79eac9e3-baf9-11ce-8c82-00aa004ba90b}") ;
    > objType = Type.GetTypeFro mCLSID(IID_IInt ernetProtocolIn fo);
    > Activator.Creat eInstance(objTy pe);
    >
    > Any thoughts would be greatly appreciated.
    >
    > Thanks,
    > Brian.
    >
    >
    >
    >[/color]


    Comment

    • Brian Rogers

      #3
      Re: Can't create object using C++ CoCreateInstanc e, but not using C# Activator.Creat eInstance

      Hi Nicholas,

      I appreciate the feedback.

      The objective is to place a wrapper around the protocol adapter, so I can
      reverse engineer the data flow in both directions. I want to analyse the
      data flow between IE and the FTP protocol handler.

      I actually have no idea how the IMoniker interface comes into play. I
      believe the handler was supposed to support the IInternetProtoc ol and
      IInternetProtoc olRoot interfaces amongst others. Currently, I can't even
      create the filter to bind it to IUnknown.

      In the end, I want to create a custom FTP Protocol handler in C#. My C++ is
      not good enough to create and expose an unmanaged factory class, so that was
      not an option for me.

      Thanks,
      B.

      "Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard .caspershouse.c om> wrote in
      message news:uR8B$hBuDH A.2136@TK2MSFTN GP10.phx.gbl...[color=blue]
      > Brian,
      >
      > If you are trying to access the asyncronous pluggable protocol[/color]
      adaptor,[color=blue]
      > you shouldn't be creating it directly, but rather, you should be using the
      > IMoniker interface.
      >
      > However, that doesn't mean that one ^can't^ create it directly, as it
      > should just be another COM object. It could be that there is something in
      > the constructor of the class that detects some sort of context (just a
      > guess).
      >
      > As a workaround, you can have unmanaged code that creates the object,
      > and then passes the pointer to managed code.
      >
      > Hope this helps.
      >
      >
      > --
      > - Nicholas Paldino [.NET/C# MVP]
      > - mvp@spam.guard. caspershouse.co m
      >
      >
      > "Brian Rogers" <none@none.co m> wrote in message
      > news:%23wfupbBu DHA.2060@TK2MSF TNGP10.phx.gbl. ..[color=green]
      > > Hello everyone,
      > >
      > > I apologize for the cross and re-post, but I am still searching for an
      > > answer.
      > >
      > > Why can C++ can create this object, but C# can't?
      > >
      > > I am trying to create an instance of the default FTP asynchronous[/color]
      > pluggable[color=green]
      > > protocol adaptor, so I can analyse the traffic between urlmon.dll (IE)[/color][/color]
      and[color=blue][color=green]
      > > the FTP server. The language I am attempting to use is C#.
      > >
      > > The CLSID for the adaptor (as referenced in the protocol registry key)[/color][/color]
      is[color=blue][color=green]
      > > {79eac9e3-baf9-11ce-8c82-00aa004ba90b} and is stored as[/color][/color]
      CLSID_FtpProtoc ol.[color=blue][color=green]
      > >
      > > If I use the following unmanaged C++ code, I can create an instance of[/color][/color]
      the[color=blue][color=green]
      > > filter.
      > >
      > > HRESULT result;
      > > LPUNKNOWN _pUnk = NULL;
      > > CoInitialize( NULL);
      > > result = CoCreateInstanc e( CLSID_FtpProtoc ol,
      > > NULL,
      > > CLSCTX_INPROC_S ERVER,
      > > IID_IInternetPr otocol,
      > > (LPVOID*)&_pUnk );
      > >
      > > If I use the following C# code, I receive an error.[/color][/color]
      (OutOfMemoryExc eption)[color=blue][color=green]
      > >
      > > Guid IID_IInternetPr otocolInfo = new
      > > Guid("{79eac9e3-baf9-11ce-8c82-00aa004ba90b}") ;
      > > objType = Type.GetTypeFro mCLSID(IID_IInt ernetProtocolIn fo);
      > > Activator.Creat eInstance(objTy pe);
      > >
      > > Any thoughts would be greatly appreciated.
      > >
      > > Thanks,
      > > Brian.
      > >
      > >
      > >
      > >[/color]
      >
      >[/color]


      Comment

      • Mattias Sjögren

        #4
        Re: Can create object using C++ CoCreateInstanc e, but not using C# Activator.Creat eInstance

        Brian,
        [color=blue]
        >If I use the following unmanaged C++ code, I can create an instance of the
        >filter.
        >
        >HRESULT result;
        >LPUNKNOWN _pUnk = NULL;
        >CoInitialize ( NULL);
        >result = CoCreateInstanc e( CLSID_FtpProtoc ol,
        > NULL,
        > CLSCTX_INPROC_S ERVER,
        > IID_IInternetPr otocol,
        > (LPVOID*)&_pUnk );[/color]

        If I replace IID_IInternetPr otocol with IID_IUnknown, I get an access
        violation exception. Unless I'm missing something, that looks like a
        bug. I suspect that's why you get the exception in managed code.

        The only workaround I can suggest is that you call CoCreateInstanc e
        through P/Invoke.



        Mattias

        --
        Mattias Sjögren [MVP] mattias @ mvps.org

        Please reply only to the newsgroup.

        Comment

        • Nicholas Paldino [.NET/C# MVP]

          #5
          Re: Can't create object using C++ CoCreateInstanc e, but not using C# Activator.Creat eInstance

          Brian,

          It would be much easier to implement a pluggable protocol handler in
          C++. You can create an ATL project that will do all of the COM plumbing for
          you. Once you have that, all you should have to worry about is the
          implementation of the interface (along with the registration).

          However, I don't know if you can register your own FTP handler. I think
          that for protocols like HTTP and FTP, the COM Moniker framework hard-codes
          the protocol handlers.


          --
          - Nicholas Paldino [.NET/C# MVP]
          - mvp@spam.guard. caspershouse.co m

          "Brian Rogers" <none@none.co m> wrote in message
          news:ed9kxICuDH A.2248@TK2MSFTN GP09.phx.gbl...[color=blue]
          > Hi Nicholas,
          >
          > I appreciate the feedback.
          >
          > The objective is to place a wrapper around the protocol adapter, so I can
          > reverse engineer the data flow in both directions. I want to analyse the
          > data flow between IE and the FTP protocol handler.
          >
          > I actually have no idea how the IMoniker interface comes into play. I
          > believe the handler was supposed to support the IInternetProtoc ol and
          > IInternetProtoc olRoot interfaces amongst others. Currently, I can't even
          > create the filter to bind it to IUnknown.
          >
          > In the end, I want to create a custom FTP Protocol handler in C#. My C++[/color]
          is[color=blue]
          > not good enough to create and expose an unmanaged factory class, so that[/color]
          was[color=blue]
          > not an option for me.
          >
          > Thanks,
          > B.
          >
          > "Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard .caspershouse.c om> wrote[/color]
          in[color=blue]
          > message news:uR8B$hBuDH A.2136@TK2MSFTN GP10.phx.gbl...[color=green]
          > > Brian,
          > >
          > > If you are trying to access the asyncronous pluggable protocol[/color]
          > adaptor,[color=green]
          > > you shouldn't be creating it directly, but rather, you should be using[/color][/color]
          the[color=blue][color=green]
          > > IMoniker interface.
          > >
          > > However, that doesn't mean that one ^can't^ create it directly, as[/color][/color]
          it[color=blue][color=green]
          > > should just be another COM object. It could be that there is something[/color][/color]
          in[color=blue][color=green]
          > > the constructor of the class that detects some sort of context (just a
          > > guess).
          > >
          > > As a workaround, you can have unmanaged code that creates the[/color][/color]
          object,[color=blue][color=green]
          > > and then passes the pointer to managed code.
          > >
          > > Hope this helps.
          > >
          > >
          > > --
          > > - Nicholas Paldino [.NET/C# MVP]
          > > - mvp@spam.guard. caspershouse.co m
          > >
          > >
          > > "Brian Rogers" <none@none.co m> wrote in message
          > > news:%23wfupbBu DHA.2060@TK2MSF TNGP10.phx.gbl. ..[color=darkred]
          > > > Hello everyone,
          > > >
          > > > I apologize for the cross and re-post, but I am still searching for an
          > > > answer.
          > > >
          > > > Why can C++ can create this object, but C# can't?
          > > >
          > > > I am trying to create an instance of the default FTP asynchronous[/color]
          > > pluggable[color=darkred]
          > > > protocol adaptor, so I can analyse the traffic between urlmon.dll (IE)[/color][/color]
          > and[color=green][color=darkred]
          > > > the FTP server. The language I am attempting to use is C#.
          > > >
          > > > The CLSID for the adaptor (as referenced in the protocol registry key)[/color][/color]
          > is[color=green][color=darkred]
          > > > {79eac9e3-baf9-11ce-8c82-00aa004ba90b} and is stored as[/color][/color]
          > CLSID_FtpProtoc ol.[color=green][color=darkred]
          > > >
          > > > If I use the following unmanaged C++ code, I can create an instance of[/color][/color]
          > the[color=green][color=darkred]
          > > > filter.
          > > >
          > > > HRESULT result;
          > > > LPUNKNOWN _pUnk = NULL;
          > > > CoInitialize( NULL);
          > > > result = CoCreateInstanc e( CLSID_FtpProtoc ol,
          > > > NULL,
          > > > CLSCTX_INPROC_S ERVER,
          > > > IID_IInternetPr otocol,
          > > > (LPVOID*)&_pUnk );
          > > >
          > > > If I use the following C# code, I receive an error.[/color][/color]
          > (OutOfMemoryExc eption)[color=green][color=darkred]
          > > >
          > > > Guid IID_IInternetPr otocolInfo = new
          > > > Guid("{79eac9e3-baf9-11ce-8c82-00aa004ba90b}") ;
          > > > objType = Type.GetTypeFro mCLSID(IID_IInt ernetProtocolIn fo);
          > > > Activator.Creat eInstance(objTy pe);
          > > >
          > > > Any thoughts would be greatly appreciated.
          > > >
          > > > Thanks,
          > > > Brian.
          > > >
          > > >
          > > >
          > > >[/color]
          > >
          > >[/color]
          >
          >[/color]


          Comment

          • Brian Rogers

            #6
            Re: Can create object using C++ CoCreateInstanc e, but not using C# Activator.Creat eInstance

            Hi Mattias,

            Thank you for looking into the issue.

            I was not aware there was a CoCreateInstanc e that you could invoke from C#.
            I assume you are using some form of reflection to access the object and then
            call P/Invoke?

            My under the covers COM and C++ skills are seriously lacking. While I
            understand the fundamentals and can do some of the advanced stuff, this is a
            little further down the road.

            In another project, I received an instance of an object through the
            marshaller and then invoked methods by name. The problem I have here is
            actually getting the initial instance.

            Thanks,
            B.


            "Mattias Sjögren" <mattias.dont.w ant.spam@mvps.o rg> wrote in message
            news:%23iSmJeCu DHA.2060@TK2MSF TNGP10.phx.gbl. ..[color=blue]
            > Brian,
            >[color=green]
            > >If I use the following unmanaged C++ code, I can create an instance of[/color][/color]
            the[color=blue][color=green]
            > >filter.
            > >
            > >HRESULT result;
            > >LPUNKNOWN _pUnk = NULL;
            > >CoInitialize ( NULL);
            > >result = CoCreateInstanc e( CLSID_FtpProtoc ol,
            > > NULL,
            > > CLSCTX_INPROC_S ERVER,
            > > IID_IInternetPr otocol,
            > > (LPVOID*)&_pUnk );[/color]
            >
            > If I replace IID_IInternetPr otocol with IID_IUnknown, I get an access
            > violation exception. Unless I'm missing something, that looks like a
            > bug. I suspect that's why you get the exception in managed code.
            >
            > The only workaround I can suggest is that you call CoCreateInstanc e
            > through P/Invoke.
            >
            >
            >
            > Mattias
            >
            > --
            > Mattias Sjögren [MVP] mattias @ mvps.org
            > http://www.msjogren.net/dotnet/
            > Please reply only to the newsgroup.[/color]


            Comment

            • Brian Rogers

              #7
              Re: Can't create object using C++ CoCreateInstanc e, but not using C# Activator.Creat eInstance

              Hi Nicholas,

              Yeah - was trying desperately not to have to do that. I love ATL and C++ -
              NOT!!! :)

              Hardcoding the handler in the PROTOCOLS key works perfectly for me and
              initiates my C# handler. I have registered my protocol as test: for now.
              It's the re-routing of the calls to the ftp protocol handler that is killing
              me.

              All I really need to do is create and instance of the handler and bind it to
              the IInternetProtoc ol interfaces (or other pluggable protocol handlers) in
              order to reverse engineer it. Then I implement all the interface methods and
              pass the calls to the FTP handler instance. I can then examine all data in
              transit.

              I appreciate the help though.

              Thanks,
              B.


              "Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard .caspershouse.c om> wrote in
              message news:%23FTOa9Cu DHA.2072@TK2MSF TNGP10.phx.gbl. ..[color=blue]
              > Brian,
              >
              > It would be much easier to implement a pluggable protocol handler in
              > C++. You can create an ATL project that will do all of the COM plumbing[/color]
              for[color=blue]
              > you. Once you have that, all you should have to worry about is the
              > implementation of the interface (along with the registration).
              >
              > However, I don't know if you can register your own FTP handler. I[/color]
              think[color=blue]
              > that for protocols like HTTP and FTP, the COM Moniker framework hard-codes
              > the protocol handlers.
              >
              >
              > --
              > - Nicholas Paldino [.NET/C# MVP]
              > - mvp@spam.guard. caspershouse.co m
              >
              > "Brian Rogers" <none@none.co m> wrote in message
              > news:ed9kxICuDH A.2248@TK2MSFTN GP09.phx.gbl...[color=green]
              > > Hi Nicholas,
              > >
              > > I appreciate the feedback.
              > >
              > > The objective is to place a wrapper around the protocol adapter, so I[/color][/color]
              can[color=blue][color=green]
              > > reverse engineer the data flow in both directions. I want to analyse the
              > > data flow between IE and the FTP protocol handler.
              > >
              > > I actually have no idea how the IMoniker interface comes into play. I
              > > believe the handler was supposed to support the IInternetProtoc ol and
              > > IInternetProtoc olRoot interfaces amongst others. Currently, I can't even
              > > create the filter to bind it to IUnknown.
              > >
              > > In the end, I want to create a custom FTP Protocol handler in C#. My C++[/color]
              > is[color=green]
              > > not good enough to create and expose an unmanaged factory class, so that[/color]
              > was[color=green]
              > > not an option for me.
              > >
              > > Thanks,
              > > B.
              > >
              > > "Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard .caspershouse.c om> wrote[/color]
              > in[color=green]
              > > message news:uR8B$hBuDH A.2136@TK2MSFTN GP10.phx.gbl...[color=darkred]
              > > > Brian,
              > > >
              > > > If you are trying to access the asyncronous pluggable protocol[/color]
              > > adaptor,[color=darkred]
              > > > you shouldn't be creating it directly, but rather, you should be using[/color][/color]
              > the[color=green][color=darkred]
              > > > IMoniker interface.
              > > >
              > > > However, that doesn't mean that one ^can't^ create it directly, as[/color][/color]
              > it[color=green][color=darkred]
              > > > should just be another COM object. It could be that there is[/color][/color][/color]
              something[color=blue]
              > in[color=green][color=darkred]
              > > > the constructor of the class that detects some sort of context (just a
              > > > guess).
              > > >
              > > > As a workaround, you can have unmanaged code that creates the[/color][/color]
              > object,[color=green][color=darkred]
              > > > and then passes the pointer to managed code.
              > > >
              > > > Hope this helps.
              > > >
              > > >
              > > > --
              > > > - Nicholas Paldino [.NET/C# MVP]
              > > > - mvp@spam.guard. caspershouse.co m
              > > >
              > > >
              > > > "Brian Rogers" <none@none.co m> wrote in message
              > > > news:%23wfupbBu DHA.2060@TK2MSF TNGP10.phx.gbl. ..
              > > > > Hello everyone,
              > > > >
              > > > > I apologize for the cross and re-post, but I am still searching for[/color][/color][/color]
              an[color=blue][color=green][color=darkred]
              > > > > answer.
              > > > >
              > > > > Why can C++ can create this object, but C# can't?
              > > > >
              > > > > I am trying to create an instance of the default FTP asynchronous
              > > > pluggable
              > > > > protocol adaptor, so I can analyse the traffic between urlmon.dll[/color][/color][/color]
              (IE)[color=blue][color=green]
              > > and[color=darkred]
              > > > > the FTP server. The language I am attempting to use is C#.
              > > > >
              > > > > The CLSID for the adaptor (as referenced in the protocol registry[/color][/color][/color]
              key)[color=blue][color=green]
              > > is[color=darkred]
              > > > > {79eac9e3-baf9-11ce-8c82-00aa004ba90b} and is stored as[/color]
              > > CLSID_FtpProtoc ol.[color=darkred]
              > > > >
              > > > > If I use the following unmanaged C++ code, I can create an instance[/color][/color][/color]
              of[color=blue][color=green]
              > > the[color=darkred]
              > > > > filter.
              > > > >
              > > > > HRESULT result;
              > > > > LPUNKNOWN _pUnk = NULL;
              > > > > CoInitialize( NULL);
              > > > > result = CoCreateInstanc e( CLSID_FtpProtoc ol,
              > > > > NULL,
              > > > > CLSCTX_INPROC_S ERVER,
              > > > > IID_IInternetPr otocol,
              > > > > (LPVOID*)&_pUnk );
              > > > >
              > > > > If I use the following C# code, I receive an error.[/color]
              > > (OutOfMemoryExc eption)[color=darkred]
              > > > >
              > > > > Guid IID_IInternetPr otocolInfo = new
              > > > > Guid("{79eac9e3-baf9-11ce-8c82-00aa004ba90b}") ;
              > > > > objType = Type.GetTypeFro mCLSID(IID_IInt ernetProtocolIn fo);
              > > > > Activator.Creat eInstance(objTy pe);
              > > > >
              > > > > Any thoughts would be greatly appreciated.
              > > > >
              > > > > Thanks,
              > > > > Brian.
              > > > >
              > > > >
              > > > >
              > > > >
              > > >
              > > >[/color]
              > >
              > >[/color]
              >
              >[/color]


              Comment

              • Nicholas Paldino [.NET/C# MVP]

                #8
                Re: Can't create object using C++ CoCreateInstanc e, but not using C# Activator.Creat eInstance

                Brian,

                In that case, I would stick with what I originally proposed, which is
                getting the pointer in unmanaged code and then passing that back to managed
                code.


                --
                - Nicholas Paldino [.NET/C# MVP]
                - mvp@spam.guard. caspershouse.co m

                "Brian Rogers" <none@none.co m> wrote in message
                news:eP5S4UEuDH A.2148@TK2MSFTN GP12.phx.gbl...[color=blue]
                > Hi Nicholas,
                >
                > Yeah - was trying desperately not to have to do that. I love ATL and C++ -
                > NOT!!! :)
                >
                > Hardcoding the handler in the PROTOCOLS key works perfectly for me and
                > initiates my C# handler. I have registered my protocol as test: for now.
                > It's the re-routing of the calls to the ftp protocol handler that is[/color]
                killing[color=blue]
                > me.
                >
                > All I really need to do is create and instance of the handler and bind it[/color]
                to[color=blue]
                > the IInternetProtoc ol interfaces (or other pluggable protocol handlers) in
                > order to reverse engineer it. Then I implement all the interface methods[/color]
                and[color=blue]
                > pass the calls to the FTP handler instance. I can then examine all data in
                > transit.
                >
                > I appreciate the help though.
                >
                > Thanks,
                > B.
                >
                >
                > "Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard .caspershouse.c om> wrote[/color]
                in[color=blue]
                > message news:%23FTOa9Cu DHA.2072@TK2MSF TNGP10.phx.gbl. ..[color=green]
                > > Brian,
                > >
                > > It would be much easier to implement a pluggable protocol handler in
                > > C++. You can create an ATL project that will do all of the COM plumbing[/color]
                > for[color=green]
                > > you. Once you have that, all you should have to worry about is the
                > > implementation of the interface (along with the registration).
                > >
                > > However, I don't know if you can register your own FTP handler. I[/color]
                > think[color=green]
                > > that for protocols like HTTP and FTP, the COM Moniker framework[/color][/color]
                hard-codes[color=blue][color=green]
                > > the protocol handlers.
                > >
                > >
                > > --
                > > - Nicholas Paldino [.NET/C# MVP]
                > > - mvp@spam.guard. caspershouse.co m
                > >
                > > "Brian Rogers" <none@none.co m> wrote in message
                > > news:ed9kxICuDH A.2248@TK2MSFTN GP09.phx.gbl...[color=darkred]
                > > > Hi Nicholas,
                > > >
                > > > I appreciate the feedback.
                > > >
                > > > The objective is to place a wrapper around the protocol adapter, so I[/color][/color]
                > can[color=green][color=darkred]
                > > > reverse engineer the data flow in both directions. I want to analyse[/color][/color][/color]
                the[color=blue][color=green][color=darkred]
                > > > data flow between IE and the FTP protocol handler.
                > > >
                > > > I actually have no idea how the IMoniker interface comes into play. I
                > > > believe the handler was supposed to support the IInternetProtoc ol and
                > > > IInternetProtoc olRoot interfaces amongst others. Currently, I can't[/color][/color][/color]
                even[color=blue][color=green][color=darkred]
                > > > create the filter to bind it to IUnknown.
                > > >
                > > > In the end, I want to create a custom FTP Protocol handler in C#. My[/color][/color][/color]
                C++[color=blue][color=green]
                > > is[color=darkred]
                > > > not good enough to create and expose an unmanaged factory class, so[/color][/color][/color]
                that[color=blue][color=green]
                > > was[color=darkred]
                > > > not an option for me.
                > > >
                > > > Thanks,
                > > > B.
                > > >
                > > > "Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard .caspershouse.c om>[/color][/color][/color]
                wrote[color=blue][color=green]
                > > in[color=darkred]
                > > > message news:uR8B$hBuDH A.2136@TK2MSFTN GP10.phx.gbl...
                > > > > Brian,
                > > > >
                > > > > If you are trying to access the asyncronous pluggable protocol
                > > > adaptor,
                > > > > you shouldn't be creating it directly, but rather, you should be[/color][/color][/color]
                using[color=blue][color=green]
                > > the[color=darkred]
                > > > > IMoniker interface.
                > > > >
                > > > > However, that doesn't mean that one ^can't^ create it directly,[/color][/color][/color]
                as[color=blue][color=green]
                > > it[color=darkred]
                > > > > should just be another COM object. It could be that there is[/color][/color]
                > something[color=green]
                > > in[color=darkred]
                > > > > the constructor of the class that detects some sort of context (just[/color][/color][/color]
                a[color=blue][color=green][color=darkred]
                > > > > guess).
                > > > >
                > > > > As a workaround, you can have unmanaged code that creates the[/color]
                > > object,[color=darkred]
                > > > > and then passes the pointer to managed code.
                > > > >
                > > > > Hope this helps.
                > > > >
                > > > >
                > > > > --
                > > > > - Nicholas Paldino [.NET/C# MVP]
                > > > > - mvp@spam.guard. caspershouse.co m
                > > > >
                > > > >
                > > > > "Brian Rogers" <none@none.co m> wrote in message
                > > > > news:%23wfupbBu DHA.2060@TK2MSF TNGP10.phx.gbl. ..
                > > > > > Hello everyone,
                > > > > >
                > > > > > I apologize for the cross and re-post, but I am still searching[/color][/color][/color]
                for[color=blue]
                > an[color=green][color=darkred]
                > > > > > answer.
                > > > > >
                > > > > > Why can C++ can create this object, but C# can't?
                > > > > >
                > > > > > I am trying to create an instance of the default FTP asynchronous
                > > > > pluggable
                > > > > > protocol adaptor, so I can analyse the traffic between urlmon.dll[/color][/color]
                > (IE)[color=green][color=darkred]
                > > > and
                > > > > > the FTP server. The language I am attempting to use is C#.
                > > > > >
                > > > > > The CLSID for the adaptor (as referenced in the protocol registry[/color][/color]
                > key)[color=green][color=darkred]
                > > > is
                > > > > > {79eac9e3-baf9-11ce-8c82-00aa004ba90b} and is stored as
                > > > CLSID_FtpProtoc ol.
                > > > > >
                > > > > > If I use the following unmanaged C++ code, I can create an[/color][/color][/color]
                instance[color=blue]
                > of[color=green][color=darkred]
                > > > the
                > > > > > filter.
                > > > > >
                > > > > > HRESULT result;
                > > > > > LPUNKNOWN _pUnk = NULL;
                > > > > > CoInitialize( NULL);
                > > > > > result = CoCreateInstanc e( CLSID_FtpProtoc ol,
                > > > > > NULL,
                > > > > > CLSCTX_INPROC_S ERVER,
                > > > > > IID_IInternetPr otocol,
                > > > > > (LPVOID*)&_pUnk );
                > > > > >
                > > > > > If I use the following C# code, I receive an error.
                > > > (OutOfMemoryExc eption)
                > > > > >
                > > > > > Guid IID_IInternetPr otocolInfo = new
                > > > > > Guid("{79eac9e3-baf9-11ce-8c82-00aa004ba90b}") ;
                > > > > > objType = Type.GetTypeFro mCLSID(IID_IInt ernetProtocolIn fo);
                > > > > > Activator.Creat eInstance(objTy pe);
                > > > > >
                > > > > > Any thoughts would be greatly appreciated.
                > > > > >
                > > > > > Thanks,
                > > > > > Brian.
                > > > > >
                > > > > >
                > > > > >
                > > > > >
                > > > >
                > > > >
                > > >
                > > >[/color]
                > >
                > >[/color]
                >
                >[/color]


                Comment

                • Mattias Sjögren

                  #9
                  Re: Can create object using C++ CoCreateInstanc e, but not using C# Activator.Creat eInstance

                  Brian,
                  [color=blue]
                  >I was not aware there was a CoCreateInstanc e that you could invoke from C#.
                  >I assume you are using some form of reflection to access the object and then
                  >call P/Invoke?[/color]

                  No reflection needed, just declare the function like this

                  [DllImport("ole3 2.dll", PreserveSig=fal se)]
                  [return: MarshalAs(Unman agedType.IUnkno wn)]
                  static extern object CoCreateInstanc e(
                  [MarshalAs(Unman agedType.LPStru ct)] Guid rclsid,
                  [MarshalAs(Unman agedType.IUnkno wn)] object pUnkOuter,
                  uint dwClsContext,
                  [MarshalAs(Unman agedType.LPStru ct)] Guid riid);

                  and call it something like this

                  Guid CLSID_FtpProtoc ol = new
                  Guid("79eac9e3-baf9-11ce-8c82-00aa004ba90b");
                  Guid IID_IInternetPr otocol = new
                  Guid("79eac9e4-baf9-11ce-8c82-00aa004ba90b");

                  o = CoCreateInstanc e( CLSID_FtpProtoc ol, null, 1
                  /*CLSCTX_INPROC_ SERVER*/, IID_IInternetPr otocol );



                  Mattias

                  --
                  Mattias Sjögren [MVP] mattias @ mvps.org

                  Please reply only to the newsgroup.

                  Comment

                  • Brian Rogers

                    #10
                    Re: Can't create object using C++ CoCreateInstanc e, but not using C# Activator.Creat eInstance

                    I will give it a shot,
                    Thanks.

                    "Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard .caspershouse.c om> wrote in
                    message news:%238GBQwEu DHA.2224@TK2MSF TNGP09.phx.gbl. ..[color=blue]
                    > Brian,
                    >
                    > In that case, I would stick with what I originally proposed, which is
                    > getting the pointer in unmanaged code and then passing that back to[/color]
                    managed[color=blue]
                    > code.
                    >
                    >
                    > --
                    > - Nicholas Paldino [.NET/C# MVP]
                    > - mvp@spam.guard. caspershouse.co m
                    >
                    > "Brian Rogers" <none@none.co m> wrote in message
                    > news:eP5S4UEuDH A.2148@TK2MSFTN GP12.phx.gbl...[color=green]
                    > > Hi Nicholas,
                    > >
                    > > Yeah - was trying desperately not to have to do that. I love ATL and[/color][/color]
                    C++ -[color=blue][color=green]
                    > > NOT!!! :)
                    > >
                    > > Hardcoding the handler in the PROTOCOLS key works perfectly for me and
                    > > initiates my C# handler. I have registered my protocol as test: for now.
                    > > It's the re-routing of the calls to the ftp protocol handler that is[/color]
                    > killing[color=green]
                    > > me.
                    > >
                    > > All I really need to do is create and instance of the handler and bind[/color][/color]
                    it[color=blue]
                    > to[color=green]
                    > > the IInternetProtoc ol interfaces (or other pluggable protocol handlers)[/color][/color]
                    in[color=blue][color=green]
                    > > order to reverse engineer it. Then I implement all the interface methods[/color]
                    > and[color=green]
                    > > pass the calls to the FTP handler instance. I can then examine all data[/color][/color]
                    in[color=blue][color=green]
                    > > transit.
                    > >
                    > > I appreciate the help though.
                    > >
                    > > Thanks,
                    > > B.
                    > >
                    > >
                    > > "Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard .caspershouse.c om> wrote[/color]
                    > in[color=green]
                    > > message news:%23FTOa9Cu DHA.2072@TK2MSF TNGP10.phx.gbl. ..[color=darkred]
                    > > > Brian,
                    > > >
                    > > > It would be much easier to implement a pluggable protocol handler[/color][/color][/color]
                    in[color=blue][color=green][color=darkred]
                    > > > C++. You can create an ATL project that will do all of the COM[/color][/color][/color]
                    plumbing[color=blue][color=green]
                    > > for[color=darkred]
                    > > > you. Once you have that, all you should have to worry about is the
                    > > > implementation of the interface (along with the registration).
                    > > >
                    > > > However, I don't know if you can register your own FTP handler. I[/color]
                    > > think[color=darkred]
                    > > > that for protocols like HTTP and FTP, the COM Moniker framework[/color][/color]
                    > hard-codes[color=green][color=darkred]
                    > > > the protocol handlers.
                    > > >
                    > > >
                    > > > --
                    > > > - Nicholas Paldino [.NET/C# MVP]
                    > > > - mvp@spam.guard. caspershouse.co m
                    > > >
                    > > > "Brian Rogers" <none@none.co m> wrote in message
                    > > > news:ed9kxICuDH A.2248@TK2MSFTN GP09.phx.gbl...
                    > > > > Hi Nicholas,
                    > > > >
                    > > > > I appreciate the feedback.
                    > > > >
                    > > > > The objective is to place a wrapper around the protocol adapter, so[/color][/color][/color]
                    I[color=blue][color=green]
                    > > can[color=darkred]
                    > > > > reverse engineer the data flow in both directions. I want to analyse[/color][/color]
                    > the[color=green][color=darkred]
                    > > > > data flow between IE and the FTP protocol handler.
                    > > > >
                    > > > > I actually have no idea how the IMoniker interface comes into play.[/color][/color][/color]
                    I[color=blue][color=green][color=darkred]
                    > > > > believe the handler was supposed to support the IInternetProtoc ol[/color][/color][/color]
                    and[color=blue][color=green][color=darkred]
                    > > > > IInternetProtoc olRoot interfaces amongst others. Currently, I can't[/color][/color]
                    > even[color=green][color=darkred]
                    > > > > create the filter to bind it to IUnknown.
                    > > > >
                    > > > > In the end, I want to create a custom FTP Protocol handler in C#. My[/color][/color]
                    > C++[color=green][color=darkred]
                    > > > is
                    > > > > not good enough to create and expose an unmanaged factory class, so[/color][/color]
                    > that[color=green][color=darkred]
                    > > > was
                    > > > > not an option for me.
                    > > > >
                    > > > > Thanks,
                    > > > > B.
                    > > > >
                    > > > > "Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard .caspershouse.c om>[/color][/color]
                    > wrote[color=green][color=darkred]
                    > > > in
                    > > > > message news:uR8B$hBuDH A.2136@TK2MSFTN GP10.phx.gbl...
                    > > > > > Brian,
                    > > > > >
                    > > > > > If you are trying to access the asyncronous pluggable protocol
                    > > > > adaptor,
                    > > > > > you shouldn't be creating it directly, but rather, you should be[/color][/color]
                    > using[color=green][color=darkred]
                    > > > the
                    > > > > > IMoniker interface.
                    > > > > >
                    > > > > > However, that doesn't mean that one ^can't^ create it[/color][/color][/color]
                    directly,[color=blue]
                    > as[color=green][color=darkred]
                    > > > it
                    > > > > > should just be another COM object. It could be that there is[/color]
                    > > something[color=darkred]
                    > > > in
                    > > > > > the constructor of the class that detects some sort of context[/color][/color][/color]
                    (just[color=blue]
                    > a[color=green][color=darkred]
                    > > > > > guess).
                    > > > > >
                    > > > > > As a workaround, you can have unmanaged code that creates the
                    > > > object,
                    > > > > > and then passes the pointer to managed code.
                    > > > > >
                    > > > > > Hope this helps.
                    > > > > >
                    > > > > >
                    > > > > > --
                    > > > > > - Nicholas Paldino [.NET/C# MVP]
                    > > > > > - mvp@spam.guard. caspershouse.co m
                    > > > > >
                    > > > > >
                    > > > > > "Brian Rogers" <none@none.co m> wrote in message
                    > > > > > news:%23wfupbBu DHA.2060@TK2MSF TNGP10.phx.gbl. ..
                    > > > > > > Hello everyone,
                    > > > > > >
                    > > > > > > I apologize for the cross and re-post, but I am still searching[/color][/color]
                    > for[color=green]
                    > > an[color=darkred]
                    > > > > > > answer.
                    > > > > > >
                    > > > > > > Why can C++ can create this object, but C# can't?
                    > > > > > >
                    > > > > > > I am trying to create an instance of the default FTP[/color][/color][/color]
                    asynchronous[color=blue][color=green][color=darkred]
                    > > > > > pluggable
                    > > > > > > protocol adaptor, so I can analyse the traffic between[/color][/color][/color]
                    urlmon.dll[color=blue][color=green]
                    > > (IE)[color=darkred]
                    > > > > and
                    > > > > > > the FTP server. The language I am attempting to use is C#.
                    > > > > > >
                    > > > > > > The CLSID for the adaptor (as referenced in the protocol[/color][/color][/color]
                    registry[color=blue][color=green]
                    > > key)[color=darkred]
                    > > > > is
                    > > > > > > {79eac9e3-baf9-11ce-8c82-00aa004ba90b} and is stored as
                    > > > > CLSID_FtpProtoc ol.
                    > > > > > >
                    > > > > > > If I use the following unmanaged C++ code, I can create an[/color][/color]
                    > instance[color=green]
                    > > of[color=darkred]
                    > > > > the
                    > > > > > > filter.
                    > > > > > >
                    > > > > > > HRESULT result;
                    > > > > > > LPUNKNOWN _pUnk = NULL;
                    > > > > > > CoInitialize( NULL);
                    > > > > > > result = CoCreateInstanc e( CLSID_FtpProtoc ol,
                    > > > > > > NULL,
                    > > > > > > CLSCTX_INPROC_S ERVER,
                    > > > > > > IID_IInternetPr otocol,
                    > > > > > > (LPVOID*)&_pUnk );
                    > > > > > >
                    > > > > > > If I use the following C# code, I receive an error.
                    > > > > (OutOfMemoryExc eption)
                    > > > > > >
                    > > > > > > Guid IID_IInternetPr otocolInfo = new
                    > > > > > > Guid("{79eac9e3-baf9-11ce-8c82-00aa004ba90b}") ;
                    > > > > > > objType = Type.GetTypeFro mCLSID(IID_IInt ernetProtocolIn fo);
                    > > > > > > Activator.Creat eInstance(objTy pe);
                    > > > > > >
                    > > > > > > Any thoughts would be greatly appreciated.
                    > > > > > >
                    > > > > > > Thanks,
                    > > > > > > Brian.
                    > > > > > >
                    > > > > > >
                    > > > > > >
                    > > > > > >
                    > > > > >
                    > > > > >
                    > > > >
                    > > > >
                    > > >
                    > > >[/color]
                    > >
                    > >[/color]
                    >
                    >[/color]


                    Comment

                    • Brian Rogers

                      #11
                      Re: Can create object using C++ CoCreateInstanc e, but not using C# Activator.Creat eInstance

                      Hi Mattias,

                      I get it now. Now I understand.Will give it a shot.

                      Thanks,
                      B.

                      "Mattias Sjögren" <mattias.dont.w ant.spam@mvps.o rg> wrote in message
                      news:uB7MK5EuDH A.1680@TK2MSFTN GP12.phx.gbl...[color=blue]
                      > Brian,
                      >[color=green]
                      > >I was not aware there was a CoCreateInstanc e that you could invoke from[/color][/color]
                      C#.[color=blue][color=green]
                      > >I assume you are using some form of reflection to access the object and[/color][/color]
                      then[color=blue][color=green]
                      > >call P/Invoke?[/color]
                      >
                      > No reflection needed, just declare the function like this
                      >
                      > [DllImport("ole3 2.dll", PreserveSig=fal se)]
                      > [return: MarshalAs(Unman agedType.IUnkno wn)]
                      > static extern object CoCreateInstanc e(
                      > [MarshalAs(Unman agedType.LPStru ct)] Guid rclsid,
                      > [MarshalAs(Unman agedType.IUnkno wn)] object pUnkOuter,
                      > uint dwClsContext,
                      > [MarshalAs(Unman agedType.LPStru ct)] Guid riid);
                      >
                      > and call it something like this
                      >
                      > Guid CLSID_FtpProtoc ol = new
                      > Guid("79eac9e3-baf9-11ce-8c82-00aa004ba90b");
                      > Guid IID_IInternetPr otocol = new
                      > Guid("79eac9e4-baf9-11ce-8c82-00aa004ba90b");
                      >
                      > o = CoCreateInstanc e( CLSID_FtpProtoc ol, null, 1
                      > /*CLSCTX_INPROC_ SERVER*/, IID_IInternetPr otocol );
                      >
                      >
                      >
                      > Mattias
                      >
                      > --
                      > Mattias Sjögren [MVP] mattias @ mvps.org
                      > http://www.msjogren.net/dotnet/
                      > Please reply only to the newsgroup.[/color]


                      Comment

                      • Igor Tandetnik

                        #12
                        Re: Can create object using C++ CoCreateInstanc e, but not using C# Activator.Creat eInstance

                        "Brian Rogers" <none@none.co m> wrote in message
                        news:%23wfupbBu DHA.2060@TK2MSF TNGP10.phx.gbl. ..[color=blue]
                        > If I use the following unmanaged C++ code, I can create an instance of[/color]
                        the[color=blue]
                        > filter.
                        >
                        > HRESULT result;
                        > LPUNKNOWN _pUnk = NULL;
                        > CoInitialize( NULL);
                        > result = CoCreateInstanc e( CLSID_FtpProtoc ol,
                        > NULL,
                        > CLSCTX_INPROC_S ERVER,
                        > IID_IInternetPr otocol,
                        > (LPVOID*)&_pUnk );
                        >
                        > If I use the following C# code, I receive an error.[/color]
                        (OutOfMemoryExc eption)[color=blue]
                        >
                        > Guid IID_IInternetPr otocolInfo = new
                        > Guid("{79eac9e3-baf9-11ce-8c82-00aa004ba90b}") ;
                        > objType = Type.GetTypeFro mCLSID(IID_IInt ernetProtocolIn fo);
                        > Activator.Creat eInstance(objTy pe);[/color]

                        A bug in URLMon.dll. Activator.Creat eInstance calls CoCreateInstanc e
                        querying for IUnknown. Rather than looking at the outer unknown, URLMon
                        erroneously assumes that when an object is created and asked for
                        IUnknown, the caller wants to aggregate the object. So it goes ahead and
                        uses outer unknown without checking, but Activator.Creat eInstance passes
                        NULL there. So the whole thing crashes with an AV. .NET marshaling
                        catches the crash with a structured exception handler, and rethrows it
                        as OutOfMemoryExce ption.

                        I'm not familiar with C#, I don't know if there's a way to make it call
                        CoCreateInstanc e asking for some interface other than IUnknown.
                        --
                        With best wishes,
                        Igor Tandetnik

                        "For every complex problem, there is a solution that is simple, neat,
                        and wrong." H.L. Mencken


                        Comment

                        • Brian Rogers

                          #13
                          Re: Can create object using C++ CoCreateInstanc e, but not using C# Activator.Creat eInstance

                          Hi Igor,

                          Pretty impressive. That definitely sounds plausible. I wonder if MS is aware
                          of the issue? Is this a problem you have encountered before when using
                          interop?

                          Your post, combined with the advice from Mattias and Nicholas will
                          definitely help me solve this problem.

                          Thanks,
                          B.

                          "Igor Tandetnik" <itandetnik@mvp s.org> wrote in message
                          news:OoMlbRFuDH A.2360@TK2MSFTN GP10.phx.gbl...[color=blue]
                          > "Brian Rogers" <none@none.co m> wrote in message
                          > news:%23wfupbBu DHA.2060@TK2MSF TNGP10.phx.gbl. ..[color=green]
                          > > If I use the following unmanaged C++ code, I can create an instance of[/color]
                          > the[color=green]
                          > > filter.
                          > >
                          > > HRESULT result;
                          > > LPUNKNOWN _pUnk = NULL;
                          > > CoInitialize( NULL);
                          > > result = CoCreateInstanc e( CLSID_FtpProtoc ol,
                          > > NULL,
                          > > CLSCTX_INPROC_S ERVER,
                          > > IID_IInternetPr otocol,
                          > > (LPVOID*)&_pUnk );
                          > >
                          > > If I use the following C# code, I receive an error.[/color]
                          > (OutOfMemoryExc eption)[color=green]
                          > >
                          > > Guid IID_IInternetPr otocolInfo = new
                          > > Guid("{79eac9e3-baf9-11ce-8c82-00aa004ba90b}") ;
                          > > objType = Type.GetTypeFro mCLSID(IID_IInt ernetProtocolIn fo);
                          > > Activator.Creat eInstance(objTy pe);[/color]
                          >
                          > A bug in URLMon.dll. Activator.Creat eInstance calls CoCreateInstanc e
                          > querying for IUnknown. Rather than looking at the outer unknown, URLMon
                          > erroneously assumes that when an object is created and asked for
                          > IUnknown, the caller wants to aggregate the object. So it goes ahead and
                          > uses outer unknown without checking, but Activator.Creat eInstance passes
                          > NULL there. So the whole thing crashes with an AV. .NET marshaling
                          > catches the crash with a structured exception handler, and rethrows it
                          > as OutOfMemoryExce ption.
                          >
                          > I'm not familiar with C#, I don't know if there's a way to make it call
                          > CoCreateInstanc e asking for some interface other than IUnknown.
                          > --
                          > With best wishes,
                          > Igor Tandetnik
                          >
                          > "For every complex problem, there is a solution that is simple, neat,
                          > and wrong." H.L. Mencken
                          >
                          >[/color]


                          Comment

                          • Igor Tandetnik

                            #14
                            Re: Can create object using C++ CoCreateInstanc e, but not using C# Activator.Creat eInstance

                            "Brian Rogers" <none@none.co m> wrote in message
                            news:eBU6KgFuDH A.2148@TK2MSFTN GP12.phx.gbl...[color=blue]
                            > Pretty impressive. That definitely sounds plausible. I wonder if MS is[/color]
                            aware[color=blue]
                            > of the issue? Is this a problem you have encountered before when using
                            > interop?[/color]

                            No, I encountered this problem while working with APPs from C++. It's
                            easy to reproduce - just call CoCreateInstanc e with NULL outer and
                            asking for IUnknown. A resulting AV says it cannot dereference NULL
                            pointer, which I assume to be the outer.
                            --
                            With best wishes,
                            Igor Tandetnik

                            "For every complex problem, there is a solution that is simple, neat,
                            and wrong." H.L. Mencken


                            Comment

                            • Õíϼ¾ÉÓÑ

                              #15
                              Re: Can create object using C++ CoCreateInstanc e, but not using C# Activator.Creat eInstance


                              "Brian Rogers" <none@none.co m> дÈëÏûÏ¢ÐÂÎÅ
                              :#wfupbBuDHA.20 60@TK2MSFTNGP10 .phx.gbl...[color=blue]
                              > Hello everyone,
                              >
                              > I apologize for the cross and re-post, but I am still searching for an
                              > answer.
                              >
                              > Why can C++ can create this object, but C# can't?
                              >
                              > I am trying to create an instance of the default FTP asynchronous[/color]
                              pluggable[color=blue]
                              > protocol adaptor, so I can analyse the traffic between urlmon.dll (IE) and
                              > the FTP server. The language I am attempting to use is C#.
                              >
                              > The CLSID for the adaptor (as referenced in the protocol registry key) is
                              > {79eac9e3-baf9-11ce-8c82-00aa004ba90b} and is stored as CLSID_FtpProtoc ol.
                              >
                              > If I use the following unmanaged C++ code, I can create an instance of the
                              > filter.
                              >
                              > HRESULT result;
                              > LPUNKNOWN _pUnk = NULL;
                              > CoInitialize( NULL);
                              > result = CoCreateInstanc e( CLSID_FtpProtoc ol,
                              > NULL,
                              > CLSCTX_INPROC_S ERVER,
                              > IID_IInternetPr otocol,
                              > (LPVOID*)&_pUnk );
                              >
                              > If I use the following C# code, I receive an error. (OutOfMemoryExc eption)
                              >
                              > Guid IID_IInternetPr otocolInfo = new
                              > Guid("{79eac9e3-baf9-11ce-8c82-00aa004ba90b}") ;
                              > objType = Type.GetTypeFro mCLSID(IID_IInt ernetProtocolIn fo);
                              > Activator.Creat eInstance(objTy pe);
                              >
                              > Any thoughts would be greatly appreciated.
                              >
                              > Thanks,
                              > Brian.
                              >
                              >
                              >
                              >[/color]


                              Comment

                              Working...