WINRT_NO_MODULE_LOCK conflicts with uninit_apartment()

[X1aomu]

WINRT_NO_MODULE_LOCK can cause application to crash if the Windows system automatically unloads unused DLLs.

See the test code below.

#define WINRT_NO_MODULE_LOCK

#include <winrt/Windows.Foundation.h>
#include <winrt/Windows.Devices.Bluetooth.h>

#include <thread>

using namespace ::winrt;
using namespace Windows::Foundation;
using namespace Windows::Devices::Bluetooth;

int main()
{
    {
        std::thread t([]
        {
            init_apartment();
            {
                [[maybe_unused]] auto adapter = BluetoothAdapter::GetDefaultAsync().get();
            }

            // sleep at least 30s so that DLLs will be unloaded when uninit_apartment is called (don't know exactly why)
            std::this_thread::sleep_for(std::chrono::seconds(35));

            clear_factory_cache();
            uninit_apartment();
        });
        t.join();
    }
    {
        std::thread t([]
        {
            init_apartment();
            {
                [[maybe_unused]] auto adapter = BluetoothAdapter::GetDefaultAsync().get();
            }
            clear_factory_cache();
            uninit_apartment();
        });
        t.join();
    }
    return 0;
}

This code causes an access violation reading exception.

After the fisrt time we call Consume(), DLLs were loaded, and an factory_cache_entry was set.

With WINRT_NO_MODULE_LOCK defined, the factory_cache_entry will not be added to the cache entry list.
As a result, the factory_cache_entry has no chance to be clear. However, without WINRT_NO_MODULE_LOCK, the factory_cache_entry could be clear by clear_factory_cache(). Windows system may unload DLLs further (i don't know exactly why and when), so an access violation could happen.

This is dangerous, as this code seems no harm to me, which an init_apartment() is always paired with an uninit_apartment(), and clear_factory_cache() when uninit_apartment() to ensure nothing is cache when there is no apartment.

I've found some ways to keep an extra MTA alive which prevent DLLs from being unloaded. Is this reliable and it it a good way?

IMO, this isn't good enough. If this code is inside a common lib, It assume that the application that using this lib must have a MTA alive all the time when running.

[kennykerr]

This is by design: #1031

Using WINRT_NO_MODULE_LOCK means you want DLLs to remain pinned and clear_factory_cache has no effect.

The trouble is that you're calling CoUninitialize (via uninit_apartment) which may force COM to tear down and unload DLLs that you have expected will remain loaded. Calling CoUninitialize is very dangerous and should be done very carefully.

Don't call it (preferred) or don't use WINRT_NO_MODULE_LOCK.

[X1aomu]

Thanks for reply.

I'm still a little confused. Microsoft doc says

A thread must call CoUninitialize once for each successful call it has made to the CoInitialize or CoInitializeEx function, including any call that returns S_FALSE. Only the CoUninitialize call corresponding to the CoInitialize or CoInitializeEx call that initialized the library can close it.

This means CoInitilaize and CoUninitialze should appear in pairs, which could usually implemented by RAII. WINRT_NO_MODULE_LOCK may break such things.

Just now, I know that WINRT_NO_MODULE_LOCK conflcts with uninit_apartment. The question is, without WINRT_NO_MODULE_LOCK defined, what is the use case of uninit_apartment? In other word, any bad thing would happen if we don't call uninit_apartment?

[kennykerr]

There's theory and there's practice. In theory you should pair them and for secondary STA threads that's usually the right thing to do... usually. For MTA threads its practically impossible to guarantee that it is safe to call CoUninitialize, ever. That has nothing to do with C++/WinRT. It's just the reality of COM and the unpredictability of COM object lifetimes in an open system. If you happen to control every object and every reference to every object in the entire object graph, directly and indirectly, then you could in theory make this work but Windows apps are rarely that simple. Not calling CoUninitialize just means the MTA remains alive until the process exits at which point everything is cleaned up reliably. This is far more predictable and reliable.