/azp run

looks good. do you have a synthetic test that shows the problem and validates the fix?

Something seems fishy here. unique_threadpool_wait calls WaitForThreadpoolWaitCallbacks in its destructor, so scenario doesn't seem possible, assuming everything is working as designed. In particular, registry_watcher_state cannot be fully deleted during an invocation of the callback.

You do mention:

TryAddRef() is reached and accesses destroyed member m_refCount

which may technically have some merit to it since m_refCount is declared after m_threadPoolWait in the definition of registry_watcher_state. That said, longs are trivially destructible, so this is only a "technically wrong" thing and unlikely to be observable in practice, outside of something like a Debug build or ASan/UBSan etc.

I'll second Chris' question - I'd like to know more about the scenario where you've seen issues.