memory problem when calling unmanaged code from managed code in Windows 7

Question

When I call an unmanaged C++ code from my C# code, I seem to have some kind of a memory leak.
The C++ reads data from a file using ifstream.read, and writes it to a Vector.

This happens only after upgrading to Windows 7, doesn't happen on Vista, but if I use a version of the native dll that was compiled on Vista, it doesn't change anything!
If I run the same C++ code directly, without the managed interope, there is no memory leak!
If I run the managed process, but within the vshost process, there is no memory leak!

Here's the call signature:

     [DllImport(DllPath, CharSet = CharSet.Unicode)]
 [return: MarshalAs(UnmanagedType.I1)]
 public static extern bool MyMethod(
  int x, 
  string y, 
  string z, 
  bool v, 
  bool w);

and the native one:

MyDll_Export bool APIENTRY MyMethod(
int x,
const wchar_t* y, 
const wchar_t* z,
bool v,
bool w)

hwen I call it from C++, I call it like this:

MyMethod(1, L"My String 1", L"My String 2", true, true)

When I look at the performance counters for managed and unmanaged memory, I see that all of the memory comes from the unmanaged code.
Considering that the marshaling is pretty simple, I don't understand why there is a difference between calling the C++ directly or through C#.
I also don't know why would this happen only on Windows 7 (both Windows installations had .net 3.5 SP1).

Does anyone have an idea what's the reason for this?

Also if anyone knows of a native memory profiling tool that works on Window 7, I'd be glad to know (for now I've just printed to console all explicit memory allocation and there are no differences).

Answer 1

Unfortunately once you involve strings, no marshalling is simple.

We're going to need some more data in order to help you track down this problem. Can you provide the following

• Native Method Signature
• How is the memory for the strings managed in native code?
• Perhaps the C++ sample where you use the API?

EDIT

Try the following signature. This tells the CLR not to marshal memory in both directions but instead only pass the data in.

    [DllImport(DllPath, CharSet = CharSet.Unicode)]
    [return: MarshalAs(UnmanagedType.I1)]
    public static extern bool MyMethod(
            int x, 
            [In] string  y, 
            [In] string  z, 
            bool    v, 
            bool    w);

Answer 2

I found the use of the CLR Profiler helpful when finding my memory leak.

Answer 3

Are you sure that there is a memory leak?

What is your basis for determining the memory leak. You say that you can see it from performance counters, but what do you actually observe? Do you see a coninously rising curve, or one that settles on a high level? A high memory consumption is often confused for a memory leak.

btw. Can you post you C++ function definition as well?

Answer 4

I'm sure the problem is related to marshaling the C# data types to their C++ counter parts. Since you are marshaling the return value bool to a signed 1 byte value, maybe you should do the same to the function arguments? The C# bool type is 4 bytes, maybe you are leaking there?

Also, specifying the unmanaged type for the strings may help.

[DllImport(DllPath, CharSet = CharSet.Unicode)]
[return: MarshalAs(UnmanagedType.I1)]
public static extern bool MyMethod(
        int x,
        [MarshalAs(UnmanagedType.LPWStr)]
        [In] string y,
        [MarshalAs(UnmanagedType.LPWStr)]
        [In] string z,
        [MarshalAs(UnmanagedType.I1)]
        bool v,
        [MarshalAs(UnmanagedType.I1)]
        bool w);

An explanation for the commentor:

For the C++ bool type:

In general, a zero or null-pointer value is converted to false, any other value is converted to true.

...

The 1998 C++ Standard Library defines a specialization of the vector template for bool. The description of the class indicates that the implementation should pack the elements so that every bool only uses one bit of memory.

So, pretty much whatever value you use, you'll get a c++ boolean with the value true or false.

Answer 5

Since you're landing in C++ anyway, why not use C++/CLI instead of P/Invoke? You'll avoid all the marshalling magic and can easily create a .NET-friendlier API.