We Keep Coding

"Unmanaged memory" at profiler diagram. Is this a memory leak indication?

I've faced with this diagram, when profiling memory usage of my application:
As you can see, before line "snapshot 1" unmanaged memory holds approximately a half of total used memory. Then, after "snapshot 1" and 2 min 55 s (see the timeline below), I've forced a garbage collection.
As I expect, generation 2 was mostly collected, but unmanaged memory was not released, and now it holds approx. 2/3 of total used memory.
I have no idea, what "unmanaged memory" means in this context.
This is the WPF application with some WinForms/GDI+ interop. I'm sure, that everything, that should be disposed, is disposed. Also, there's no explicit platform interop code. The rest of managed memory is OK.
Is this a memory leak indication?
If so, what is the way to detect memory leak here?
Is this matters, the profiler I'm using is JetBrains dotMemory.

"Total used" memory on dotMemory chart it's the private working set of process. It's memory that the process executable has asked for - not necessarily the amount it is actually using. It includes all your DLLs and heaps but not includes memory-mapped files (shared DLLs). Moreover there is no way to tell whether it belongs to executable itself, or to a linked library. It's not exclusively physical memory; they can be paged to disk or in the standby page list (i.e. no longer in use, but not paged yet either).
So, unmanaged memory is everything in private working set except managed CLR heaps. Usually you have no easy ways to change amount of unmanaged memory for pure .net process. And it's approximately constant during execution of program.

How to Manage Memory with Unmanaged C/C++ from C#.net?

Need some expert advice:
I have an unmanaged code from a 3rd party provider which is on C/C++ and I am writing a wrapper from C#.Net to get referred and use the respective methods. Since its unmanaged and there is a lot of places which has the memory leak and unmanaged code is not known to manage the memory what is the best solution for this kind of scenario?
I have the solution with PInvoke and Marshalling which bridges the Managed and Unmanaged with a knowledge of taking the memory management. But will GC takes care of this completely or is there still a gap which the memory should be released? Is there a solution from the .Net wrapper class i have a generic way to manage the memory for the unmanaged calls?

sharing memory between C# and native C++

is there a way to share memory between managed and native code, just like memory mapped files (I'am using .Net 2.0, so MMF is not available in this version), I'am new to this .Net, so what is actually marshalling? I've done this for communication between managed and unmanaged code, but my question is during marshaling do we copy the memory portion of unmanaged to managed memory area, or we share the same address space, thus when we change a variable from unmanaged code, then the value is changed too in managed code?

This post is a useful start point to gain some ideas about Marshaling between Managed and Unmanaged Code
you can skip the part related to [InAttribute] and [OutAttribute]

Free managed memory allocation from unmanaged code

I'd like to do Marshal.AllocHGlobal in managed code, fill it with data, and pass that memory block to unmanaged (C++) code that will then be responsible for freeing it.
Under the hood, Marshal.AllocHGlobal calls LocalAlloc (and, I'm guessing, LocalLock). But in order for the unmanaged code to call LocalFree, it needs the HLOCAL returned by LocalAlloc, which Marshal.AllocHGlobal doesn't provide.
I'm not necessarily restricted to using AllocHGlobal; the high level goal is to let the managed code allocate memory that the unmanaged code and then read and free.

This is not a handle, not since Windows version 3. Calling LocalFree() on the pointer is fine, as the Windows SDK article shows in its example. Marshal.AllocCoTaskMem and CoTaskMemFree() are the better mouse trap here.

Memory allocators for a native C++ library to be used by C#

I'm writing some native C++ code which needs to be called from C# (and I can't replace the C++ native code with C# code).
I found memory corruptions while allocating/deallocating some memory in the native C++ code using malloc/free. Then I used LocalAlloc/LocalFree and HeapAlloc/HeapFree and had the same problems.
The allocations/deallocations seem to be correct, and they happen in a separate thread, created by the native code.
I was wondering which is the best allocation strategy to use in a native C++ library called by C#
EDIT: found the problem: the problem wasn't in the allocation/deallocation code, but in some memory being written after being deallocated.

As long as the C# side of the code uses the compiler's /unsafe switch and the fixed keyword used for holding the buffer of data, I think you should be ok.
As to the question of your memory allocation, it may not be the C++ memory allocation code that is causing the problem, it could be the way how the C++ code is interacting with the driver...maybe using VirtualAlloc/VirtualFree pair as per the MSDN docs...
Edit: When you try to allocate the buffer to hold the data from the C++ side after interacting with the driver...possibly a race-condition or interrupt latency is causing a memory corruption...just a thought...
Hope this helps,
Best regards,
Tom.

Your question is missing essential details, it isn't at all clear whether the memory allocated by the C++ code needs to be released on the C# side. That's normally done automatically with, say, the P/Invoke marshaller or the COM interop layer in the CLR. Or can be done manually by declaring a method argument as IntPtr, then use of the Marshal class.
If it is done automatically you must use the COM memory allocator, CoTaskMemAlloc(). If you marshal yourself you could also use GlobalAlloc(), release on the C# side with Marshal.FreeHGlobal(). There isn't any advantage to using GlobalAlloc(), you might as well use CoTaskMemAlloc() and release with Marshal.FreeCoTaskMem().
But you should have noticed this yourself. Allocating with malloc() or HeapAlloc() on the C++ side causes leaks instead of corruption if the managed code releases the memory. Vista and Win7 have a much stricter heap manager, it terminates the program if it notices a bad release.
It sounds to me that you have simple heap corruption in your C++ code. That is the most common scourge of unmanaged C++ programming, over-running the end of a buffer, writing to memory that's been freed, bad pointer values. The way to get rid of bugs like these is a careful code review and use of a debug allocator, such as the one provided by <crtdbg.h>. Good luck with it.

The windows driver developpement kit recommend against the use of C++ for drivers.
Also the best strategy is to have the driver manage its own memory. When the c# needs to see the data then pass it a marshalled buffer and have the driver to fill it