为提升您的使用体验,本站正在维护,部分功能暂时无法使用。如果本站文章无法解决您的问题,您想要向社区提问的话,请到 Twitter 上的 @FirefoxSupport 或 Reddit 上的 /r/firefox 提问,我们的支持社区将会很快回复您的疑问。

搜索 | 用户支持

防范以用户支持为名的诈骗。我们绝对不会要求您拨打电话或发送短信,及提供任何个人信息。请使用“举报滥用”选项报告涉及违规的行为。

详细了解

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