Code change:
use crate::io; use crate::mem; <del> use crate::sync; </del> <ins> use crate::ptr; </ins> use crate::sys::c; <del> /// The kinds of HashMap RNG that may be available #[derive(Clone, Copy, Debug, PartialEq)] enum HashMapRng { Preferred, Fallback, } </del> pub fn hashmap_random_keys() -> (u64, u64) { <del> match get_hashmap_rng() { HashMapRng::Preferred => { preferred_rng().expect("couldn't generate random bytes with preferred RNG") } HashMapRng::Fallback => { fallback_rng().expect("couldn't generate random bytes with fallback RNG") } } } /// Returns the HashMap RNG that should be used /// /// Panics if they are both broken fn get_hashmap_rng() -> HashMapRng { // Assume that if the preferred RNG is broken the first time we use it, it likely means // that: the DLL has failed to load, there is no point to calling it over-and-over again, // and we should cache the result static VALUE: sync::OnceLock<HashMapRng> = sync::OnceLock::new(); *VALUE.get_or_init(choose_hashmap_rng) } /// Test whether we should use the preferred or fallback RNG /// /// If the preferred RNG is successful, we choose it. Otherwise, if the fallback RNG is successful, /// we choose that /// /// Panics if both the preferred and the fallback RNG are both non-functional fn choose_hashmap_rng() -> HashMapRng { let preferred_error = match preferred_rng() { Ok(_) => return HashMapRng::Preferred, Err(e) => e, }; match fallback_rng() { Ok(_) => return HashMapRng::Fallback, Err(fallback_error) => panic!( "preferred RNG broken: `{}`, fallback RNG broken: `{}`", preferred_error, fallback_error ), } } /// Generate random numbers using the preferred RNG function (BCryptGenRandom) fn preferred_rng() -> Result<(u64, u64), io::Error> { use crate::ptr; </del> let mut v = (0, 0); let ret = unsafe { c::BCryptGenRandom(

Related discussion:
text: It have something to do with initializing the logs in , but I have no clue what specific small detail it is that breaks it <details<summaryExe code (not much interesting)</summary<p</p</details<details<summaryDLL code</summary rust-toolchain </p</details
Ok, I've submitted a fix. See the PR linked above. is tricky because of the loader lock and other tricks the OS does while a dll is loading.
I know is tricky, but is there any better option to do initialization, if I do not control the exe? And I need to fix the exe (by doing memory patches) before it reaches its .
Possibly not, which is why I filed a fix. Using the std in only works on a "best effort" basis. We do try to support it as much as reasonably possible but there are always going to be limitations due to the OS.
I get maybe a bit crazy idea, but my DLL hooks functions anyway, so if I would limit to and before the hooked main do my initialization. (for my use case any time before main is good enough) Would that eliminate wast majority of potential breaks related to ? Or is it not worth it?
Calling load_library in is susceptible to deadlocks unless the library is already loaded. I think you might just need to be very careful about the dependencies you use. Maybe there's a different or lighter weight logger you can use in place of log4js that doesn't use HashSet?
On further inspection it seems unlikely that fixes the issue although I still think it's a good cleanup and simplification (so I stand by my r+). That is, looking at your back trace... the deadlock you're hitting is from inside BCryptGenRandom itself, not from our code that synchronizes while calling it. It looks like BCryptGenRandom does some synchronizing when getting the preferred RNG (I guess). My hunch is for whatever reason this ends up needing to take the loader lock, and because the loader lock is already held inside , this causes a deadlock. If this is the case, I don't think there's a way for us to solve it... we can't detect it this in advance, nor is there a good alternative approach we can take that doesn't make things worse when outside (and/or on newer systems, which apparently works?). So I'm not sure what we can do about this.