Hello!, Its a well-known issue, that Boost-Thread users on Windows machines have observed that popular leak reporting tools loudly notify a missing delete for the dynamically allocated mutex in tss_hooks.cpp. A good overview for this discussion can be found in: http://groups.google.de/group/boost-list/browse_thread/thread/f5788746e458dd... While I don't want to heat up the discussion whether this is actually a "leak" or not, many code style guides of companies give very bad points on such behaviour, so I would like to ask whether it is possible to ensure a proper clean-up of this by code (before the system does), to keep those detector programs quiet... Simple question of a non-expert: Couldn't one simply change the current impl of on_process_exit in tss_hooks.cpp to extern "C" BOOST_THREAD_DECL void on_process_exit(void) { { // Wrap into scope boost::call_once(init_threadmon_mutex, once_init_threadmon_mutex); boost::mutex::scoped_lock lock(*threadmon_mutex); BOOST_ASSERT(attached_thread_count == 0); //Free the tls slot if one was allocated. if (tls_key != invalid_tls_key) { TlsFree(tls_key); tls_key = invalid_tls_key; } } delete threadmon_mutex; // Shouldn't that be the last point of access?? threadmon_mutex = 0; // For those who prefer a defined value... } OK, I see that the docs for this function says: "Must not be omitted; may be called multiple times." Question is: Does there exist at least the guarantee, that there is always the same number of on_process_enter and on_process_exit calls? If yes: Wouldn't a simply reference counting scheme using one of the atomic integer incrementing/decrementing functions (also provided by boost via interlocked.hpp) allow a thread-save deletion of that mutex object? Thanks for your patience, Daniel Krügler