Hi,

We are using .NET MarshalByRef remoted object that we use in a COM Interop
scenario. When we try to access a member of the remoted object from COM
returned by a remoting method call, we get the following error:

<VSNET Debugger runtime error>

"Run-Time check failure #0 : The value of ESP was not properly saved across
a function call. This is usually a result of calling a function declared
with one calling convention with a function pointer declared with a
different calling convention."

<VSNET Debugger runtime error/>

Exemple to reproduce this:

<C# Code Class Lib>

[
System.Runtime.InteropServices.Guid("C5DDC244-4CFC-4f15-821B-787F9C0684D5")
]

public interface A

{

B GetB();

}

public class ImplA : A

{

B GetB()

{

B temp;

// Get B through .NET Remoting here...

...

return temp;

}

}

[
System.Runtime.InteropServices.Guid("97286132-A545-4965-9BE3-AC3E2C63ED9E")
]

public interface B

{

C GetC();

}

internal class ImplB : MarshalByRef, B

{

C GetC()

{

return new ImplC();

}

[
System.Runtime.InteropServices.Guid("97286132-A545-4965-9BE3-AC3E2C63ED9F")
]

public interface C

{

string Name{get;}

}

internal class ImplC : MarshalByRef, C

{

string Name

{

get{ return "Eric St-Onge" } };

}

}

<C# Code Class Lib/>

<C++ Win32 Console Client Code>

#include "stdafx.h"

#include <comdef.h>

#import <ClassLibrary1.tlb> auto_search

#include <iostream>

int _tmain(int argc, _TCHAR* argv[])

{

try

{

ClassLibrary1::APtr smartptr_A;

_com_util::CheckError( smartptr_A.CreateInstance("ClassLibrary1.A") );

ClassLibrary1::BPtr smartptr_B = smartptr_A->GetB();

ClassLibrary1::CPtr smartptr_C = smartptr_B->GetC();

_bstr_t name = smartptr_C->Name; // VSNET Debugger runtime error happen
here!!

std::cout << (const char*)name << std::endl;

}

catch( _com_error e )

{

std::cout << (const char*)(e.ErrorMessage()) << std::endl;

}

return 0;

}

<C++ Win32 Console Client Code/>

The workaround for this is to do a QueryInterface(C) on the object pointed
by smartptr_C before using it.

This only happens when objects are going through remoting boundaries.

This looks like a bug since the IDL clearly states that the interface
returned by GetC() is of type C and, when using standard COM objects, it is
not required to QueryInterface after the call returns. (if it was the case,
the code generated to produce the smart pointer would have called
QueryInterface on return of the GetC() call).

Is there a bug fix from MS for this or a known workaround using attributes
or something else? Or maybe we are doing something wrong that fools the CCW?

Thanks!

Eric