1578895 - mozilla::DoPathsPointToIdenticalFile fails with D000003A

Status: RESOLVED FIXED

(Firefox :: Launcher Process, defect)

Description

[Toshihito Kikuchi [:toshi]]

According to https://sql.telemetry.mozilla.org/queries/63732/source, the top failure of the launcher process is at mozilla::DoPathsPointToIdenticalFile, and its error code is D000003A.

Once a patch of https://bugzilla.mozilla.org/show_bug.cgi?id=1576697 is landed, we'll get fine-grained data, but possibly it's caued by NtOpenFile failing with STATUS_OBJECT_PATH_NOT_FOUND (= c000003a) and one possible scenario is the first-time launch from the installer. In the installation process, setup.exe is unzipped to %temp% and it will be deleted at the end of installation. It's possible that when the launcher process checks the parent process, it's already deleted from %temp%. We'd like to prove this theory.

Comment 1

[Molly Howell (she/her) (mostly inactive)]

Now that I've thought about this a little more, this really shouldn't be a problem, because when the installer starts the browser process, it always calls WaitForInputIdle() on it; we already have another reason (bug 1451366) for wanting the installer process to keep running until then. So I'm not sure what's up with those STATUS_OBJECT_PATH_NOT_FOUND errors, but I don't think it's this.

Comment 2

[Toshihito Kikuchi [:toshi]]

Thanks, Matt. I see WaitForInputIdle and a 10sec timeout should be enough to avoid the issue. I'll update the title and the component.

Comment 3

[Toshihito Kikuchi [:toshi]]

Attachment: Bug 1578895 - Compare NT paths if NtOpenFile failed with STATUS_OBJECT_PATH_NOT_FOUND. r=aklotz

We compare two file ids to check the current process is launched from the same
executable. However, our telemetry showed a number of Win7 users failed to open
a file handle of the parent process with STATUS_OBJECT_PATH_NOT_FOUND even
though we opened a process handle and retrieved a module path of the parent
process successfully. We don't have data to explain how this happens or why
this happens only on Win7, Win10 10240, and 10586.

To mitigate this situation, this patch introduces a logic to compare NT path
strings. The benefit from doing this is 1) we don't have to open a file handle
of a parent process executable and 2) when we get an NT path, a network drive
or a symbolic link is already solved.

This new logic is much faster, but we still compare file ids on the first
attempt to minimize the impact. We fall back to the new logic only if we
detect the STATUS_OBJECT_PATH_NOT_FOUND failure.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2e3d007effb8
Compare NT paths if NtOpenFile failed with STATUS_OBJECT_PATH_NOT_FOUND. r=aklotz

Comment 5

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/2e3d007effb8