2023251 - [ESET eOppBrowser.dll 1.0.165.0-1.0.169.0] Firefox crashes and close entire app when I detach a window, I've noticed that it occurs when trying to take a meeting on Google Meeting, but now it occurs on any kind of web page and window.

Status: NEW

(External Software Affecting Firefox :: Other, defect)

Description

[Jared Gutierrez]

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

Steps to reproduce:

I use FireFox like normally, I've configured to open previous windows and tabs, I use web apps like spreadsheets, Telegram web, Calendar, some network tools like Wifi controllers based on web and so on.
But I noticed when I take a meeting on Google Meet and detach the window to another screen (I have 2 monitors) Firefox crashes, and then I noticed that it occurs with another web apps or websites.

Actual results:

The entire Mozilla Firefox web browser crashes.

Expected results:

Allow me to detach the window to another screen.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

Can you check about:crashes, and give some of the links/id's for the crashes?

Comment 3

[Jared Gutierrez]

Hi, :)

2406fdae-4544-46ed-ae9e-a2d210014bf1 3/18/2026, 4:14 PM
333954d8-108f-412d-86c6-19e8f8798434 3/13/2026, 12:31 PM
7a6ddca1-9674-4f8a-9334-1a57007a315e 3/13/2026, 12:03 PM
53e82a46-de15-4a95-8c38-2036045fa618 3/11/2026, 12:17 PM
f9a267b8-ecba-4dd9-972d-df4ce4dc80bd 3/4/2026, 11:02 AM
4036f64d-b233-414c-a99e-857795045068 3/3/2026, 1:24 PM
40e201fa-7992-4272-bb1c-062a9260d991 3/3/2026, 11:22 AM
036ddd15-efcf-40ea-abf7-7127107d2222 3/2/2026, 6:32 PM
954a8d58-a3bf-4919-870a-384d0e9914e3 3/2/2026, 1:16 PM

Comment 4

[Kershaw Chang [:kershaw]]

I can’t find the crash reports with those IDs.

Reporter, are you able to view the crash reports by clicking the “View” button in about:crashes? If so, could you share the actual links?

Comment 5

[Jared Gutierrez]

Hi, Kershaw,

I can only see a button "submit", but when I click on them it fails, no "view" button is available.

Comment 6

[Kershaw Chang [:kershaw]]

Thanks. I don’t think this is a networking bug, since the crash happens when moving the window.
I’ll change the component so the front-end team can take a look.

Comment 7

[Jared Gutierrez]

Hi!,

A moment ago I experienced in 2 times the web entire browser crash while sharing screen using Google Meet.

Comment 8

[Niklas Baumgardner [:niklas]]

moving to Core :: WebRTC because this doesn't seem to be a tabbrowser bug. It could possibly be related to screen sharing on google meet?

Comment 9

[Jim Mathies [:jimm]]

Hi Jared, thanks for your patience and for providing the crash IDs.

Unfortunately, we weren't able to find the crash reports in our crash reporting system. It sounds like the submissions may be failing on your end — there's a known issue where submissions can fail due to network restrictions or firewall settings.

To help us investigate, could you try the following to get us a crash report?

1. Open a new tab and go to about:crashes
2. For any crash reports listed, try clicking Submit again
3. If submission succeeds, you'll see a "bp-..." style Report ID — please share that here along with a direct link, e.g. https://crash-stats.mozilla.org/report/index/bp-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

If submission continues to fail, you may be behind a firewall or proxy that blocks the submission. In that case, could you share a bit more detail about your environment?

To help us narrow down the cause, could you clarify:

• When the crash happens, are you dragging a tab out to create a new window, or moving an existing window by its title bar to the other monitor?
• Is Google Meet screen sharing (sharing your screen or a window) active at the time, or just a video call?

Additionally, to get a look at your display set up, could you please post your about:support text?

Thanks!

Comment 10

[Jared Gutierrez]

Hi Jim,

I've tried to submit the last crash report but it failed, and when I try to submit all of them they fail too.

About the environment, I'm connected and behind a SonicWall Firewall in my Office, actually I'm the administrator, so, can You share with me the IP addresses of the crash report servers? In order to track the traffic, try to allow them and finally share with You.

About your questions:

• When the crash happens, are you dragging a tab out to create a new window, or moving an existing window by its title bar to the other monitor? First, I opened a new Google Meet window, and then I move an existing window to the other monitor, that's what I did a few hours ago

• Is Google Meet screen sharing (sharing your screen or a window) active at the time, or just a video call? I think both, but, last time I was only sharing screen, I mean, I was connected to the meeting using my phone, and at the same time using my Windows laptop to join to the meeting but using the option "only share screen", and I shared only the second screen, then, when I tried to move an existing window, it crashed

Comment 11

[Jared Gutierrez]

Attachment: Troubleshooting Information

