From https://bugzilla.mozilla.org/show_bug.cgi?id=680927#c48 (In reply to Ian Gregory from comment #48) > I'm still getting this crash with Fx 10.0b1 - though neither the Mozilla > crash reporter nor the Windows winqual system is catching it - Firefox just > exits silently. I can easily work around the issue but I wonder how many > users are being affected by this bug but are not visible due to the fact > that crash reports have not been sent for this issue since Fx 7.0
How do we know this is the same issue if there aren't any reports being sent anywhere? Has anyone else been able to reproduce this behavior?
(In reply to Ted Mielczarek [:ted, :luser] from comment #1) > How do we know this is the same issue if there aren't any reports being sent > anywhere? Has anyone else been able to reproduce this behavior? I've CC'd Ian for help in answering your question. The intent of this bug was to separate out the new silent startup crash report from the previous bug.
I can tell it's the same issue as shutting down Oracle ESSO allows Firefox to start cleanly. If I start Oracle ESSO and then start Firefox, I see the taskbar icon animate to the 'running' state then back to the 'inactive' state 2-3 seconds later. In Fx 7.0, the crash reporter picked up the issue. In Fx 8.0, the crash reporter no longer picked up the issue, but there was still an entry in the Windows Event Log: Faulting application name: firefox.exe, version: 184.108.40.20688, time stamp: 0x4e8342f6 Faulting module name: mozmolt0.dll, version: 220.127.116.11, time stamp: 0x4b1d8f7f Exception code: 0xc0000005 Fault offset: 0x0000138e Faulting process id: 0x1fd8 Faulting application start time: 0x01cc84c2267e6ad9 Faulting application path: C:\Users\GregorI\AppData\Local\Mozilla Firefox\firefox.exe Faulting module path: C:\Program Files\Passlogix\v-GO SSO\Helper\Moz\mozmolt0.dll Report Id: d8f78760-f0b5-11e0-9500-68b599f6eede I can't recall the behaviour from Fx 9, but Fx 10 behaves as stated at the start of this comment.
If you are interested in launching Firefox under a debugger to get a crash stack, that would be very helpful: https://developer.mozilla.org/En/Using_the_Mozilla_symbol_server has instructions on using the free MSVC express edition so that you can debug our release builds. It's clear from the report that mozmolt0.dll is crashing, which is not a Mozilla DLL, so this is definitely caused by third-party software.
I'll try and get a debug build of Fx running on my laptop at the weekend and see if I can get a stack. Having said that, I've done some further testing, and it appears in the Fx 10 builds Firefox is actually hanging indefinitely rather than crashing - on startup the process stays in the background consuming CPU. If ESSO is started whilst Fx is already running, the Fx window freezes, greys and displays the "Not Responding" window title. So I may not be able to get a crash stack.
You don't need a debug build. With the link in comment 4, you can get a stack from our release builds. If this is a hang, you can still attach a debugger and break into the application to find out where it's hanging.
Created attachment 586112 [details] Windbg output Attached Windbg output - issued break on hung thread
This is pretty clearly that
This is pretty clearly that mozcomp.dll doing something bad and causing a hang. I don't think there's anything more definitive we can say about it without access to its source.
Fair enough. I don't suppose there is a way for firefox to detect a hang in a third party module and react appropriately (perhaps by crashing?) is there? The current behavior gives no indication of the cause of the issue other than "Firefox won't load"
We do have some code for hang monitoring (bug 429592), but it's currently preffed-off because we trip it entirely too much in actual usage right now.
Yeah, I don't think there's realistically anything we can do about this. Resolving the bug.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.