Closed Bug 1603335 Opened 3 months ago Closed 10 hours ago

Firefox fails to open/visit any sites and displays only blank pages

Categories

(External Software Affecting Firefox :: Other, defect, P2)

x86_64
Windows 10
defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1614885

People

(Reporter: tpb261, Assigned: toshi)

References

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0

Steps to reproduce:

Updated Firefox Nightly to 73.0a1 and restarted it.
Tried to visit sites in new tabs.

Actual results:

The previous session was restored, but all tabs were left blank.
Attempts to any other sites also resulted in blank pages.

Expected results:

Sites should have loaded normally.

History:
Since Firefox 72.0a1 I have been seeing 0xc0000022 at starting of Firefox the first time. If I start it again there is no problem.
On my work laptop, with 73.0a1 neither the tabs from my previous session nor new tabs were getting loaded.
To debug, I started using mozregression as suggested here
During this I came across this bug and realized that at work we use Digital Guardian Agent (v7.4.2.002). After removing the fix provided in the linked bug Firefox works fine.

OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64

Thank you for filing a new bug. Can you confirm the FileVersion field of dgapi64.dll is also 7.4.2.2? I'd like to confirm this because our data shows some version of dgapi64.dll does not have a value in the file version field.

Flags: needinfo?(tpb261)

In my system, I do not have the dgapi dll file. I was able to find an installation log, where I see that it deleted the installed files from C:\Program Files and left some in a folder under C:\ - but there are no dlls here. I got the version from "Apps and Features" window.

Flags: needinfo?(tpb261)

Thank you for checking your system. Does your system stil have this blank page issue? The fix for Bug 1318858 is to prevent dgapi.dll and dgapi64.dll from being loaded into firefox.exe. If there no such DLLs, the issue will not happen.

If you're still having the issue and stil have a build environment mentioned in this thread, can you try a change like this?

-    DllBlocklistEntry("dgapi.dll", (7, 5, 0, 0xffff)),
-    DllBlocklistEntry("dgapi64.dll", (7, 5, 0, 0xffff)),
+    DllBlocklistEntry("dgapi.dll", (7, 4, 1, 0xffff)),
+    DllBlocklistEntry("dgapi64.dll", (7, 4, 1, 0xffff)),

I can see crash data with dgapi v7.4.1.xxx and v7.5.0.xxx, but nothing with v7.4.2 nor v7.5.1. This crash might be fixed in two release branches (7.4 and 7.5) of Digital Guradian.

Flags: needinfo?(tpb261)
See Also: → 1318858

(In reply to Toshihito Kikuchi [:toshi] from comment #4)

Thank you for checking your system. Does your system stil have this blank page issue? The fix for Bug 1318858 is to prevent dgapi.dll and dgapi64.dll from being loaded into firefox.exe. If there no such DLLs, the issue will not happen.
I do not have the dlls. But the issue is present. It crops up either as a permissions errors (0xC0000022) or as blank pages when trying to open/visit any sites.

If you're still having the issue and stil have a build environment mentioned in this thread, can you try a change like this?

-    DllBlocklistEntry("dgapi.dll", (7, 5, 0, 0xffff)),
-    DllBlocklistEntry("dgapi64.dll", (7, 5, 0, 0xffff)),
+    DllBlocklistEntry("dgapi.dll", (7, 4, 1, 0xffff)),
+    DllBlocklistEntry("dgapi64.dll", (7, 4, 1, 0xffff)),

With this change, I am able to work with Firefox. I'll pull in the latest changes, and check. currently I am on this changeset:

changeset:   506207:5ba6228ac0ee
tag:         tip
user:        Dorel Luca <dluca@mozilla.com>
date:        Tue Dec 10 13:47:12 2019 +0200

I might be a bit late responding/reporting the results here. I'll try for the earliest.

Flags: needinfo?(tpb261)

I just verified the working on this changeset: 508266:6d2e33d632e7 (and posting from the built Firefox :) ).

Do you mean the blank page problem was solved on the build of 6d2e33d632e7 without changing any code? If so, that's a great news though I have no idea which changeset solved the problem..

Uh.. no. Sorry for the confusion. I meant it works after the change (7.5.0->7.4.1).

I think I figured out how this happens and could reproduce it. I'm attaching a screenshot of my repro.

First, the dialog [firefox.exe - Application Error] saying The application was unable to start correctly (0xc0000022). Click OK to close the application. was displayed because our blocklist blocked a module in the process's early stage. I can see this popup with both the latest Beta (72.0b10) and Nightly (73.0a1). This is one-time issue because when this happens, the launcher process is automatically disabled.

Next time Firefox is launched, Beta works normally, while Nightly hits a problem that is described in this bug, displaying a blank page. This can happen when no tab process is running.

In Nightly, we enabled our new blocklist in a tab process as Bug 1522830. When the launcher process is disabled after the popup of 0xc0000022, that 0xc0000022 error does not happen because we use the old version of blocklist that is hooked not so early, but we still enable the new version of blocklist in a tab process. As a result, the browser process is launched correctly, but the tab process is not. In this case, somehow there is no 0xc0000022 popup from the tab process.

We should rethink how we enable a blocklist in a child process when the launcher is disabled.

Attached image repro-73.0a1.png

repro

Assignee: nobody → tkikuchi

I prototyped a new way to block dgapi not to cause 0xc0000022 or this blank page issue. Could you please install this and see it fixes both 0xc0000022 and dgapi's crash?

Please note that this is an experimental fix. This may not resolve the issue, or the approach may not be approved even if this works good, but we'd like to know a verification result to confirm we understand the issue correctly.

x64 installer (submitted job):
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/SuQkDlzVRhe0jPIHFIxulQ/runs/0/artifacts/public/build/install/sea/target.installer.exe

Flags: needinfo?(tpb261)

Sorry, I found this prototype was imperfect. I'll update when a next version is ready.

Flags: needinfo?(tpb261)
Component: Untriaged → Other
Product: Firefox → External Software Affecting Firefox
Version: 73 Branch → unspecified
Priority: -- → P2

The issue still remains, but I think the fix for bug 1614885 stopped this no-content-process-situation. Now, dgapi's bug could be emerged as firefox's crash, which is tracked by bug 1603974.

See Also: → 1614885, 1603974

I'm resolving this bug as a dup of bug 1614885 because it mitigated this symptom (blank pages situation). If the same symptom remains on 73.0.1, please let us know.

You may still see the 0xc0000022 error popup. I'd appreciate it if you could test the latest prototype and verify no more 0xc0000022 error.

Status: NEW → RESOLVED
Closed: 10 hours ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1614885
You need to log in before you can comment on or make changes to this bug.