{"id":6133,"date":"2006-09-19T20:37:00","date_gmt":"2006-09-19T20:37:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/vcblog\/2006\/09\/19\/mixing-deterministic-and-non-deterministic-cleanup\/"},"modified":"2019-02-18T18:54:42","modified_gmt":"2019-02-18T18:54:42","slug":"mixing-deterministic-and-non-deterministic-cleanup","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/mixing-deterministic-and-non-deterministic-cleanup\/","title":{"rendered":"Mixing deterministic and non-deterministic cleanup"},"content":{"rendered":"

Hi, my name is Alan Chan.  <\/span>I’m a software design engineer in Visual C++ libraries team.  <\/span>As the name suggests, my team owns some of the C\/C++ libraries such as ATL, MFC, CRT, STL, and OpenMP.  <\/span>Today, I’m going to talk about one very interesting COM interop bug that I have worked on recently.  <\/span><\/font><\/font><\/p>\n

\n

 <\/font><\/p>\n<\/p>\n

Basic scenario: We have a mixed MFC and .NET application.  <\/span>When the user presses a button in the application, it pops up a MFC dialog which hosts a managed control.   <\/span>This managed control implements IQuickActivate and is activated through <\/font><\/font>COleControlSite::QuickActivate()<\/font><\/a>.  <\/span>This function creates all the appropriate sinks – in this case IAdviseSinkEx and IPropertyNotifySink – and passes them to the managed control through <\/font>IQuickActivate::QuickActivate()<\/font><\/a>.  <\/span><\/font><\/font><\/p>\n

\n

<\/font><\/p>\n

 <\/p>\n

\n

W<\/font><\/p>\n

hen the user dismisses the dialog, the destructor of COleControlSite is called.  <\/span>The destructor disconnects all the sink COM objects that were passed in through QuickActivate(), deactivates the managed control, and deletes the sink COM objects. <\/span><\/font><\/font><\/p>\n

<\/span><\/font><\/font> <\/p>\n

<\/span><\/font><\/font>This works on the whole.  <\/span>However, if the user opens and closes the dialog repeatedly, the application will AV and crash.  <\/span>If you read the title, you can probably guess what’s happening!  <\/span>It turns out that the garbage collector (GC) is calling IUnknown::Release() on the IAdviseSinkEx and IPropertyNotifySink COM objects after they have been deleted.<\/font><\/font><\/p>\n

 <\/p>\n

As most of you know already, whenever a COM object is passed from native code to managed code, the .Net framework creates <\/font>Runtime-Callable Wrappers (RCW)<\/font><\/a> automatically.  <\/span>The RCW wraps the object and controls lifetime.   <\/span>In this case, when the destructor of COleControlSite calls Unadvise() to disconnect the sinks, the managed control does, in fact, disconnect the sinks and drop all references to the RCWs of the sink objects.  <\/span>However, IUnknown::Release() is not called at this point.  <\/span>IUnknown::Release() is called in the RCW’s finalizer function.  <\/span>Dropping all references to the RCWs only means that the RCWs are eligible for garbage collection.  <\/span>The GC can collect these RCWs at anytime.  <\/span>Garbage collection is determined by memory pressure.  <\/span>If these RCWs were garbage collected and finalized after the actual sink COM objects have been deleted, it will cause an AV.<\/font><\/p>\n

 <\/p>\n

So how do we fix this?  <\/span>We need some way to clean up these RCWs deterministically.  <\/span>Sadly, RCW doesn’t implement <\/font>IDisposable interface<\/font><\/a> or else we could call <\/font>IDisposable::Dispose()<\/font><\/a> for cleanup.  <\/span>Fortunately, the framework provides a function, <\/font>Marshal.ReleaseComObject()<\/font><\/a>, for deterministic cleanup.  <\/span>Each RCW keeps a reference count of how many managed references are pointing to itself.  <\/span>(This is completely separated from the reference count in the COM object.)  <\/span>Every time you copy or QueryInterface() a managed COM reference, the RCW automatically increments its reference count.  <\/span>When ReleaseComObject() is called, the RCW decrements its reference count.  <\/span>As soon as the reference count reaches zero, the RCW will then call the finalizer function and release all the COM reference counts that it is holding deterministically.<\/font><\/p>\n

 <\/p>\n

Therefore, similar to calling IUnknown::Release() in native code, we should always call ReleaseComObject() on the managed COM references before it goes out of scope.  <\/span>This should guarantee that IUnknown::Release() is called deterministically.  <\/span><\/font><\/font><\/p>\n

<\/font><\/font> <\/p>\n

I hope this will save you time when debugging COM interop bugs.  <\/span><\/font><\/font><\/p>\n

\n

 <\/font><\/p>\n<\/p>\n

Thanks,<\/font><\/p>\n

Alan Chan<\/font><\/p>\n

Visual C++ Libraries Team.<\/font><\/p>\n


<\/span><\/p>\n

\n

 <\/font><\/p>\n<\/p>\n

\n

 <\/font><\/p><\/p>\n","protected":false},"excerpt":{"rendered":"

Hi, my name is Alan Chan.  I’m a software design engineer in Visual C++ libraries team.  As the name suggests, my team owns some of the C\/C++ libraries such as ATL, MFC, CRT, STL, and OpenMP.  Today, I’m going to talk about one very interesting COM interop bug that I have worked on recently.    […]<\/p>\n","protected":false},"author":289,"featured_media":35994,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-6133","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cplusplus"],"acf":[],"blog_post_summary":"

Hi, my name is Alan Chan.  I’m a software design engineer in Visual C++ libraries team.  As the name suggests, my team owns some of the C\/C++ libraries such as ATL, MFC, CRT, STL, and OpenMP.  Today, I’m going to talk about one very interesting COM interop bug that I have worked on recently.    […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/6133","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/users\/289"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/comments?post=6133"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/6133\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media\/35994"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media?parent=6133"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/categories?post=6133"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/tags?post=6133"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}