Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/8de824ba-5ad3-44e7-b6a4-ab0fb0220119

MOZ_CRASH Reason: couldn't generate random bytes: Der Vorgang wurde erfolgreich beendet. (os error 0)

Top 10 frames of crashing thread:

0 xul.dll RustMozCrash mozglue/static/rust/wrappers.cpp:17
1 xul.dll mozglue_static::panic_hook mozglue/static/rust/lib.rs:91
2 xul.dll core::ops::function::Fn::call<void  ../02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/ops/function.rs:227
3 xul.dll std::panicking::rust_panic_with_hook ../02072b482a8b5357f7fb5e5637444ae30e423c40//library/std/src/panicking.rs:610
4 xul.dll std::panicking::begin_panic_handler::closure$0 ../02072b482a8b5357f7fb5e5637444ae30e423c40//library/std/src/panicking.rs:502
5 xul.dll std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_handler::closure$0, never$> ../02072b482a8b5357f7fb5e5637444ae30e423c40//library/std/src/sys_common/backtrace.rs:139
6 xul.dll std::panicking::begin_panic_handler ../02072b482a8b5357f7fb5e5637444ae30e423c40//library/std/src/panicking.rs:498
7 xul.dll core::panicking::panic_fmt ../02072b482a8b5357f7fb5e5637444ae30e423c40//library/core/src/panicking.rs:107
8 xul.dll std::thread::local::fast::Key::try_initialize<core::cell::Cell<tuple$<u64, u64> >, core::cell::Cell<tuple$<u64, u64> >  ../02072b482a8b5357f7fb5e5637444ae30e423c40//library/std/src/thread/local.rs:613
9 xul.dll static env_logger::Builder::new third_party/rust/env_logger/src/lib.rs:406

Google translate says "Der Vorgang wurde erfolgreich beendet." means "The process ended successfully." There are a few other messages in non-English that occur after "couldn't generate random bytes", though this German one accounts for 71% of them.

It looks like we're initializing some Rust logger and then some initialization code failed. I'm not sure what could be causing that.

About half of these are in the RDD process. Another 27% are in content processes, and 23% are in socket processes.

Could this be some kind of sandboxing issue? Or maybe some weird resource starvation?

The Russian error message translates to "The system cannot find the specified environment setting". The French one translated to something else. It seems weird that the error messages in different languages don't really sound identical.

All on Windows 8.1 and Windows 7.

Don't tell me this is a return of https://github.com/rust-lang/rust/issues/88576 or some variant of it.

Relevant code that prints this error: https://github.com/rust-lang/rust/blob/master/library/std/src/sys/windows/rand.rs#L18

Also a large spread of versions and build ids... smells like a Windows update?

This signature is hitting the same issue. 32-bit Windows 7 this time.

Looking at the signature from comment 5, most of the errors are "Access is denied" (or its translation).

(In reply to Gabriele Svelto [:gsvelto] from comment #5)

This signature is hitting the same issue. 32-bit Windows 7 this time.

Yes, this is what was worked-around in https://bugzilla.mozilla.org/show_bug.cgi?id=1746254 (triggered from HashMap use in Glean) and what I am also tracking in https://bugzilla.mozilla.org/show_bug.cgi?id=1751177 (triggered from HashMap use in env_logger via gecko_logger)

(In reply to Alexandre LISSY :gerard-majax from comment #7)

(In reply to Gabriele Svelto [:gsvelto] from comment #5)

This signature is hitting the same issue. 32-bit Windows 7 this time.

Yes, this is what was worked-around in https://bugzilla.mozilla.org/show_bug.cgi?id=1746254 (triggered from HashMap use in Glean) and what I am also tracking in https://bugzilla.mozilla.org/show_bug.cgi?id=1751177 (triggered from HashMap use in env_logger via gecko_logger)

I can't speak for the signatures mentionned there, but I can repro bug 1751177 on my WIndows 7 64-bits VM running a 64-bits packaged debug firefox.

Bug 1746254 may help address some of these, but there's still crashes attributed to this signature from Nightly builds after that landed. Guess we'll take it into the Fx97 RC build and see how it goes, though.

Looking at the amount of crashes, it seems to have stopped since feb 1st, when bug 1751177 did land.

Fixed by bug 1751177.

Looks like we've gotten a couple reports from 98.0b2:
https://crash-stats.mozilla.org/report/index/ea116844-dca8-41b1-871a-469f50220209
https://crash-stats.mozilla.org/report/index/766cc726-b698-4354-8576-2f7310220209

Can you please take a look, Alexandre?

(In reply to Ryan VanderMeulen [:RyanVM] from comment #12)

Looks like we've gotten a couple reports from 98.0b2:
https://crash-stats.mozilla.org/report/index/ea116844-dca8-41b1-871a-469f50220209
https://crash-stats.mozilla.org/report/index/766cc726-b698-4354-8576-2f7310220209

Can you please take a look, Alexandre?

As pointed by toshi, it seems to not be a new issue: https://crash-stats.mozilla.org/search/?signature=%3Dstd%3A%3Acollections%3A%3Ahash%3A%3Amap%3A%3Aimpl%2481%3A%3Anew%3A%3AKEYS%3A%3A__getit%20%7C%20env_logger%3A%3ABuilder%3A%3Anew&product=Firefox&platform=Windows&process_type=parent&date=%3E%3D2021-11-09T15%3A26%3A00.000Z&date=%3C2022-02-09T15%3A26%3A00.000Z&_facets=signature&_facets=platform_version&_facets=cpu_arch&_sort=date&_columns=date&_columns=signature&_columns=version&_columns=platform_version&_columns=cpu_arch&_columns=process_type#crash-reports