Comment 12

[Jim Mathies [:jimm]]

fyi to Andreas, an interesting dual monitor crash somehow associated with sharing. Unfortunately we can't get the crash reports.

Comment 13

[Andreas Pehrson [:pehrsons]]

I can't reproduce on linux or macOS. I tried being in Google Meet with both plain camera and camera + screen shared. I can drag a tab out of the window into a new window. I can drag a tab into an existing window. Both cases tested to other screen and to same screen.

Might be Windows specific. Jim, do you have a windows machine to attempt a repro on?

Comment 14

[Philipp Hancke [:fippo]]

Note that Chromium is seeing similar crashes, MacOS with multiple monitors and no crash ids:
https://issues.chromium.org/issues/495700483
https://issues.chromium.org/issues/496254750

Comment 15

[Jim Mathies [:jimm]]

Looking over about:support, the lack of crash reports is likely caused by ESET Security + Firewall.

Comment 16

[Jim Mathies [:jimm]]

Without the crash reports we're a bit stuck. Claude thinks this might have something to do with a desktop mirroring api, but that's just a guess.

• Severity: S3 | Priority: P3 (unchanged — still no crash signature, single reporter, no Windows reproduction)
• Plausible root cause: DXGI Desktop Duplication API losing the capture source when the window moves across monitors during an active screen share (analogous to DXGI_ERROR_ACCESS_LOST). Libwebrtc's Windows DXGI path at third_party/libwebrtc/modules/desktop_capture/win/ is the natural starting point once a signature is available.

Comment 17

[Jim Mathies [:jimm]]

Jared, any chance you could work with your IT team to get those crash reports through your firewall?

Comment 18

[Jared Gutierrez]

Hey all,

I understand that the reason of crash reports cannot be send is because a Firewall rule is filtering or blocking the traffic.
So, I tried from my home network (no Firewall filtering my connections), and same issue, all crash reports failed to submit.

Is there another way to share with You those crash reports?

Regards.

Comment 19

[Jared Gutierrez]

In addition, I've tried to turn off Antivirus Firewall and pause the entire protection, but same issue, I can't submit the crash reports.

Comment 20

[Jim Mathies [:jimm]]

Jared, I want to make sure we understand how to reproduce the issue. I used a little summarizer tool to summarize everything you've told us. Can you confirm I have the situation right? Thanks.

Device(s) in Use

The reporter is using a single machine — a Windows laptop — with two external monitors attached:

• OS: Windows 10 (x64), Build 26200
• GPU: Intel Iris Xe Graphics — this is a laptop integrated GPU (confirms laptop, not desktop)
• Displays: Two monitors, both 1920×1080 @ 60 Hz at 1.0x DPI scale
• Firefox version: 148 at time of first report, 149 by the time they submitted about:support
• Security software: ESET Security + Firewall installed on the machine
• Network: Behind a SonicWall Firewall at their office (reporter is the IT administrator)

In comment #10 they also mention using their phone to join the Google Meet audio/video call while using the Windows laptop separately for screen sharing only — so phone is a peripheral, not the crash device.

---

Steps to Reproduce (Best Reconstruction)

The clearest account comes from comment #10, where the reporter directly answered the questions asked:

1. Open Google Meet in Firefox on the Windows laptop
2. Join the meeting using "only share screen" mode — no camera or microphone from the laptop (audio/video handled by phone)
3. In Google Meet, select only the second screen to share
4. While screen sharing is active, move an existing Firefox window (by its title bar — not dragging a tab out) to the other monitor
5. Firefox crashes entirely

Supporting detail from comment #7: The reporter confirmed two additional crashes that happened "while sharing screen using Google Meet" — reinforcing that active screen sharing is the consistent trigger, not just window movement alone.

Comment 21

[Lukáš Kaňka [:lukaskabc]]

Hello, I am facing the same (or similar issue) and I am as well not able to submit a crash report, because it is not even being created (.dmp files have 0 bytes).
I am getting the crash only on google meet and only with microphone enabled, no screen share involved.
I can replicate the crash by opening a new tab in the maximized window with the google meeting and dragging the new blank tab to another monitor.
Before I found this bug report I also created a support thread with troubleshooting information from a clear new profile attached.
https://support.mozilla.org/en-US/questions/1576150
Let me know if I should create own standalone bug report and if can trace the browser in other means that would preserve the crash report.

Comment 22

[Andreas Pehrson [:pehrsons]]

Cubeb related, perhaps. Kinetik, ringing any bells?

Comment 23

[Matthew Gregan [:kinetik]]

@Lukas, can you please attach your about:support page to the bug?

@Jared, do the .dmp files on your machine (in %APPDATA%\Mozilla\Firefox\Crash Reports\pending) show non-zero file sizes? If you have valid .dmp files, you can send them to us directly for analysis.

