0

I have an managed .NET 2.0 dll that provides an IDispatch inteface and calls an IDispatch interface. Reading this question this question:

When to use ReleaseComObject vs FinalReleaseComObject?

It sounds as though I should be waiting for Garbage Collection to release my COM object references rather than attempting to count them myself. However when I do this, the unmanaged code calling my DLL throws an error (I don't have the source code to debug what the error is) but it indicates it's an unauthorized virtual memory access problem. Adding the FinalReleaseCOMObject stops this error.

Should I be using FinalReleaseCOMObject then?

EDIT: forgot to mention when the managed code is replaced by an unmanaged dll it does not exhibit the error.

Community
  • 1
  • 1
probably at the beach
  • 14,489
  • 16
  • 75
  • 116
  • 1
    You are just hiding a side-effect of a heap corruption problem. Which you'll no doubt have trouble finding, so if you found a hack around the problem then that *may* allow you to ignore it for a while. It can come back at any time, it tends to do so when the code is in production and gets slammed by real data. – Hans Passant May 30 '12 at 13:58
  • @HansPassant - thanks, that sounds like a resounding no. My thought was around the Application calling my DLL failing because it had released the COM object but the garbage collection hadn't got around to releasing COM object held in managed code. – probably at the beach May 30 '12 at 14:14

0 Answers0