I would like to create a dll library that will be loading in runtime. The library'll be using internally COM objects with MTA flag. The library will be created in main thread.

So I have question: Where there is best place where can I call 'CoInitializeEx' and 'CoUninitialize' functions. In the my dll(init/deinit functions) or client should call directly these functions?

I prefer first option. I would like avoid public dependig on COMs. Client shouldn't know I'm using COMs, but also I'd like avoid crashes when client unload my lib(then I call 'CoUninitialize' for my lib) and other libs(depend on COM) will be in undefined state.



#ifndef API_H
#define API_H

class Provider;

define API __declspec(dllexport)

using ErrCode = int;

extern "C" {
  API ErrCode init(Provider** provider);
  API ErrCode deinit();



#include <Objbase.h>

Provider* prov;

API ErrCode init(Provider** provider)
  const auto res = CoInitializeEx(nullptr, COINIT_MULTITHREADED);
  // create provider
  // then I can use any com object

  *provider = prov;

API ErrCode deinit()

client code

#include <Windows.h>

class Provider;

typedef ErrCode (*f_init)(Provider**);
typedef ErrCode (*f_deinit)();

int main(int /*argc*/, char** /*argv*/)
  auto lib = LoadLibrary("my_lib.dll");

  auto init = (f_init)GetProcAddress(lib, "init");
  auto deinit = (f_deinit)GetProcAddress(lib, "deinit");

  Provider* prov;

  // do something


  return 0;

  • 1
    What does "publicly depending" mean? When you distribute this dll are you distributing these com objects? – candied_orange Jul 30 '19 at 23:57
  • @candied_orange In the 'public depending' I mean dependency about 'COM' world. If I want use these object I have to initialize 'COM' by the call 'CoInitalizeEx' function and when the library is no longer needed I call 'CoUninitialize', but if another client code use COM's the app may crash after release my lib. For the easiest understand, I've update main post and I added sample code which show what I'd like achieve. No don't distributing these com objects. – pbieguszewski Jul 31 '19 at 17:17
  • Do you actually have (need) a technical requirement that your DLL be unloadable? (That is, the requirement that certain cleanup code needs to be executed, and afterwards all resources need to be cleanly released, when the client calls FreeLibrary.) In my opinion, for all non-trivial COM DLL code I've seen so far, I've not encountered a case where a "clean" cleanup and release is ever achievable. Once a COM DLL is loaded into a process, you better assume that it will stay with the process, until the process terminates. If there's requirement (e.g. to delete the file), use multiple processes. – rwong Dec 28 '19 at 23:39

Microsoft advises against calling these from the Dll load/unload functions:

Because there is no way to control the order in which in-process servers are loaded or unloaded, do not call CoInitialize, CoInitializeEx, or CoUninitialize from the DllMain function.



  • 1
    Yes, I understand. I don't wanted call these function in DllMain. – pbieguszewski Jul 31 '19 at 17:19
  • @pbieguszewski: Putting those calls in functions that should be called on load/unload of your DLL leads to the exact same problems as why Microsoft issued this advice. – Bart van Ingen Schenau Aug 2 '19 at 11:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.