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: I tried this code: I expected it to work on Windows 7 the same as it works on other platforms. Instead, this happened: the code get stuck in the initialization of logging, we acquired same-ish stack from multiple people using Windows 7 It was always calling ! On Windows 10 as under Wine the application starts normally My rust code produces DLL that is loaded by C++ application from 10 years ago Latest working version: Earliest version that gets stuck:
seems possibly relevant, but since this is just hanging, I’m not sure we can blame it all on snake oil this time. Though maybe? Wouldn’t be the first time it breaks the system in incomprehensible ways. First and foremost – could you minimize the reproducer? Both from the perspective of the Rust code (sounds like simply calling from should suffice?) and the OS setup (does this occur on a fresh OS install? If not, what modifications are necessary for the reduced reproducer to start hanging)
The nightly that it first started failing under is the first nightly after was merged, which just happens to be directly related to ? That's really whack given that the stack trace above shows the hang taking place just before any of the changes that PR introduced are invoked.
I personally do not have Windows 7, and would prefer not not bother players with more testing unless really necessary. But I can confirm that at least one of the systems was clean Windows 7 Home Premium from . And calling directly seems pretty complicated :( It requires calling which still requires knowing which algorithm to chose, and what flags to use :( I also see this in the documentation: and this in the code: , but unfortunately I can not say how relevant that it.
It's unlikely to be a problem with itself as that works in the earlier version. Is this code being used in ? In any case, I think the fix here is to simplify the rng code so it's as close to the old version as possible.
Yes logging is initialized in DllMain, I will soon post a very small example
So it is related to it being library.