There are some prefs you could both try flipping in about:config that may help narrow down the cause of the crash. Try these in order - for each of the steps, set the pref to the specified value in about:config, then restart Firefox and try to reproduce the crash.

1. Set gfx.webrender.dcomp-video-hw-overlay-win and gfx.webrender.dcomp-video-sw-overlay-win to false
2. Set gfx.webrender.compositor to false
3. Set layers.gpu-process.enabled to false
4. Set gfx.webrender.software to true

If none of these make a difference to the crash, reset them back to their default in about:config.

If either of you feel comfortable with trying to capture the crash in Microsoft's WinDbg tool, there are instructions here: https://firefox-source-docs.mozilla.org/contributing/debugging/stacktrace_windbg.html

Comment 24

[Lukáš Kaňka [:lukaskabc]]

Attachment: lukaskabc_firefox_about_support.json

Comment 25

[Lukáš Kaňka [:lukaskabc]]

Attachment: I was able to replic

Comment 26

[Lukáš Kaňka [:lukaskabc]]

Attachment: I was able to replic

Comment 27

[Lukáš Kaňka [:lukaskabc]]

I apologize for the two attached files above, that was a mistake, but you can check WinDbg logs in there.

I was able to replicate the issue with all the mentioned config options.
For each option, I changed the value, restarted Firefox, and replicated the issue, then proceeded to the next option (not reverting the previous one).
At the end, I was able to replicate the crash with all the options set to the mentioned values, then reverted them to the default values.

The crash reproduction steps were slightly different from yesterday:

1. open a single window with a single tab in firefox
2. join google meeting
3. create a new tab
4. drag and drop the new tab to another monitor (detaching it and creating a new window) and keep that window open
5. close the meeting tab in the original window
6. browser crash

I installed WinDbg with winget
(winget install Microsoft.WinDbg --version 1.2308.2002.0)
and tried running firefox from WinDbg (WinDbg running as administrator) by Launch executable advanced, selected the firefox executable and enabled debug child processes.
The log listed

Unable to read dynamic function table list head
ntdll!LdrpDoDebuggerBreak+0x35:
00007fff`874e1589 ??              ???

and there was also eOppBrowser.dll file listed as a ModLoad entry.

I went to the ESET app and disabled all "Security tools" -
mainly the "Safe Banking & Browsing" and "Browser Privacy & Security" - I disabled them permanently (an option in the ESET app), not for a limited time.
I left other protection modules and firewall enabled, only disabled the security tools.
Then I restarted the whole computer

After the computer restarted, I was not able to reproduce the crash.
The WinDbg log now instead listed

(46b4.46b0): Break instruction exception - code 80000003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x35:
00007ffb`36d21589 cc              int     3

However, I did not proceed with debugging since I was not able to reproduce the crash with the mentioned ESET options disabled.
I also noticed one successfully created crash report which I submitted under ID bp-61813baf-0277-43fc-87e4-921ac0260414. Unfortunately, I don't know under which configuration the report was created.
https://crash-stats.mozilla.org/report/index/61813baf-0277-43fc-87e4-921ac0260414

Comment 28

[Lukáš Kaňka [:lukaskabc]]

I also verified that enabling ESET's "Safe Banking & Browsing" makes the crash reproducible again.

Comment 29

[Andreas Pehrson [:pehrsons]]

Fantastic work, thank you Lukas. Moving to the appropriate component.
Your crash report is valuable, and it does show eOppBrowser.dll version 1.0.165.0 as loaded, too.

Jared, do you also have the same ESET software installed? Did you reboot after disabling the protections?

Comment 31

[Jared Gutierrez]

Hi, Andreas,

Yes, at this moment I have some ESSET configurations disabled, but I haven't tried having another meeting.
Actually I have ESET Endpoint Security, app version 13.0.2044.0.

Comment 32

[Jens Stutte [:jstutte]]

Apparently most if not all crashes here have a version of ESET injected, between 1.0.165.0 and 1.0.169.0. As of comment 29 there is a workaround, so while it is pretty bad for affected users I think it does not really merit an S2.

It seems like we may see a double-registration by ESET of SetWindowLongPtrW(GWLP_WNDPROC, …) which leads to an endless loop: mPrevWndProc is captured in AssociateWithNativeWindow (nsWindow.cpp:1549–1557) by SetWindowLongPtrW(GWLP_WNDPROC, …). The cycle forms when both subclassers race / re-hook:

1. Window created (proc = O).
2. ESET subclasses → ESET.saved=O, current=ESET.
3. Firefox subclasses → Firefox.mPrevWndProc=ESET, current=nsWindow::WindowProc.
4. ESET re-applies on top → ESET.saved=nsWindow::WindowProc, current=ESET.

We could add a re-entrancy guard in our WindowProcInternal as in-depth defense, but the root cause is most likely on their side.