{"id":109198,"date":"2023-12-28T07:00:00","date_gmt":"2023-12-28T15:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=109198"},"modified":"2023-12-29T09:08:07","modified_gmt":"2023-12-29T17:08:07","slug":"20231228-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20231228-00\/?p=109198","title":{"rendered":"On calling Afx­Connection­Advise<\/CODE> with bAddRef<\/CODE> set to FALSE<\/CODE>"},"content":{"rendered":"

A customer had a question about the Afx\u00adConnection\u00adAdvise<\/code> function when you set bAddRef<\/code> to FALSE<\/code>.<\/p>\n

According to the documentation<\/a>,<\/p>\n

\n
BOOL AFXAPI AfxConnectionAdvise(\r\n    LPUNKNOWN pUnkSrc,\r\n    REFIID iid,\r\n    LPUNKNOWN pUnkSink,\r\n    BOOL bRefCount,\r\n    DWORD FAR* pdwCookie);\r\n<\/pre>\n
bRefCount<\/i> 
\nTRUE indicates that creating the connection should cause the reference count of pUnkSink<\/i> to be incremented. FALSE indicates that the reference count should not be incremented.<\/p>\n<\/blockquote>\n
They are passing FALSE<\/code> for bAddRef<\/code> when they connect to an out-of-process COM server. What they found is that not only does this suppress the increment of the sink’s reference count, it in fact does a spurious decrement<\/i> of the reference count, causing the sink to be destroyed.<\/p>\n
The customer looked at  the source code for Afx\u00adConnection\u00adAdvise<\/code><\/a> and saw that if you pass FALSE<\/code> for bAddRef<\/code>, then it calls Release<\/code> on the sink after a successful registration.<\/p>\n
BOOL AFXAPI AfxConnectionAdvise(LPUNKNOWN pUnkSrc, REFIID iid,\r\n    LPUNKNOWN pUnkSink, BOOL bRefCount, DWORD* pdwCookie)\r\n{\r\n    ASSERT_POINTER(pUnkSrc, IUnknown);\r\n    ASSERT_POINTER(pUnkSink, IUnknown);\r\n    ASSERT_POINTER(pdwCookie, DWORD);\r\n\r\n    BOOL bSuccess = FALSE;\r\n\r\n    LPCONNECTIONPOINTCONTAINER pCPC;\r\n\r\n    if (SUCCEEDED(pUnkSrc->QueryInterface(\r\n                    IID_IConnectionPointContainer,\r\n                    (LPVOID*)&pCPC)))\r\n    {\r\n        ASSERT_POINTER(pCPC, IConnectionPointContainer);\r\n\r\n        LPCONNECTIONPOINT pCP;\r\n\r\n        if (SUCCEEDED(pCPC->FindConnectionPoint(iid, &pCP)))\r\n        {\r\n            ASSERT_POINTER(pCP, IConnectionPoint);\r\n\r\n            if (SUCCEEDED(pCP->Advise(pUnkSink, pdwCookie)))\r\n                bSuccess = TRUE;\r\n\r\n            pCP->Release();\r\n\r\n            \/\/ The connection point just AddRef'ed us.  If we don't want to\r\n            \/\/ keep this reference count (because it would prevent us from\r\n            \/\/ being deleted; our reference count wouldn't go to zero),\r\n            \/\/ then we need to cancel the effects of the AddRef by calling\r\n            \/\/ Release.\r\n\r\n            if (bSuccess && !bRefCount)\r\n                pUnkSink->Release();\r\n        }\r\n\r\n        pCPC->Release();\r\n    }\r\n\r\n    return bSuccess;\r\n}\r\n<\/pre>\n
It is apparent from the comment “The connection point just AddRef’ed us” that Afx\u00adConnection\u00adAdvise<\/code> expects the IConnectionPoint::Advise<\/code> method to increment the reference count of the sink, because it is doing a bonus Release<\/code> to counteract that AddRef<\/code>.<\/p>\n
Is this a valid assumption?<\/p>\n
No.<\/p>\n
One case where IConnectionPoint::Advise<\/code> would not increment the reference count on the sink is the somewhat pathological case where the source knows that it will never call the event sink, so there’s no point remembering it.<\/p>\n
It’s like if somebody hands you a slip of paper and says, “Make sure to call this number if the antenna falls down,” but your television set doesn’t have an antenna at all. In that case, you can just throw away the slip of paper since you know you will never need it.<\/p>\n
Now, as I noted, this is a rather pathological case. After all, a connection point container is unlikely to advertise a connection point that does nothing.\u00b9<\/p>\n
The customer is encountering another case, though: Reference count aggregation through a proxy.<\/p>\n
When a COM object is passed to another context (in this case, to another process), the client receives a proxy object. To reduce cross-context chatter, each proxy retains a single reference to the real object on the other side, and any local reference counts are aggregated in the proxy.<\/p>\n
For example, suppose we have an object on the server with a single reference held by a client process.<\/p>\n\n\n\n\n\n\n
Server<\/td>\n <\/td>\nClient<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\npObject<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n\u21d3<\/td>\n<\/tr>\n
Object
\nrefcount = 1<\/td>\n		\ud83e\udc44<\/td>\nObject proxy
\nrefcount = 1<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
In these diagrams, heavy arrows are those that cross process boundaries.<\/p>\n
If the client calls pObject->AddRef()<\/code> to increment the reference count, COM merely increments the reference count of the proxy. It doesn’t send an AddRef<\/code> call over the wire to the server. After the client calls AddRef<\/code>, we have this:<\/p>\n\n\n\n\n\n\n
Server<\/td>\n <\/td>\nClient<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\npObject<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n\u21d3<\/td>\n<\/tr>\n
Object
\nrefcount = 1<\/td>\n		\ud83e\udc44<\/td>\nObject proxy
\nrefcount =  \u00a0<\/span> 2 <\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Notice that the reference count of the proxy has gone up to 2, but there is no change to the reference count of the original object on the server. The proxy aggregates all the references from the client, and only a single reference count is retained from the proxy to the original object. When the proxy’s reference count drops to zero, then the proxy is destroyed, and only then does the proxy send a Release<\/code> to the original object.<\/p>\n
Okay, now we can set up our story. Suppose you register the same sink against multiple connection points in a remote process. From the point of view of the sink, those remote processes are all clients. (Of course, from the point of view of the connection points, your process is the client.)<\/p>\n
ComPtr<IDispatch> sink = \u27e6 create a sink \u27e7;\r\nComPtr<IConnectionPoint> point1 = \u27e6 some remote object \u27e7;\r\nComPtr<IConnectionPoint> point2 = \u27e6 some remote object \u27e7;\r\n\r\nDWORD cookie1, cookie2;\r\npoint1->Advise(sink.Get(), &cookie1);\r\npoint2->Advise(sink.Get(), &cookie2);\r\n<\/pre>\n
This is what things look like before the first Advise<\/code>:<\/p>\n\n\n\n\n\n\n\n\n\n
You<\/td>\n\u00a0<\/td>\nThem<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n <\/td>\n<\/tr>\n
point1<\/code><\/td>\n\u21d2<\/td>\nPoint1 Proxy
\nrefcount = 1<\/td>\n		\ud83e\udc46<\/td>\nPoint1 Object
\nrefcount = 1<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n <\/td>\n<\/tr>\n
sink<\/code><\/td>\n\u21d2<\/td>\nSink Object
\nrefcount = 1<\/td>\n		 <\/td>\n <\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n <\/td>\n<\/tr>\n
point2<\/code><\/td>\n\u21d2<\/td>\nPoint2 Proxy
\nrefcount = 1<\/td>\n		\ud83e\udc46<\/td>\nPoint2 Object
\nrefcount = 1<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The only reference to the sink object is the one you hold in the sink<\/code> local variable.<\/p>\n
After the first Advise<\/code>, the Point1 object now holds a reference to the Sink Object, through its own proxy on their side.<\/p>\n\n\n\n\n\n\n\n\n\n
You<\/td>\n\u00a0<\/td>\nThem<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n <\/td>\n<\/tr>\n
point1<\/code><\/td>\n\u21d2<\/td>\nPoint1 Proxy
\nrefcount = 1<\/td>\n		\ud83e\udc46<\/td>\nPoint1 Object
\nrefcount = 1<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n\n
\u00a0<\/div>\n
\u21d3<\/div>\n<\/td>\n<\/tr>\n
sink<\/code><\/td>\n\u21d2<\/td>\nSink Object
\nrefcount =  \u00a0<\/span> 2 <\/span><\/td>\n		\n
\u00a0<\/div>\n
\ud83e\udc44<\/div>\n<\/td>\n
\n
\u00a0<\/div>\n
Sink Proxy
\nrefcount = 1<\/div>\n<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n <\/td>\n<\/tr>\n
point2<\/code><\/td>\n\u21d2<\/td>\nPoint2 Proxy
\nrefcount = 1<\/td>\n		\ud83e\udc46<\/td>\nPoint2 Object
\nrefcount = 1<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
With the second Advise<\/code>, things get interesting:<\/p>\n\n\n\n\n\n\n\n\n\n
You<\/td>\n\u00a0<\/td>\nThem<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n <\/td>\n<\/tr>\n
point1<\/code><\/td>\n\u21d2<\/td>\nPoint1 Proxy
\nrefcount = 1<\/td>\n		\ud83e\udc46<\/td>\nPoint1 Object
\nrefcount = 1<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n\u21d3<\/td>\n<\/tr>\n
sink<\/code><\/td>\n\u21d2<\/td>\nSink Object
\nrefcount = 2<\/td>\n		\ud83e\udc44<\/td>\nSink Proxy
\nrefcount =  \u00a0<\/span> 2 <\/span><\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n\n
\u00a0<\/div>\n
\u21d1<\/div>\n<\/td>\n<\/tr>\n
point2<\/code><\/td>\n\u21d2<\/td>\nPoint2 Proxy
\nrefcount = 1<\/td>\n		\ud83e\udc46<\/td>\nPoint2 Object
\nrefcount = 1<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
COM realizes that it already has a proxy for the sink object on their side, so instead of creating a second proxy, it just reuses the existing one. When Point2<\/code> calls AddRef<\/code> to retain a reference to the sink, the AddRef<\/code> is cached by the proxy, and no AddRef<\/code> happens on the original sink.<\/p>\n
What we did above was roughly equivalent to calling Afx\u00adConnection\u00adAdvise<\/code> with bAddRef<\/code> set to TRUE<\/code>.<\/p>\n
Now let’s do it again with bAddRef<\/code> set to FALSE<\/code>.<\/p>\n
ComPtr<IDispatch> sink = \u27e6 create a sink \u27e7;\r\nComPtr<IConnectionPoint> point1 = \u27e6 some remote object \u27e7;\r\nComPtr<IConnectionPoint> point2 = \u27e6 some remote object \u27e7;\r\n\r\nDWORD cookie1, cookie2;\r\npoint1->Advise(sink.Get(), &cookie1);\r\nsink->Release(); \/\/ New!\r\n\r\npoint2->Advise(sink.Get(), &cookie2);\r\nsink->Release(); \/\/ New!\r\n<\/pre>\n
Everything is the same through the first Advise<\/code>:<\/p>\n\n\n\n\n\n\n\n\n\n
You<\/td>\n\u00a0<\/td>\nThem<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n <\/td>\n<\/tr>\n
point1<\/code><\/td>\n\u21d2<\/td>\nPoint1 Proxy
\nrefcount = 1<\/td>\n		\ud83e\udc46<\/td>\nPoint1 Object
\nrefcount = 1<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n\n
\u00a0<\/div>\n
\u21d3<\/div>\n<\/td>\n<\/tr>\n
sink<\/code><\/td>\n\u21d2<\/td>\nSink Object
\nrefcount =  \u00a0<\/span> 2 <\/span><\/td>\n		\n
\u00a0<\/div>\n
\ud83e\udc44<\/div>\n<\/td>\n
\n
\u00a0<\/div>\n
Sink Proxy
\nrefcount = 1<\/div>\n<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n <\/td>\n<\/tr>\n
point2<\/code><\/td>\n\u21d2<\/td>\nPoint2 Proxy
\nrefcount = 1<\/td>\n		\ud83e\udc46<\/td>\nPoint2 Object
\nrefcount = 1<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
But this time, since bAddRef<\/code> is FALSE<\/code>, the Afx\u00adConnection\u00adAdvise<\/code> function tries to undo the AddRef<\/code> performed by the connection point by doing a sink->Release()<\/code>.<\/p>\n\n\n\n\n\n\n\n\n\n
You<\/td>\n\u00a0<\/td>\nThem<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n <\/td>\n<\/tr>\n
point1<\/code><\/td>\n\u21d2<\/td>\nPoint1 Proxy
\nrefcount = 1<\/td>\n		\ud83e\udc46<\/td>\nPoint1 Object
\nrefcount = 1<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n\u21d3<\/td>\n<\/tr>\n
sink<\/code><\/td>\n\u21d2<\/td>\nSink Object
\nrefcount =  \u00a0<\/span> 1 <\/span><\/td>\n		\ud83e\udc44<\/td>\nSink Proxy
\nrefcount = 1<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n <\/td>\n<\/tr>\n
point2<\/code><\/td>\n\u21d2<\/td>\nPoint2 Proxy
\nrefcount = 1<\/td>\n		\ud83e\udc46<\/td>\nPoint2 Object
\nrefcount = 1<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The sink object’s reference count is back down to 1, so it’s as if the sink proxy’s AddRef<\/code> had never occurred.<\/p>\n
Now we do the second Advise<\/code>:<\/p>\n\n\n\n\n\n\n\n\n\n
You<\/td>\n\u00a0<\/td>\nThem<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n <\/td>\n<\/tr>\n
point1<\/code><\/td>\n\u21d2<\/td>\nPoint1 Proxy
\nrefcount = 1<\/td>\n		\ud83e\udc46<\/td>\nPoint1 Object
\nrefcount = 1<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n\u21d3<\/td>\n<\/tr>\n
sink<\/code><\/td>\n\u21d2<\/td>\nSink Object
\nrefcount = 1<\/td>\n		\ud83e\udc44<\/td>\nSink Proxy
\nrefcount =  \u00a0<\/span> 2 <\/span><\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n\n
\u00a0<\/div>\n
\u21d1<\/div>\n<\/td>\n<\/tr>\n
point2<\/code><\/td>\n\u21d2<\/td>\nPoint2 Proxy
\nrefcount = 1<\/td>\n		\ud83e\udc46<\/td>\nPoint2 Object
\nrefcount = 1<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The AddRef<\/code> from the second connection point to the sink is cached in the proxy and is not communicated to the original sink in the server process.<\/p>\n
Nevertheless, Afx\u00adConnection\u00adAdvise<\/code> sees that bAddRef<\/code> is set to FALSE<\/code>, so it performs a second sink->Release()<\/code>, and bad things happen:<\/p>\n\n\n\n\n\n\n\n\n\n
You<\/td>\n\u00a0<\/td>\nThem<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n <\/td>\n<\/tr>\n
point1<\/code><\/td>\n\u21d2<\/td>\nPoint1 Proxy
\nrefcount = 1<\/td>\n		\ud83e\udc46<\/td>\nPoint1 Object
\nrefcount = 1<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n\u21d3<\/td>\n<\/tr>\n
sink<\/code><\/td>\n\u21d2<\/td>\nSink Object
\nrefcount =  \u00a0<\/span> 0 <\/span><\/td>\n		\ud83e\udc44<\/td>\nSink Proxy
\nrefcount = 2<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n\u21d1<\/td>\n<\/tr>\n
point2<\/code><\/td>\n\u21d2<\/td>\nPoint2 Proxy
\nrefcount = 1<\/td>\n		\ud83e\udc46<\/td>\nPoint2 Object
\nrefcount = 1<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Oh no, the sink object’s reference count has dropped to zero! This destructs the sink, leaving the sink<\/code> variable and the sink proxy with pointers to freed memory.<\/p>\n\n\n\n\n\n\n\n\n\n
You<\/td>\n\u00a0<\/td>\nThem<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n <\/td>\n<\/tr>\n
point1<\/code><\/td>\n\u21d2<\/td>\nPoint1 Proxy
\nrefcount = 1<\/td>\n		\ud83e\udc46<\/td>\nPoint1 Object
\nrefcount = 1<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n\u21d3<\/td>\n<\/tr>\n
sink<\/code><\/td>\n\u21d2<\/td>\n\n
\u00a0<\/div>\n
(freed memory)<\/div>\n<\/td>\n
\ud83e\udc44<\/td>\nSink Proxy
\nrefcount = 2<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n\u21d1<\/td>\n<\/tr>\n
point2<\/code><\/td>\n\u21d2<\/td>\nPoint2 Proxy
\nrefcount = 1<\/td>\n		\ud83e\udc46<\/td>\nPoint2 Object
\nrefcount = 1<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The original authors of Afx\u00adConnection\u00adAdvise<\/code> made an invalid assumption, namely that a successful Advise<\/code> necessarily increments the reference count on the sink. In the case of remote connection points, the reference counts of those remote connection points are aggregated on the remote side, and only a single reference count is maintained on the server side. The Release()<\/code> call thinks it is counteracting the AddRef()<\/code> on the client side, but really it’s counteracting a nonexistent AddRef()<\/code> on the server side.<\/p>\n
You break the COM rules at your own peril.<\/p>\n
Moral of the story: This is a design flaw in Afx\u00adConnection\u00adAdvise<\/code>. Do not call it with bAddRef<\/code> set to FALSE<\/code>. Instead of playing games with COM reference counts trying to simulate a weak reference, use a proper weak reference to the sink.<\/p>\n
\u00b9 And it may end up not being a valid implementation anyway, because the connection point is expected to produce those clients in response to IConnectionPoint::Enum\u00adConnections<\/code>, so it is obligated to retain references to them even though it has no use for them.<\/p>\n","protected":false},"excerpt":{"rendered":"
Playing fast and loose, and eventually you get burnt.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-109198","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Playing fast and loose, and eventually you get burnt.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/109198","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=109198"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/109198\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=109198"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=109198"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=109198"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}