Managed C++ Memory leak

Question

I am getting a memory leak whenver a new RPC thread in a DCOM server (c++ DCOM server) invokes the following managed C++ method

void CToolDataClient::SetLotManagerActive(bool bLotManagerActive)
{
  if( m_toolDataManager != nullptr)
  {
   m_toolDataManager->LotActive = bLotManagerActive;
  }
}

---

I get the managed C++ object pointer using the floowing code

typedef bool (*FPTR_CREATEINTERFACE)(CToolDataInterface ** ppInterface);

FPTR_CREATEINTERFACE fnptr = (FPTR_CREATEINTERFACE)GetProcAddress(hModule,(LPTSTR)"CreateInstance");
if ( NULL != fnptr ) 
{
  CICELogger::Instance()->LogMessage("CToolDataManager::CToolDataManager", Information, 
            "Created instance of DataManagerBridge");
  fnptr(&m_pToolDataInterface);
}

---

This is how I invoke the managed call in the DCOME server C++ portion

void CToolDataManager::SetLotManagerActive(bool bLotManagerActive)
{
    if(m_pToolDataInterface != NULL)
    {
        m_pToolDataInterface->SetLotManagerActive(bLotManagerActive);
    }
}

---

The callstack given below indicate the location of the memory leak . Is there any ways to solve this memory leak? Please help me

 ntdll!RtlDebugAllocateHeap+000000E1
 ntdll!RtlAllocateHeapSlowly+00000044
 ntdll!RtlAllocateHeap+00000E64
 mscorwks!EEHeapAlloc+00000142
 mscorwks!EEHeapAllocInProcessHeap+00000052
 **mscorwks!operator new[]+00000025
 mscorwks!SetupThread+00000238
 mscorwks!IJWNOADThunk::FindThunkTarget+00000019
 mscorwks!IJWNOADThunkJumpTargetHelper+0000000B
 mscorwks!IJWNOADThunkJumpTarget+00000048
 ICEScheduler!CToolDataManager::SetLotManagerActive+00000025** (e:\projects\ice\ice_dev\trunk\source\application source\iceschedulersystem\icescheduler\tooldatamanager.cpp, 250)
 ICEScheduler!SetLotManagerActive+00000014 (e:\projects\ice\ice_dev\trunk\source\application source\iceschedulersystem\icescheduler\schddllapi.cpp, 589)
 ICELotControl!CLotDetailsHandler::SetLotManagerStatus+0000006C (e:\projects\ice\ice_dev\source\application source\icelotsystem\icelotcontrol\lotdetailshandler.cpp, 1823)
 ICELotControl!CLotManager::StartJob+00000266 (e:\projects\ice\ice_dev\source\application source\icelotsystem\icelotcontrol\lotmanager.cpp, 205)
 RPCRT4!Invoke+00000030
 RPCRT4!NdrStubCall2+00000297
 RPCRT4!CStdStubBuffer_Invoke+0000003F
 OLEAUT32!CUnivStubWrapper::Invoke+000000C5
 ole32!SyncStubInvoke+00000033
 ole32!StubInvoke+000000A7
 ole32!CCtxComChnl::ContextInvoke+000000E3
 ole32!MTAInvoke+0000001A
 ole32!AppInvoke+0000009C
 ole32!ComInvokeWithLockAndIPID+000002E0
 ole32!ThreadInvoke+000001CD
 RPCRT4!DispatchToStubInC+00000038
 RPCRT4!RPC_INTERFACE::DispatchToStubWorker+00000113
 RPCRT4!RPC_INTERFACE::DispatchToStub+00000084
 RPCRT4!RPC_INTERFACE::DispatchToStubWithObject+000000C0
 RPCRT4!LRPC_SCALL::DealWithRequestMessage+000002CD
 RPCRT4!LRPC_ADDRESS::DealWithLRPCRequest+0000016D
 RPCRT4!LRPC_ADDRESS::ReceiveLotsaCalls+0000028F

Answer 1

First, is LotActive a member variable/field (pure data) or a property?

I think that it is a property, and before it can be set, the JIT has to compile the code for the setter. In desktop .NET, native code produced by the JIT compilation process is not garbage collected, instead it exists for the lifetime of the AppDomain, so it could look like a leak.

Can you check whether each call to this function leaks another object, or the leak just occurs once?