Issues when working with Quill as DLL - missing log entries

[fahrudinhalilovic]

Hello, I'm trying to create a small test setup where the Quill library is "wrapped" into a DLL and there is a small executable which then implicitly loads this DLL. My main problem is that my test app simply shuts down while not a single log entry has been written yet (neither to the console nor file). I took a look at this issue #584 where author suggested to flush the log entries before unloading of the DLL takes a place - I mean on the case DLL_PROCESS_DETACH:. What I did for this case was the following:

    case DLL_PROCESS_DETACH:
        // it's sufficient to flush log for one logger since
        // in the background flushing will be done for all 
        // pending message no matter which logger they belong to
        if (auto logger = quill::Frontend::get_valid_logger(); logger) {
            logger->flush_log();
        }
        break;

But unfortunately, this does not work. This simply blocks entire shutdown procedure of my test app i.e. shutting down simply hangs and I do not see any log entries. Of course, if I execute following piece of the code at the end of my app (directly in the app code, not in the DLL wrapper or somewhere else) then log entries are properly displayed:

        if (auto logger = quill::Frontend::get_valid_logger(); logger) {
            logger->flush_log();
        }

Is this some sort of known issue which I missed in the docs somewhere or this is supposed to work actually? If I really have to call flush_log from the DLL consumer side is there any proposal on how to nicely wrap that into some RAII class. I thought maybe in my DLL wrapper I could somehow expose some static class which will then simply call flush_log for any logger and thus secure logging of log statements but as it's stated in the official docs flush_log can not be called from destructor of the static objects and I'm not even sure if that would be possible since calling flush_log at that point in time would be already too late because my app would probably have been already closed (I'm not fully sure how the lifecycle of the static objects in the DLL library actually works but since flush_log can not be called in the destructor of static object I gave up on further research here).

Somehow it does not feel right for the consumer side to explicitly call flush_log since the consumer can easily forget about that and thus miss some log entries. Also, this DLL will be linked by many other DLLs or static libs which are then all linked into a single app which increases the complexity of tracking if flush_log has been called or not.

[odygrd]

Thanks for the detailed report. I was able to reproduce this

Quill is an asynchronous logging library — log messages are enqueued by frontend threads and processed by a separate backend thread - This is important context for understanding the DLL behavior.

When Backend::start() is called from within a DLL, it registers a std::atexit handler that calls Backend::stop() to drain all pending messages and join the backend thread on shutdown. This works fine for normal (non-DLL) applications.

However, on Windows with MSVC, std::atexit handlers registered from a DLL do not run during the normal exit() sequence.

Instead, they run during DLL unload, which happens inside DLL_PROCESS_DETACH.

The problem is the Windows process shutdown order:

  1. main() returns → EXE's atexit handlers run (backend thread is still alive here)
  2. ExitProcess() is called → OS terminates all threads, including the backend thread
  3. DLL_PROCESS_DETACH fires
  4. DLL's atexit handlers run → Backend::stop() is called, but the backend thread is already dead

Since the backend thread was killed by the OS before it could drain the queues, all pending log messages are lost.

And this is also why your flush_log() call in DLL_PROCESS_DETACH hangs — it enqueues a flush event and busy-waits for the (dead) backend thread to acknowledge it, which never happens.

Workaround:

You can expose a flush_logging() function from your DLL wrapper and call it at the end of main() in the consuming application.

For RAII, you could expose a guard object from your DLL:

  // In your DLL header
  class LoggingGuard {
  public:
      ~LoggingGuard() { Backend::stop(); }
  };

  // In consumer's main()
  int main() {
      LoggingGuard guard;  // stop() runs when main() scope exits, before atexit/ExitProcess
      init_logging();
      // ... application code ...
  }

This works because the destructor of a local variable in main() runs before ExitProcess() kills threads.

Upcoming Fix

I have a fix planned for a future release (likely in 1–2 months). When Backend::stop() detects that the backend thread was terminated by the OS without draining its queues, it will drain them on the calling thread as a fallback. This will make the automatic cleanup work correctly in the DLL case without any changes on the consumer side.

[fahrudinhalilovic]

Thanks a lot for your extremely fast feedback. I've just tried out your workaround and works nicely. Maybe you can tag this discussion/issue with the potential fix version for the future references. Anyhow, I'm looking forward for the next release but until then workaround will just do the thing.