main thread random context doesn't reinitialize correctly with non-weak source
TLDR is that _mi_auto_process_init attempts to reseed the main thread's random ctx (which would cause BCrypt to get loaded there) but there's a bug preventing that from working.
Starting point:
https://github.com/microsoft/mimalloc/blob/09a27098aa6e9286518bd9c74e6ffa7199c3f04e/src/init.c#L580
_mi_auto_process_init calls mi_heap_main_init which on _WIN32 && !MI_SHARED_LIB builds calls _mi_random_init_weak for bcrypt-related reasons.
Then, we call _mi_random_reinit_if_weak at the end of _mi_auto_process_init
https://github.com/microsoft/mimalloc/blob/09a27098aa6e9286518bd9c74e6ffa7199c3f04e/src/init.c#L600-L601
BUT, that will never actually do anything.
Why? The mi_random_ctx_t weak bool will always be false after any call to mi_random_init_ex.
Why? At the end of mi_random_init_ex, for either the weak or normal path, we call chacha_init.
And what does that guy do? Memsets the entire mi_random_ctx_t to zero, wiping out the weak bool.
https://github.com/microsoft/mimalloc/blob/09a27098aa6e9286518bd9c74e6ffa7199c3f04e/src/random.c#L97-L102
We discovered this when we saw a thread was doing the mimalloc BCrypt-related initialization (e.g. LoadLibrary) during the initialization of a thread, which involved calling LoadLibrary a couple times and holding an internal BCrypt critical section while the thread initialization has the loader lock held (because the root calloc in that new thread is inside of __vcrt_getptd_noexit). So it seems, given the above mentioned code, that it's not intended that we'd be leaving the main thread's initialization without initializing the BCrypt stuff?