We're calling on all EU-based Mozillians with iOS or iPadOS devices to help us monitor Apple’s new browser choice screens. Join the effort to hold Big Tech to account!

Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

ఇంకా తెలుసుకోండి

Often crash in plugin-container.exe; FF ver. 42.0

  • 1 ప్రత్యుత్తరం
  • 1 ఈ సమస్య కలిగినది
  • 5 వీక్షణలు
  • చివరి సమాధానమిచ్చినది FredMcD

more options

Extremely often crash on INT3 in plugin-container.exe at offset 0x00B8ED50: 00B8ED41 push eax 00B8ED42 push 0B9705Ch 00B8ED47 call dword ptr ds:[0B961C0h] 00B8ED4D add esp,10h 00B8ED50 int 3 ; <== it's a crash point. After this crash LoadLibrary() and LoadLibraryEx() APIs (all variants - Unicode/MBCS and single char) stop normal operation until reboot, xul.dll remains locked by unknown process. As the result, Crash reporter can neither send the crash report with data collected nor add user's comment to it. Further transmission of crash report is available only via about:crashes page after system reboot because a lot of other applications (including FF) can't be started. Graphical attributes of other opened windows belong to other applications and texts in windows' headers look spoiled. Contents of all other CHtmlView-derived windows belong to other applications (even started before this crash) becomes empty. After reboot and until next FF crash all normally works. This crash happens in -safe-mode too, FF clearance doesn't helpful. Step-by-step backout of FF ver. from 42.0 to 33.1.1 has reduced fault frequency but not removed it at all. Fault may occure on attempt of open some Web page and may not occure on the same page next time after reboot, so, it looks like cumulative and/or garbage-in-constructor problem...

Extremely often crash on INT3 in plugin-container.exe at offset 0x00B8ED50: 00B8ED41 push eax 00B8ED42 push 0B9705Ch 00B8ED47 call dword ptr ds:[0B961C0h] 00B8ED4D add esp,10h 00B8ED50 int 3 ; <== it's a crash point. After this crash LoadLibrary() and LoadLibraryEx() APIs (all variants - Unicode/MBCS and single char) stop normal operation until reboot, xul.dll remains locked by unknown process. As the result, Crash reporter can neither send the crash report with data collected nor add user's comment to it. Further transmission of crash report is available only via about:crashes page after system reboot because a lot of other applications (including FF) can't be started. Graphical attributes of other opened windows belong to other applications and texts in windows' headers look spoiled. Contents of all other CHtmlView-derived windows belong to other applications (even started before this crash) becomes empty. After reboot and until next FF crash all normally works. This crash happens in -safe-mode too, FF clearance doesn't helpful. Step-by-step backout of FF ver. from 42.0 to 33.1.1 has reduced fault frequency but not removed it at all. Fault may occure on attempt of open some Web page and may not occure on the same page next time after reboot, so, it looks like cumulative and/or garbage-in-constructor problem...

ప్రత్యుత్తరాలన్నీ (1)

more options

Start your Computer in safe mode with networking. Then start Firefox. Try Safe web sites. Is the problem still there?

Starting The Computer In Safe Mode;
Free Online Encyclopedia