Reputation: 25969
I have a managed assembly that makes calls to an unmanaged assembly. In the unmanaged assembly I can use the CRT library to hunt for memory leaks, but most of the times it's the managed assembly that also makes calls to the unmanaged assembly to clean up certain things.
A call to the unmanaged assembly could for instance return a pointer to some unmanaged memory. It will then be marhalled to managed memory and after that, a call to the unmananged assembly will be done to free the unmanaged memory.
So, is it possible to use CRT from the managed assembly? Or are there other tools in VS2012 to do memory leak detection from a C# library (since that is a managed library, I'd find it strange to see memory leak tools there...).
Upvotes: 0
Views: 380
Reputation: 942197
This very rarely comes to a good end. A typical Windows install can easily have handful of distinct versions of the CRT dll. Common ones are msvcrt.dll, msvcr70.dll, msvr71.dll, msvcr80.dll, msvcr90.dll, msvcr100.dll, msvcr110.dll, msvcr120.dll. You see the pattern, no doubt. Especially the msvcr80 and msvcr90 versions are tricky, they require a manifest to get loaded since they are stored in the Windows side-by-side cache (c:\windows\winsxs).
You'll also have a problem with unmanaged code that doesn't use the DLL version of the CRT at all. Fairly common for DLLs that were designed to be used as a general purpose library, they'll have the CRT code linked into the DLL itself, /MT compile option.
A mismatch between the one you load and the one that the DLL uses is fatal, you'll always end up using the wrong allocator since the CRT creates its own heap.
In the specific case of <crtdbg.h>
, this just isn't necessary. Your managed code won't allocate CRT memory at all so cannot cause leaks either. The only thing you need to do is ensure that the leak report is generated. Use _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF) so it is automatic. Don't ship the Debug build.
Upvotes: 1