Bugzilla

This is now fixed in Nightly:
- Following the STR in comment 19 with [Firefox Nightly 2023-02-27-21-47-33](https://ftp.mozilla.org/pub/firefox/nightly/2023/02/2023-02-27-21-47-33-mozilla-central/) leads to a startup crash with both 32-bit and 64-bit builds.
- Following the STR in comment 19 with [Firefox Nightly 2023-02-28-08-53-39](https://ftp.mozilla.org/pub/firefox/nightly/2023/02/2023-02-28-08-53-39-mozilla-central/) leads to normal startup.

The vast majority of crashes are with 32-bit builds, and the string recovery in the investigation from comment 9 more precisely suggests that this a majority of 32-bit builds running on a 64-bit system. This correlation could be explained by the fact that the Windows system itself can maybe cope with failing to load 32-bit `bcryptprimitives.dll` on a 64-bit system, but not with other variations (i.e. corrupt 64-bit DLL on 64-bit system, or corrupt 32-bit DLL on 32-bit system) where it may refuse to boot. Note that although failing to load `bcryptprimitives.dll` seems to be the root cause for the vast majority of crashes, `BCryptGenRandom` can fail for other reasons, and the patch should fix those situations as well *provided that `BCryptGenRandom` fails consistently*. For the situations where `BCryptGenRandom` may fail *intermittently*, those will only fixed properly by bug 1816953.

For the hook to take place with 64-bit build on the versions which I tested, I had to [manually add support for some specific instructions](https://hg.mozilla.org/integration/autoland/rev/a5eb0191c293#l5.12) in our hooking code. Those instructions were in the 13 first bytes for `BCryptGenRandom` on my Windows 7 and Windows 11 64-bit variants of `bcrypt.dll`. If we still see crashes with 64-builds after the patch, that could be explained either by *`BCryptGenRandom` consistent failures* and *non-supported instructions in our hooking code*, and in that case we could look for the 13 first bytes of the `bcrypt.dll` version found in the crashes and implement them, or by `BCryptGenRandom` intermittent failures, since we only try to hook if the first call to `BCryptGenRandom` fails. This is not a problem for 32-bit builds, where `BCryptGenRandom` has [a hot-patch point](https://devblogs.microsoft.com/oldnewthing/20110921-00/?p=9583), so we can apply a hooking strategy that does not require us to implement specific code for each possible variation of the first bytes of the function.

This is now fixed in Nightly:
- Following the STR in comment 19 with [Firefox Nightly 2023-02-27-21-47-33](https://ftp.mozilla.org/pub/firefox/nightly/2023/02/2023-02-27-21-47-33-mozilla-central/) leads to a startup crash with both 32-bit and 64-bit builds.
- Following the STR in comment 19 with [Firefox Nightly 2023-02-28-08-53-39](https://ftp.mozilla.org/pub/firefox/nightly/2023/02/2023-02-28-08-53-39-mozilla-central/) leads to normal startup.

The vast majority of crashes are with 32-bit builds, and the string recovery in the investigation from comment 9 more precisely suggests that this a majority of 32-bit builds running on a 64-bit system. This correlation could be explained by the fact that the Windows system itself can maybe cope with failing to load 32-bit `bcryptprimitives.dll` on a 64-bit system, but not with other variations (i.e. corrupt 64-bit DLL on 64-bit system, or corrupt 32-bit DLL on 32-bit system) where it may refuse to boot. Note that although failing to load `bcryptprimitives.dll` seems to be the root cause for the vast majority of crashes, `BCryptGenRandom` can fail for other reasons, and the patch should fix those situations as well *provided that `BCryptGenRandom` fails consistently*. For the situations where `BCryptGenRandom` may fail *intermittently*, those will only fixed properly by bug 1816953.

For the hook to take place with 64-bit builds on the versions which I tested, I had to [manually add support for some specific instructions](https://hg.mozilla.org/integration/autoland/rev/a5eb0191c293#l5.12) in our hooking code. Those instructions were in the 13 first bytes for `BCryptGenRandom` on my Windows 7 and Windows 11 64-bit variants of `bcrypt.dll`. If we still see crashes with 64-builds after the patch, that could be explained either by *`BCryptGenRandom` consistent failures* and *non-supported instructions in our hooking code*, and in that case we could look for the 13 first bytes of the `bcrypt.dll` version found in the crashes and implement them, or by *`BCryptGenRandom` intermittent failures*, since we only try to hook if the first call to `BCryptGenRandom` fails. This is not a problem for 32-bit builds, where `BCryptGenRandom` has [a hot-patch point](https://devblogs.microsoft.com/oldnewthing/20110921-00/?p=9583), so we can apply a hooking strategy that does not require us to implement specific code for each possible variation of the first bytes of the function.

This is now fixed in Nightly:
- Following the STR in comment 19 with [Firefox Nightly 2023-02-27-21-47-33](https://ftp.mozilla.org/pub/firefox/nightly/2023/02/2023-02-27-21-47-33-mozilla-central/) leads to a startup crash with both 32-bit and 64-bit builds.
- Following the STR in comment 19 with [Firefox Nightly 2023-02-28-08-53-39](https://ftp.mozilla.org/pub/firefox/nightly/2023/02/2023-02-28-08-53-39-mozilla-central/) leads to normal startup.

The vast majority of crashes are with 32-bit builds, and the string recovery in the investigation from comment 9 more precisely suggests that this a majority of 32-bit builds running on a 64-bit system. This correlation could be explained by the fact that the Windows system itself can maybe cope with failing to load 32-bit `bcryptprimitives.dll` on a 64-bit system, but not with other variations (i.e. corrupt 64-bit DLL on 64-bit system, or corrupt 32-bit DLL on 32-bit system) where it may refuse to boot. Note that although failing to load `bcryptprimitives.dll` seems to be the root cause for the vast majority of crashes, `BCryptGenRandom` can fail for other reasons, and the patch should fix those situations as well *provided that `BCryptGenRandom` fails consistently*. For the situations where `BCryptGenRandom` may fail *intermittently*, those will only be fixed properly by bug 1816953.

For the hook to take place with 64-bit builds on the versions which I tested, I had to [manually add support for some specific instructions](https://hg.mozilla.org/integration/autoland/rev/a5eb0191c293#l5.12) in our hooking code. Those instructions were in the 13 first bytes for `BCryptGenRandom` on my Windows 7 and Windows 11 64-bit variants of `bcrypt.dll`. If we still see crashes with 64-builds after the patch, that could be explained either by *`BCryptGenRandom` consistent failures* and *non-supported instructions in our hooking code*, and in that case we could look for the 13 first bytes of the `bcrypt.dll` version found in the crashes and implement them, or by *`BCryptGenRandom` intermittent failures*, since we only try to hook if the first call to `BCryptGenRandom` fails. This is not a problem for 32-bit builds, where `BCryptGenRandom` has [a hot-patch point](https://devblogs.microsoft.com/oldnewthing/20110921-00/?p=9583), so we can apply a hooking strategy that does not require us to implement specific code for each possible variation of the first bytes of the function.