Closed Bug 1766022 Opened 7 months ago Closed 7 months ago

Crash in [@ gdi32.dll | CEnum::CEnum]

Categories

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

All
Windows

Tracking

(firefox-esr91 unaffected, firefox99 unaffected, firefox100+ fixed, firefox101 fixed)

RESOLVED FIXED
Tracking Status
firefox-esr91 --- unaffected
firefox99 --- unaffected
firefox100 + fixed
firefox101 --- fixed

People

(Reporter: bobowen, Assigned: bobowen)

References

(Regression)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

Crash with win32k lockdown.

Crash report: https://crash-stats.mozilla.org/report/index/21f66228-bcb8-4199-b918-893b90220420

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0 gdi32.dll gdi32.dll@0x0000000000004377 
1 d3d9.dll CEnum::CEnum 
2 d3d9.dll long Direct3DCreate9Impl 
3 d3d9.dll Direct3DCreate9 
4 videocapturerhk64.dll videocapturerhk64.dll@0x0000000000037219 
5 videocapturerhk64.dll videocapturerhk64.dll@0x0000000000012e42 
6 videocapturerhk64.dll videocapturerhk64.dll@0x0000000000089db3 
7 videocapturerhk64.dll videocapturerhk64.dll@0x0000000000049d56 
8 videocapturerhk64.dll videocapturerhk64.dll@0x000000000004d000 
9 videocapturerhk64.dll videocapturerhk64.dll@0x00000000000b1d27 

Set release status flags based on info from the regressing bug 1759168

These all seem to be down to videocapturerhk64.dll.

I can reproduce on a VM.
The only way I can reproduce is by launching firefox with the video capture software, so if that's the only way there is a good chance people will realise it is to do with the software and not Firefox.
Blocking the DLL in child processes seems to work and still allow capture, although it is a little difficult to tell because this form of capture doesn't work well in my VM anyway.

Looks like it causes the same crash with our old favourite DdQueryDisplaySettingsUniqueness as well.

(Both of these might get caused by other things trying to create devices, but all the ones I've checked are for this DLL).

Crash Signature: [@ gdi32.dll | CEnum::CEnum] → [@ gdi32.dll | CEnum::CEnum] [@ DdQueryDisplaySettingsUniqueness ]

This has been found to cause crashes when win32k lockdown is enabled.

Pushed by bobowencode@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/09a4ccbe6d74
Add videocapturer* to the child process DLL blocklist. r=gcp

Comment on attachment 9273464 [details]
Bug 1766022: Add videocapturer* to the child process DLL blocklist. r=gcp!

Beta/Release Uplift Approval Request

  • User impact if declined: Users using particular video capture software will experience tab crashes.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Just new blocklist entries, so should only affect software/DLLs in question.
  • String changes made/needed: None
  • Is Android affected?: No
Attachment #9273464 - Flags: approval-mozilla-beta?
Status: ASSIGNED → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → 101 Branch

All of these crashes had an offset of 0x4377 or 0x2da7 on gdi32.dll
Querying latest telemetry crash pings for nightly, the last crash was build ID 0220423065829, the one before this landed.

Comment on attachment 9273464 [details]
Bug 1766022: Add videocapturer* to the child process DLL blocklist. r=gcp!

Approved for 100.0rc1

Attachment #9273464 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Has Regression Range: --- → yes
Component: Security: Process Sandboxing → Other
Product: Core → External Software Affecting Firefox
Target Milestone: 101 Branch → ---
You need to log in before you can comment on or make changes to this bug.