GMock crashes on exit (WatcherThreadFunc) when used from third-party test harness

[SiriusTR]

Hello! I'm using GMock from a third-party unit test harness, and I started noticing these tests were occasionally generating crashes after they finished running. Recently they became more consistent, which enabled me to figure out the culprit; the tests are in a .DLL, and at the end of execution, the DLL is unloaded, but there is a GMock-created watcher thread (testing::internal::ThreadLocalRegistryImpl::WatcherThreadFunc) that is still running.

This thread appears to be created from the following stack:

testing::internal::ThreadLocalRegistryImpl::StartWatcherThreadFor
testing::internal::ThreadLocalRegistryImpl::GetValueOnCurrentThread+0x25c
testing::internal::ThreadLocal<testing::Sequence *>::GetOrCreateValue+0x13
testing::internal::ThreadLocal<testing::Sequence *>::pointer+0x13
testing::internal::ThreadLocal<testing::Sequence *>::get+0x13
testing::internal::FunctionMocker<void __cdecl(unsigned __int64,unsigned char const *)>::AddNewExpectation+0x100
testing::internal::MockSpec<void __cdecl(unsigned __int64,unsigned char const *)>::InternalExpectedAt+0x1c7

Looking at the implementation of ThreadLocal, I see the following comments:

// Google Test only uses global ThreadLocal objects.  That means they
// will die after main() has returned.  Therefore, no per-thread
// object managed by Google Test will be leaked as long as all threads
// using Google Test have exited when main() returns.

OK, great - so it looks like the key is making sure ThreadLocal is cleaned up properly. Unfortunately, this test harness doesn't have a main() function I can edit (it works a lot like CppUnitTestFramework, as illustrated by this StackOverflow post - it looks like I'm not the first one to encounter the crash either). What's the appropriate way to ensure ThreadLocal is correctly wound down in this case? I note there is a place to put post-test cleanup code, but it doesn't run on the initial thread.

Thanks!