Raymond Chen describes a technique for creating a fake agile wrapper in COM that uses the Global Interface Table to automatically release an object when its source apartment shuts down, addressing a problem with context callback failures.
<p>Last time, <a title="Making an agile version of a Windows Runtime delegate in C++/WinRT, part 10" href="https://devblogs.microsoft.com/oldnewthing/20260731-00/?p=112578"> we considered what it means when the context callback fails</a>, which prevents us from releasing the object in its original context. We noted that the problem is that when the original apartment tears down, we lose our chance to release the object.</p>
<p>What we want is something between a strong reference and a weak reference. We want a reference that is strong, but which releases its reference to the destination when the originating apartment tears down.</p>
<p>Is there such a thing?</p>
<p>It turns out that there is.</p>
<p>What we can do is register the object in the global interface table (historically known as the GIT, unrelated to the source control system). The usual reason for doing this is to allow the object to be accessed from another apartment by redeeming the registration cookie. We have no intention of accessing the object from another apartment, but we do this to take advantage of a feature of the GIT: References in the GIT are automatically released when the object’s apartment shuts down. The registration cookie remains valid, but if you try to redeem it, you are told that the server is no longer available.</p>
<p>So the idea here to register the original delegate in the GIT and save it in the agile wrapper. The agile wrapper then unregisters the delegate on destruction. We never redeem the registration cookie. The purpose of registering the delegate was not to access it from another apartment, but just to auto-release it when the original apartment tears down.</p>
<p>So let’s try it.</p>
<p>Next time.</p>
<p>The post <a href="https://devblogs.microsoft.com/oldnewthing/20260803-00/?p=112582">Creating a fake agile wrapper that is technically agile but is not useful outside its home apartment, part 1</a> appeared first on <a href="https://devblogs.microsoft.com/oldnewthing">The Old New Thing</a>.</p>
# Creating a fake agile wrapper that is technically agile but is not useful outside its home apartment, part 1 - The Old New Thing
Source: [https://devblogs.microsoft.com/oldnewthing/20260803-00?p=112582](https://devblogs.microsoft.com/oldnewthing/20260803-00?p=112582)
August 3rd, 2026
1 reaction

Last time,[we considered what it means when the context callback fails](https://devblogs.microsoft.com/oldnewthing/20260731-00/?p=112578), which prevents us from releasing the object in its original context\. We noted that the problem is that when the original apartment tears down, we lose our chance to release the object\.
What we want is something between a strong reference and a weak reference\. We want a reference that is strong, but which releases its reference to the destination when the originating apartment tears down\.
Is there such a thing?
It turns out that there is\.
What we can do is register the object in the global interface table \(historically known as the GIT, unrelated to the source control system\)\. The usual reason for doing this is to allow the object to be accessed from another apartment by redeeming the registration cookie\. We have no intention of accessing the object from another apartment, but we do this to take advantage of a feature of the GIT: References in the GIT are automatically released when the object’s apartment shuts down\. The registration cookie remains valid, but if you try to redeem it, you are told that the server is no longer available\.
So the idea here to register the original delegate in the GIT and save it in the agile wrapper\. The agile wrapper then unregisters the delegate on destruction\. We never redeem the registration cookie\. The purpose of registering the delegate was not to access it from another apartment, but just to auto\-release it when the original apartment tears down\.
So let’s try it\.
Next time\.
### Category
### Topics
## Author

Raymond has been involved in the evolution of Windows for more than 30 years\. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie\-jeebies\. The Web site spawned a book, coincidentally also titled The Old New Thing \(Addison Wesley 2007\)\. He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information\.
## Read next
## Stay informed
Get notified when new posts are published\.
Follow this blog
- [https://twitter.com/ChenCravat](https://twitter.com/ChenCravat)
- [](https://www.youtube.com/playlist?list=PLlrxD0HtieHge3_8Dm48C0Ns61I6bHThc)
- [https://github.com/oldnewthing](https://github.com/oldnewthing)
- [https://devblogs.microsoft.com/oldnewthing/feed/](https://devblogs.microsoft.com/oldnewthing/feed/)
Raymond Chen continues his series on creating a fake agile wrapper for non-marshalable COM objects by wrapping them in a marshalable object, enabling registration in the global interface table while preserving undefined-behavior-free failures in other apartments.
Raymond Chen continues his series on creating a fake agile wrapper in COM, explaining how to move non-marshalable objects by forwarding references into the force_marshal wrapper and discussing C++/WinRT deduction guides.
Raymond Chen explains how to use std::unique_ptr to manage a registration cookie in a fake agile wrapper, discussing integer-to-pointer round-tripping and the wil::unique_any alternative.
This article explains how to create an agile version of a Windows Runtime delegate in C++/WinRT by wrapping the delegate in an agile_ref, with a promise of more details in part 2.
Raymond Chen continues his series on building an agile Windows Runtime delegate in C++/WinRT, comparing how C++/WinRT, C++/CX, and WRL handle non-marshalable delegates and agile reference creation.