1708587 - Nightly x86 on ARM64 error 0x800000003 on first launch with launcher process

Status: NEW

(Firefox :: Launcher Process, defect, P3)

Description

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

STR:

• Remove any pre-existing registry values in HKCU\SOFTWARE\Mozilla\Firefox\Launcher (at least those relating to the install dir we're about to install into)
• Install 32-bit Nightly from archive.mozilla.org (e.g. this installer)
• Run Nightly from the installer

Result: A firefox.exe dialog box pops up with error 0x80000003.

Tested on a Lenovo YOGA C630 with Windows 10 Version 20H2 (OS Build 19042.928).

Launching Nightly again from the desktop works, but if I remove the Launcher registry values then it will fail the next time, so I assume this is due to how the launcher process is launching the browser process, and it gives up on subsequent attempts since the process it launched didn't come up cleanly.

This does not occur with Release 88.0, though it does occur on the last Nightly 88.0a1 (2021-03-22-09-35-09, linked above) and on the last Nightly 87.0a1 (2021-02-22-08-44-06), so it may be something specific to Nightly, maybe with EARLY_BETA_OR_EARLIER?

Comment 1

[Toshihito Kikuchi [:toshi]]

Thank you for reporting this. I got a chance to run Windows 10 Arm64 on Raspberry Pi 4 and reproduce this issue.

(In reply to Adam Gashlin (he/him) [:agashlin] from comment #0)

This does not occur with Release 88.0, though it does occur on the last Nightly 88.0a1 (2021-03-22-09-35-09, linked above) and on the last Nightly 87.0a1 (2021-02-22-08-44-06), so it may be something specific to Nightly, maybe with EARLY_BETA_OR_EARLIER?

Yes, the crashing code is behind EARLY_BETA_OR_EARLIER here.

The crash happens on MOZ_RELEASE_ASSERT here because we incorrectly called IsDependentModule while loading kernel32.dll.

The root cause is the condition !ModuleLoadFrame::ExistsTopFrame() here. By default, when an x86 process on Arm64 loads kernel32.dll, it loads ntdll.dll via the CHPE version of LdrLoadDll and maps it via the x86 version of NtMapOfViewSection. The launcher process only applies hooks on x86 functions, so unlike a native process, NtMapOfViewSection for kernel32.dll was invoked without passing through LdrLoadDll. I have some ideas to fix this.

There is a workaround. When I turned on Disable hybrid execution mode in the compatibility setting of firefox.exe, it launches correctly with the launcher process enabled, but it makes the process very slow.