User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 I've installed and started using Mozilla 1.4 (final release) for a few days. Then, after suffering a fatal machine crash and rebooting/cleaning up, Mozilla 1.4 refuses to start. I have Mozilla 1.3 on this machine as well (installed to a different directory), and it continues to work. Both were using the same profile. Clicking on the icon or executable causes nothing to happen. No error is thrown, no temp files are created, no process is ever started, except maybe for a millisecond, in Task Manager. It isn't just the browser, but ALL components: Mail, Profile Manager, etc. The Mozilla executable itself is failing immediately -- even when just trying to get help at the command line. I ran a File Monitor program, and it seems to look for xpcom.dll, but that's as far as it goes. Again, no error message is thrown. I have tried uninstalling and reinstalling -- no luck. I have tried uninstalling and reinstalling to a new directory -- again, no luck. I think this rules out any plugins or .xpi's, since none were present after reinstalling from scratch. I've tried deleting my profile, and it still shows no sign of starting up. On one hand, there is the problem the browser simply can't be made to work again after a fatal crash like this, so there is some kind of data corruption in the profile or in the registry that is causing Mozilla 1.4 to die before it can even get off the ground. On the other hand, there's the fact that no error message is being thrown, which itself is a real bug. Reproducible: Always Steps to Reproduce: Unable to reproduce environment consistently. Actual Results: see above Expected Results: see above I also installed Talkback when reinstalling several times -- it doesn't trigger anything either (which makes sense, as virtually nothing is being loaded). To repeat one key fact here: Mozilla 1.3, pointing to the same profile I was using before, DOES WORK. It's only Mozilla 1.4 that doesn't. Also, it bears mentioning that I did see this problem once before with Mozilla 1.4 Release Candidate 2. No matter how many times I uninstalled and reinstalled, I could never get it to work. However, when RC3 came out and I installed that, everything was fine. So I'm wondering if the problem is somehow tied to the specific version, and reinstalling something only slightly different or new would help. I thought the registry was well cleaned up after the install, but I haven't been able to narrow down what registry keys, if any, the executable is accessing upon startup, and that might be causing it to barf.
Try removing Program Files/Common Files/mozilla.org.
That fixed it -- beautifully simple. Does the deinstall procedure currently remove these directories (either automatically or optionally)? If not, it looks as though it should to avoid this problem. Or can the installer be run in some sort of "forced" mode that automatically overwrites anything in this directory? Would that have prevented this problem?
I don't think uninstall, uninstalls Common Files/mozilla.org. At least on my system it remains after installing a specific version (1.3?, 1.4x?, not sure which one I uninstalled last before I looked).
I think a somewhat recent change to the installer will now delete that directory for you, but previously it did not. If you see it saying something about deleting "Orphan GRE's", that's what it's doing. So Keith, would you consider this problem solved? If so, I'll close the bug. Thank you.
I suppose so, but these are common files, right? If the uninstaller removes them, isn't there a risk that it may be breaking other mozilla.org software that is installed? What if there are other Mozilla programs installed and the uninstaller detects this, so does not remove the directories. Won't this problem still exist then? Or is it smart enough to remove only the pieces that are needed by Mozilla? The most ideal solution is to detect and error-trap the situation that's causing the startup to fail. Another ideal solution would be for the installer to overwrite any potentially corrupt common files at install time, so the problem can be fixed with a new install. Certainly, removing the common files in ALL cases would solve this problem, but I'm concerned that this approach by itself may introduce others.
I agree that the best solution is to detect that the files are old, corrupt, or whatever is causing the problem and trap the error. However, as far as I know, there is not yet any Mozilla.org software other than the browser suite that actually uses the files installed to Common Files\Mozilla.org so that deleting it is not dangerous. Eventually the plan is to move in that direction to save memory and disk space, but currently each program (Firebird, Thunderbird, stand alone versions of Chatzilla and Calendar, etc) comes with its own copy of the Gecko Runtime Engine (GRE) files rather than sharing the ones the suite installs in that folder. On my home machine I have Firebird and Thunderbird but not the suite, and there is no Common Files\Mozilla.org folder at all. So for the moment at least, deleting that folder is only affecting the main Mozilla suite and not anything else. I think the belief among developers is that whatever causes this crash relates to multiple, old versions of the GRE existing at the same time in the common files folder, and deleting them all (and from now on using the updated installer) will ensure that this situation can't happen again.
I'm going to mark this worksforme. There is definitely still an issue of Mozilla not gracefully handling obselete extensions, but that should be filed in a new bug (if there is not one already).
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.