For Windows App SDK, “it will get cleaned up when the process dies.” This is also mentioned in the thread about Windows App SDK by Raymond Chen. "The app simply exits and doesn't tear down the frame. This follows the principle of 'When the process is exiting, don't bother cleaning up.' "
And add that “It's very very rarely a good idea to call CoUninitialize
. Tearing down the apartment means that any subsequent destructors can't assume they are running in a valid apartment and they typically do. It's best to just let the process unwind and die without ever calling CoUninitialize unless you are in a highly controlled environment, which is not the case in this kind of project.”
Also, “The thing about CoInitialize/CoUninitialize is to remember that they aren’t a global process thing; they control the state of COM on a particular thread. For the main application thread, there’s no need to uninit COM as the process is on its way out. In fact, attempting to do so will probably cause more problems, unless you can painstakingly ensure that the uninit will occur after all your other COM-related destructors run (aka global/static objects).
The main use case that comes to mind for making sure to pair up CoInitialize/CoUninitialize COM calls is for when you are creating and destroying threads. But you rarely, if ever, want to do that yourself. Use the C++/WinRT coroutine+support instead.”
Further Reading: when the building is being demolished, don’t bother sweeping the floor.