Enabling win32k lockdown by default on Nightly caused a large number of crashes in ProcessRuntime::InitInsideApartment in a relatively small number of installs.

This is due to CoInitializeSecurity failing with 0x80070057.

Looks like this like a similar issue to bug 1535704, where COM is using a user32!NtGetUserProcessWindowStation to get the window station and this fails with win32k lockdown.
Bug 1535704 hooked ApiSetQueryApiSetPresence to stop the presence of ext-ms-win-ntuser-windowstation-l1-1-0.dll being detected, so that fallback code is used that does work with win32k lockdown.

However is appears earlier versions of windows (possibly 10.0.15063 and before from current crashes), don't query for the API presence, so the work around doesn't work.

As mentioned in bug 1535704, there is some detection code for user32.dll being loaded.
This is still getting loaded on win8/8.1/10 (at least before build 15063).
This appears to be because it is a dependency for winmm.dll on these version, but not later ones.

By adding winmm.dll to the delay loads for xul.dll and nss3.dll, I can prevent user32 loading before CoInitializeSecurity.
However we can't prevent it from loading entirely because it is needed for timeGetTime call triggered by PR_IntervalNow. (At least not without further chicanery, because timeGetTime is really in kernel32.dll).

This on it's own still doesn't seem to be enough to prevent the call to user32!NtGetUserProcessWindowStation.
There must be further checks, but these seem to be sorted by moving to an alternate winstation as well as desktop.
(I think the code is checking for registered interfaces.)

With this change as well I can run firefox with win32k lockdown enabled on win8/8.1/10 build 15063.

This is to prevent user32.dll from loading before COM initialization on earlier
version of windows.

Depends on D136935

https://treeherder.mozilla.org/jobs?repo=try&revision=578d1763a60ff34d64efdd309be13fbdf4d4ac52

Backed out for causing marionette test failures

Backout link: https://hg.mozilla.org/integration/autoland/rev/3f25345c1002fd20b96788a696827f6dcf1d1886
Log link: https://treeherder.mozilla.org/logviewer?job_id=366342030&repo=autoland&lineNumber=39508

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=0b12f1bb498a5f024341697b2163f725815b12d5&selectedTaskRun=buVmRzW4S1-vP-sy0KnWRQ.0

[Remote] failure log: https://treeherder.mozilla.org/logviewer?job_id=366351135&repo=autoland

https://hg.mozilla.org/mozilla-central/rev/b35ceb4aaccc

Firefox 98.0b1 tabs are crashing on Windows 8.1 Build 9600 when flipping the pref security.sandbox.content.win32k-disable to 'true'.
Crash report: https://crash-stats.mozilla.org/report/index/fe90b58d-8693-4be2-b1dd-fe49d0220208

Hi Gabi, in the modules list I see "eplgFirefox.dll" which is from ESET antivirus. This module would also show up in about:third-party (can you check?).

Is it possible to try this on a machine (same Windows version) without this software installed and see if this makes a difference?

(In reply to Gian-Carlo Pascutto [:gcp] from comment #12)

Hi Gabi, in the modules list I see "eplgFirefox.dll" which is from ESET antivirus. This module would also show up in about:third-party (can you check?).

Is it possible to try this on a machine (same Windows version) without this software installed and see if this makes a difference?

I can see the ESET "eplgFirefox.dll" listed in about:third-party:
eplgFirefox.dll
File version
1.0.96.0
Vendor info
ESET, spol. s r.o.
Occurrences
7
Avg. Blocking time (ms)
0.6327486509762108.

Here's a crash report from another Win 8.1 build 9600 with Cisco Av installed: https://crash-stats.mozilla.org/report/index/40f1a518-7821-462d-b1be-f43210220209.
I can uninstall ESET from my test machine and return with results if that helps.

I can uninstall ESET from my test machine and return with results if that helps.

Yes, it would help confirm or deny that the AV hooking is what's causing the failure here.

(In reply to Gian-Carlo Pascutto [:gcp] from comment #14)

I can uninstall ESET from my test machine and return with results if that helps.

Yes, it would help confirm or deny that the AV hooking is what's causing the failure here.

Crash still happens with ESET uninstalled: https://crash-stats.mozilla.org/report/index/ef6caf69-485c-453d-89d1-8a2e10220210 and no third-party modules detected in Firefox.

Ran mozregression, On Windows 10, Aurora/DevEdition 98.0b2 this change seems to cause super-tiny and differently-styled HTML checkboxes somehow. Unintended, i presume?

Ran mozregression, On Windows 10, Aurora/DevEdition 98.0b2 this change seems to cause super-tiny and differently-styled HTML checkboxes somehow. Unintended, i presume?

What's your setting of widget.non-native-theme.enabled in about:config?

I have that pref set to false, since I don't like the new too-bluish non-native theme.

Ran mozregression, On Windows 10, Aurora/DevEdition 98.0b2 this change seems to cause super-tiny and differently-styled HTML checkboxes somehow. Unintended, i presume?

We filed bug 1754940 - this was almost certainly caused by another sandboxing improvement that landed close to this one.

(In reply to Gabi Cheta [:Gabi] Release Desktop QA from comment #15)

(In reply to Gian-Carlo Pascutto [:gcp] from comment #14)

I can uninstall ESET from my test machine and return with results if that helps.

Yes, it would help confirm or deny that the AV hooking is what's causing the failure here.

Crash still happens with ESET uninstalled: https://crash-stats.mozilla.org/report/index/ef6caf69-485c-453d-89d1-8a2e10220210 and no third-party modules detected in Firefox.

Looks like this is down to an accessibility check that only happens on x86 and only on earlier than win10 creator's update, which causes user32 to load:
https://searchfox.org/mozilla-central/rev/fc4d4a8d01b0e50d20c238acbb1739ccab317ebc/ipc/mscom/mozglue/ActCtxResource.cpp#209