Closed Bug 1829992 Opened 2 years ago Closed 2 years ago

Every alternate Nightly start results in a 0xc0000022 error

Categories

(Core :: Widget: Win32, defect)

Product:
Core
Component:
Widget: Win32
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: mayankleoboy1, Unassigned)

References

Details

Attachments

(5 files)

about:support
37.76 KB, text/plain
Details
Screenshot 2023-04-26 100841.png
23.40 KB, image/png
Details
about:support from a MMozregression build saved locally
32.64 KB, text/plain
Details
about:third-party from a mozregression build downloaded locally
6.17 KB, text/plain
Details
about:thirdparty output where Firefox is launched with --disableDynamicBlocklist parameter.
4.49 KB, text/plain
Details

This started happening with the latest Nightly
On every alternate firefox start, I get a 0xc0000022 error.
This does not repro with builds using mozregression, so i cant find a regression range.

Attached file about:support —
Component: Shell Integration → DOM: Content Processes
Product: Firefox → Core

One thing I noticed is that the launcher process is disabled due to failure. That has never happened before

Attached file Logfile.PML —

Logfile from Process Monitor

The only place I see 0xC0000022 mentioned in our source seems to have to do with DLL initialization. This component might be wrong, but it has to do with Windows specific things, IIUC, and someone there might have a better idea where to move this. FWIW, for example bug 1503538 was worked on just in Core: General.

BTW: Are those PML log files containing private information? If unsure I'd probably avoid to put them on a public bug. Thanks for your support!

Component: DOM: Content Processes → Widget: Win32

Hi Jens,
Please can you mark hte attachment as private? I dont know how to do that.

Thanks!

(In reply to Mayank Bansal from comment #7)

Please can you mark the attachment as private? I dont know how to do that.

Done - it still exists but is only visible to a small group of trusted engineers.
Let me know if you'd prefer for the attachment's contents to be deleted rather than just hidden.

Hello, thanks for reporting!

(In reply to Mayank Bansal from comment #0)

This started happening with the latest Nightly
On every alternate firefox start, I get a 0xc0000022 error.
This does not repro with builds using mozregression, so i cant find a regression range.

What does alternate mean here? Does the crash only reproduce sometimes? If yes -- after a successful start, can you navigate to about:buildconfig and confirm what commit the Nightly version you are using is built from? Thanks.

Edit: From about:support that shoud be the same Nightly as mine, so built from this commit.

A plausible hypothesis: The first start is with the launcher process, uses the launcher process blocklist code, which blocks a DLL that is loaded through the import table (not dynamically), so we fail to start. The second start is without the launcher process as a fallback consequence of the failure that just happened, uses the mozglue blocklist, doesn't block the DLL, all is fine.

Can you share the contents of about:third-party, Reload with system information, Copy raw data to clipboard?

ALternate means : First time I start Firefox, i get this error message and Firefox does not start. Then I close the error message and start Firefox again. This time, I dont see an error message and Firefox starts normally.

about:third-party is blank!

Output :
{
"modules": [],
"blocked": []
}

This is weird because usually I see 4 DLL's from AMD/ATI GPU Drivers.

Flags: needinfo?(yjuglaret)

I like Yannis's hypothesis in comment 9.

Do you remember if you had blocked any DLLs on the about:third-party page? And can you try launching in Troubleshoot Mode on a time that it would have crashed? That will disable the dynamic blocklist; if that succeeds we can try deleting the blocklist file (here's information about the location of the file) and see if that fixes it.

Flags: needinfo?(mayankleoboy1)
  1. Trying to start in safe mode (by pressing Shift key while starting Firefox) didnt work. Firefox crashed.

BUT

  1. Adding : "--disableDynamicBlocklist" to Firefox.exe "fixed" the issue! \O/

Edit: I didnt block any third-party dll in the last 2-3 days.

Flags: needinfo?(mayankleoboy1)
Flags: needinfo?(gstoll)

In case anyone is interested :
I have set Firefox to launch at Windows startup by (IIRC) putting the Firefox shortcut in the Windows Startup folder. When trying to diagnose this issue, I found that once i restart my machine every instance of trying to launch Firefox resulted in a crash. To fix this, I had to install an older Nightly version which then resulted in Nightly crashing on every alternate start. Thus I could atleast use the Browser.

Glad that seems to fix the issue! To finish clearing things up, I'd recommend:

  • Finding the blocklist files per the documentation and deleting them on disk
  • After relaunching Firefox, make sure the launcher process is enabled in about:support
  • Relaunch Firefox one more time and make sure that the launcher process is now enabled.

If that all works, I'll close this bug.

For what it's worth, the output you pasted in comment 15 indicates that msvcp140.dll, vcruntime140.dll, and vcruntime140_1.dll were on the dynamic blocklist. I'm not surprised that blocking those causes Firefox to crash; we have bug 1817026 to try to not even show those on the about:third-party page.

I'm also surprised that launching in Troubleshoot mode didn't fix the problem, because that's also supposed to disable the dynamic blocklist like the command-line flag does...

Flags: needinfo?(gstoll)
See Also: → 1817026

Oh, and this also makes sense that a mozregression build wouldn't have this problem, since the dynamic blocklist is specific to the install path of FIrefox.

Just a small suggestion: It might make sense to have

  1. https://firefox-source-docs.mozilla.org/widget/windows/blocklist.html#disabling-the-dynamic-blocklist somewhere in SUMO or somewhere more accessible to non-tech users
  2. Add reference of "0xC0000022" to the above link
  3. Make the contents of this link be more searchable from Google (i.e. allow the page to be indexed by google)

But aside from that, really appreciate your prompt support in troubleshooting and helping to fix this!

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(yjuglaret)
Resolution: --- → FIXED

Any idea how these entries made their way into the blocklist though?

(In reply to Yannis Juglaret [:yannis] from comment #20)

Any idea how these entries made their way into the blocklist though?

i have absolutely no idea

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: