none
How to ensure that all COM-objects were properly destroyed? RRS feed

  • Question

  • I use Active Scripting in .NET application.

    How I can ensure that all COM-objects that created during interaction were properly destroyed?

    Maybe there are any articles or blog-posts about this?

    Or maybe there are any special tools?


    • Edited by Sergey Popov Wednesday, December 7, 2011 4:04 AM
    Wednesday, December 7, 2011 4:04 AM

Answers

  • The COM object needs to be released by itself. So, on COM side, you need to implement IDispose to release memory.

    On .NET side, we can use Marshal.ReleaseComObject Method to decrements the reference count of the specified Runtime Callable Wrapper (RCW) associated with the specified COM object. It just used for .NET reference to COM object.

     

    Paul Zhou [MSFT]
    MSDN Community Support | Feedback to us
    • Marked as answer by Paul Zhou Wednesday, December 14, 2011 6:18 AM
    Thursday, December 8, 2011 8:31 AM
  • It depends on the COM object. Ideally COM object should release all resources when their reference counter reaches zero but some COM objects can have different behavior (depends on how they are written). From within .NET, we can *request* release of COM objects through the use of Marshal::ReleaseCOMObject() and Marshal::FinalReleaseCOMObject() methods but these methods do not gaurantee that the COM object will be released.

    See this thread for similar discussion.


    Click the 'Vote as Helpful' arrow if this post was helpful.
    • Marked as answer by Paul Zhou Wednesday, December 14, 2011 6:18 AM
    Thursday, December 8, 2011 12:13 PM
  • An example would be useful, but to come out with an extreme position I'd say that you can't. All you can do is create the COM objects, and make sure you increment/decrement ref counts properly if you have actual control over them. When an object has no references it should destroy itself. There's nothing about COM that requires IDispose because COM predates .NET and IDispose. If the object doesn't destroy itself it may be a bug, but on the other hand some COM implementations may choose to cache unused objects to save initialization time next time one is requested.  A more interesting question is why do you care? COM is interfaced-based, and you don't get to vote on an object's internals unless it exposes them to you, and that includes what it does when its reference count goes to zero.
    Phil Wilson
    • Marked as answer by Paul Zhou Wednesday, December 14, 2011 6:19 AM
    Thursday, December 8, 2011 7:42 PM

All replies

  • One way is - check all objects that implement IDisposable and call Dispose on them.
    Please mark this post as answer if it solved your problem. Happy Programming!
    Wednesday, December 7, 2011 6:15 AM
  • The COM object needs to be released by itself. So, on COM side, you need to implement IDispose to release memory.

    On .NET side, we can use Marshal.ReleaseComObject Method to decrements the reference count of the specified Runtime Callable Wrapper (RCW) associated with the specified COM object. It just used for .NET reference to COM object.

     

    Paul Zhou [MSFT]
    MSDN Community Support | Feedback to us
    • Marked as answer by Paul Zhou Wednesday, December 14, 2011 6:18 AM
    Thursday, December 8, 2011 8:31 AM
  • It depends on the COM object. Ideally COM object should release all resources when their reference counter reaches zero but some COM objects can have different behavior (depends on how they are written). From within .NET, we can *request* release of COM objects through the use of Marshal::ReleaseCOMObject() and Marshal::FinalReleaseCOMObject() methods but these methods do not gaurantee that the COM object will be released.

    See this thread for similar discussion.


    Click the 'Vote as Helpful' arrow if this post was helpful.
    • Marked as answer by Paul Zhou Wednesday, December 14, 2011 6:18 AM
    Thursday, December 8, 2011 12:13 PM
  • An example would be useful, but to come out with an extreme position I'd say that you can't. All you can do is create the COM objects, and make sure you increment/decrement ref counts properly if you have actual control over them. When an object has no references it should destroy itself. There's nothing about COM that requires IDispose because COM predates .NET and IDispose. If the object doesn't destroy itself it may be a bug, but on the other hand some COM implementations may choose to cache unused objects to save initialization time next time one is requested.  A more interesting question is why do you care? COM is interfaced-based, and you don't get to vote on an object's internals unless it exposes them to you, and that includes what it does when its reference count goes to zero.
    Phil Wilson
    • Marked as answer by Paul Zhou Wednesday, December 14, 2011 6:19 AM
    Thursday, December 8, 2011 7:42 PM