Bugzilla

This crash occurs while `kisfdpro64.dll` is reading `xul.dll` entirely in memory, to search for patterns in it. When it hits the `.retplne` section, it crashes because of its access rights, as it is not allowed to read these pages. In 114, `xul.dll` did not have a `.retplne` section; [possibly because we were using a different SDK version](https://bugzilla.mozilla.org/show_bug.cgi?id=1546498#c14) (were we?). See also the bugs I am attaching.

We may have a different problem that our blocklist code fails to setup properly on Windows 7, which would also explain our problems in bug 1833793. As far as I can tell the crash spike with 115.0 is mostly Windows 7 users, and a bit of Windows 10 1809 (10.0.17763) users. The crash spike with 115.0 release is mostly Windows 7 users, and a bit of Windows 10 1809 (10.0.17763) users. Windows 10 22H2 (10.0.19045) users do not seem impacted even though it was a high proportion of the crashes in beta, before we blocked the DLLs.

This crash occurs while `kisfdpro64.dll` is reading `xul.dll` entirely in memory, to search for patterns in it. When it hits the `.retplne` section, it crashes because of its access rights, as it is not allowed to read these pages. In 114, `xul.dll` did not have a `.retplne` section; [possibly because we were using a different SDK version](https://bugzilla.mozilla.org/show_bug.cgi?id=1546498#c14) (were we?). See also the bugs I am attaching.

We may have a different problem that our blocklist code fails to setup properly on Windows 7 (and Windows 10 1809), which would also explain our problems in bug 1833793. The crash spike with 115.0 release is mostly Windows 7 users, and a bit of Windows 10 1809 (10.0.17763) users. Windows 10 22H2 (10.0.19045) users do not seem impacted even though it was a high proportion of the crashes in beta, before we blocked the DLLs.

This crash occurs while `kisfdpro64.dll` is reading `xul.dll` entirely in memory, to search for patterns in it. When it hits the `.retplne` section, it crashes because of its access rights, as it is not allowed to read these pages. In 114, `xul.dll` did not have a `.retplne` section; [possibly because we were using a different SDK version](https://bugzilla.mozilla.org/show_bug.cgi?id=1546498#c14) (were we?). See also the bugs I am attaching.

We may have a different problem that our blocklist code fails to setup properly on Windows 7 (and Windows 10 1809), which would also explain our problems in bug 1833793. The crash spike with 115.0 release is mostly Windows 7 users, and a bit of Windows 10 1809 (10.0.17763) users. Windows 10 22H2 (10.0.19045) users do not seem impacted even though it was a high proportion of the crashes in beta, before we blocked the DLLs; so the blocking seems to work for them.

This crash occurs while `kisfdpro64.dll` is reading `xul.dll` entirely in memory, to search for patterns in it. When it hits the `.retplne` section, it crashes because of its access rights, as it is not allowed to read these pages. In 114, `xul.dll` did not have a `.retplne` section; [because we were using a different SDK version](https://bugzilla.mozilla.org/show_bug.cgi?id=1546498#c14) (bug 1832467, thanks [:RyanVM]). See also the bugs I am attaching.

We may have a different problem that our blocklist code fails to setup properly on Windows 7 (and Windows 10 1809), which would also explain our problems in bug 1833793. The crash spike with 115.0 release is mostly Windows 7 users, and a bit of Windows 10 1809 (10.0.17763) users. Windows 10 22H2 (10.0.19045) users do not seem impacted even though it was a high proportion of the crashes in beta, before we blocked the DLLs; so the blocking seems to work for them.

This crash occurs while `kisfdpro64.dll` is reading `xul.dll` entirely in memory, to search for patterns in it. When it hits the `.retplne` section, it crashes because of its access rights, as it is not allowed to read these pages. In 114, `xul.dll` did not have a `.retplne` section; probably [because we were using a different SDK version](https://bugzilla.mozilla.org/show_bug.cgi?id=1546498#c14) (bug 1832467, thanks [:RyanVM]). See also the bugs I am attaching.

We may have a different problem that our blocklist code fails to setup properly on Windows 7 (and Windows 10 1809), which would also explain our problems in bug 1833793. The crash spike with 115.0 release is mostly Windows 7 users, and a bit of Windows 10 1809 (10.0.17763) users. Windows 10 22H2 (10.0.19045) users do not seem impacted even though it was a high proportion of the crashes in beta, before we blocked the DLLs; so the blocking seems to work for them.