Is the calling application / thread responsible for calling CoInitialize / CoUninitialize?
Yes. Typically, the thread creator should be responsible for initializing COM. This means that the functions you expose from your DLL do not have to initialize COM for the thread to which they were called.
The reason is that if you take responsibility for initializing COM in the thread that calls the DLL, this creates an unreasonable restriction on the creator of this thread. What if the creator of the thread has to perform another action that requires COM initialization? Standard practice is that a DLL indicates COM initialization as one of its requirements. In the documentation for your DLL, indicate that the caller should initialize COM.
Read more here: Things you shouldn't do, Part 2: Dlls can never call CoInitialize * in the application thread .
This is why you should not initialize COM in your DLL in the calling thread. There are even more reasons not to initialize COM in the initialization section. Initialization sections are performed inside the DllMain DLL. There are very few things that you can call inside DllMain ; COM functions are not on the list of allowed actions. For more information: Some reasons to not do anything wrong with your DllMain, part 3 .
What if I use ComObj inside my DLL, which automatically calls CoInitialize in the initialization section and CoUninitialize in the completion section?
The ComObj block ComObj not do this. For a DLL, the COM initialization code that you reference is suppressed. Enabling ComObj will result in the initialization of COM in the executable project, but not in the library.