User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 Before you mark this as a dupe, read on, maybe I have observed something useful. I think I am sensing a "code smell" problem in XPCOM, if I might be so bold. When I am updating from 1.3.1 to 1.4rc2, Mozilla gets a crash on first run. Anyhow, subsequent to this first run crash, the quality feedback agent does *not* run! That is very suspect to me, and suggests that there is either an installer issue or a mozilla launcher issue. If I attempt to launch 1.4rc2 again, I get the same crash, an no Talkback this time either! So, for whatever reason, talkback is not automatic on all mozilla runs, and that is a problem. So I reinstall 1.3.1, and I have a working Mozilla again. On 1.3.1's first run, I get XPCOM dll related warnings and messages upon startup. If I immediately exit 1.3.1 and restart it, I get those warnings again! In fact, I can repeat that process and continue to get the warnings until I view a URL for the first time. Subsequent to a page view, exiting, and restarting, these warnings cease! FYI, I have about:blank set as my homepage, so I don't actually get a page view on any site when I start Mozilla. So, there is something critical about that initial page view subsequent to a mozilla install, it does something: refreshes the registry(?) I actually see the sense in how the installer tries to launch mozilla - it's expecting the user's homepage to be the first page view that will trip the registry refresh. But if my observation is true, then a mozilla install is running under an outdated xpcom registry until first successful *page view*. It's no wonder 1.4rc2 crashes, the registry has old 1.3 nonsense in it. This, I think, is the feature that smells to me. Further, I suggest that the installer should have the responsibility of clearing/resetting/refreshing the xpcom registry, and not the browser component. Installing Mozilla into a blank directory would probably work for me, yes. I haven't tried it because I don't want to lose all the email in my inbox. So, after reading all I've written, if you want to make this a dupe then fine, but I think this is a wider issue than a simple crash bug; I think this is a responsibility and design issue. Thanks, Dave Reproducible: Always Steps to Reproduce: 1. Install Mozilla 1.4rc2 2. Install completes and tries to launch browser 3. Mozilla 1.4rc2 crashes, Talkback agent does not launch: The instruction at "0x610f0769" referenced memory at "0x4d7a6f6d". The memory could not be "read". 4. Checked the Task Manager, installer has exited, mozilla is not running. 5. Attempt to run 1.4rc2 again, same crash every time. 6. Reinstall Mozilla 1.3.1 and installer tries to launch browser, I get the following 4 xpcom related message box warnings: Title: Mozilla.exe - Unable To Locate DLL Message: The dynamic link library xpcom-compat.dll could not be found in the specified path <my link> Title: Mozilla.exe - Entry Point Not Found Message: The entry point ??1nsAVLTree@@QAE@XZ could not be located in the dynamic link library xpcom.dll. Title: Mozilla.exe - Unable To Locate DLL Message: The dynamic link library xpcom-compat.dll could not be found in the specified path <my link> Title: Mozilla.exe - Entry Point Not Found Message: The entry point ??1nsAVLTree@@QAE@XZ could not be located in the dynamic link library xpcom.dll. 7. about:blank (my homepage) is successfully displayed. 8. exit mozilla 9. launch mozilla 1.3.1, *get same warning message boxes as step 6* 10. exit mozilla 11. launch mozilla 1.3.1, *get same warning message boxes as step 6* 12. open mozilla mail 13. exit mozilla, exit mail 14. launch mozilla 1.3.1, *get same warning message boxes as step 6* 15. visit http://www.slashdot.org: this is the first page view for 1.3.1, and it successfully displays 16. exit mozilla 17. launch mozilla 1.3.1, warnings are *not* displayed. 18. subsequent launches of 1.3.1 have no warnings at startup Actual Results: I got a working Mozilla 1.3.1. Expected Results: Get a working Mozilla 1.4rc2.
I installed Mozilla 1.4rc2 (from Mozilla 1.3.1) today and had the same problems as you have said. the work around for this is easy and Im sure its in the Release notes some where (allways has been in the past). Work Around: 1. Uninstall Mozilla. 2. Then Delete everything but the plugins folder in "%SYSTEMDRIVE%\Program Files\mozilla.org\Mozilla". As for your Mozilla Profile, Your old one should work fine (mine did) but remember to back it up first "%USERPROFILE%\Application Data\Mozilla".
oops, I forgot step 3 for the work around: reinstall mozilla 1.4rc2.
I am also having this problem. 1.4rc2 crashes, and the uninstaller crashes too. xpcom error. Help! marking new.
reporter: can you please print out the contents of what regedit tells for for the key name (including all child data): HKEY_LOCAL_MACHINE\SOFTWARE\mozilla.org\GRE Also, please provide the file path for each mozilla application installed. Also, how exactly did you install the mozilla clients? Did you install or did you unzip?
I was using the installer, I usually just pick the defaults. I fixed this problem by deleting the mozilla directory in c:\program files\mozilla.org.
Created attachment 126247 [details] My HKEY_LOCAL_MACHINE\SOFTWARE\mozilla.org\GRE branch from regedit I also have a big set of stuff under HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla, HKEY_LOCAL_MACHINE\SOFTWARE\mozilla.org\GRE_PRIVATE_Mozilla, and an entry for just my current version (1.3.1) under HKEY_LOCAL_MACHINE\SOFTWARE\mozilla.org\Mozilla.
what are all of the DLL files in this directory: e:\\Mozilla\\
dougt: please direct your questions to a particular user, we've got a few people in the comments log already. I think you're talking to Dave here.
chris, I thought the noun "reporter" was defined.
Created attachment 126343 [details] My e:\mozilla dll's. This list was generated from my currently running Mozilla 1.3.1 install.
dave: did you install on-top-of an existing installation? It looks like both copies (1.3x and 1.4rc2) were installed into e:\mozilla\. This is a bad thing that the installer should have caught.
I just installed 1.3.1 into a clean dir, and it started right up at the end of the install. I then installed 1.4rc2 over 1.3.1 and it also started right up at the end of the install. No crash of any kind. It sounds to me that you had 3rd party files installed with your 1.3.1 build that is not compatible with 1.4rc2. Comment #1 from Nikolas seem to support this as well. I'm working on a patch to the installer that will offer the user a choice on whether to delete the target folder prior to installation or to just ignore the warning and take your chances on problems like this bug.
Doug: yes, I installed 1.3.1 over 1.4rc1, and 1.4rc2 and vice versa. So, possibly files are locked that are not being deleted? (Damned DLL hell!!) Are there any install log that would reflect that supposition that I can send? Here is the list of mozillas that have been in that folder (according to my registry) in case it's useful: 1.0, 1.1, 1.2, 1.2b, 1.3, 1.3.1, 1.3a, 1.3b, 1.4_2003052908, 1.4b_2003050714, and 1.4f_2003061210 email@example.com: I like your patch idea for deleting the mozilla folder. Is that certain not to destroy any user's email mailboxes and preferences? (I assume so, otherwise you wouldn't be offering that up.) Anyhow, I suggest that it be worded more like, "An earlier version of Mozilla is installed in the target folder, it will be uninstalled before continuing. (Email inboxes, profiles, and preferences will not be affected) Ok, Cancel" This way, they have no choice in the matter and they'll click ok. In reality, all you would really do is del *.* on e:\mozilla, but the user thinks you're doing them a favor and uninstalling it for them! Oooh, I'm so devious! Gold star for me! :) Thanks, Dave Woldrich
dave, i do not think so. I think that the first attachment basically looks pretty damning. The installer should probably warn that installing on-top-of another installation is not going to work correctly.
dougt: Urf, darn ... installing in the same folder is essentially an upgrade - even InstallShield wants to install in the existing folder because that is classically how upgrades proceed ... I don't know all the issues or mechanics of Mozilla that would make clearing the folder before upgrade unsafe. Perhaps losing installed plugins? I'll be quiet, I'm way out of my league. Sorry for the extra chatter. But, I'm rooting for you guys, go Mozilla go! :)
dave, you are asking the right questions. sean su is working on a fix to this problem.
Same crash bug as 1.4rc2 with 1.4 final version released today: crash on first run after install. There were no message boxes during install popping up to warn me that installing into my existing install e:\mozilla was naughty. ;( Reinstalled 1.3.1.
Similar situation: everything from 1.4rc2 through 1.4 fails to install, reverting to 1.3.1 works. However, I don't get a crash: the initial browser launch after installation displays an hourglass for a second or two, then nothing. Tried the same installation permutations as reporter, plus uninstall / regclean / delete install dir / reboot.
Esa, what OS are you trying to install under? The bug that deals with installer upgrade problems is bug 210731. If you're installing into (essentially) a new dir in your tests, and you're still running into problems starting up, it's then it doesn't sound like an upgrade problem. Could be something else altogether. What you're describing with your problem sounds like mozilla can't find the GRE in order to run. Try running the installer and passing ' -greLocal' on the commandline. This will force GRE to be installed into the same dir as mozilla. Still install this into a new/clean dir to make sure there isn't anything else that could polute it.
win2k sp3. Tried upgrade install at first, then uninstall + delete dirs. -greLocal fixed it!
The error here can be the same as have reported on bug 207983 in my comment #9 (http://bugzilla.mozilla.org/show_bug.cgi?id=207983#c9)
Esa, do you have write access to [program files]\common files dir?
Yes, I can create files and folders under Program Files\Common Files\mozilla.org. Hmm, I see old folders there under GRE called 1.4_2003052908 1.4b_2003050714 1.4f_2003062408 I didn't delete those during my installation attempts, just Program Files\mozilla.org
Esa, I wondering if you have copies of the following files anywhere in your %PATH%, [Windir], or [WinSysdir]: gkgfx.dll js3250.dll jsj3250.dll mozctl.dll mozctlx.dll mozz.dll nspr4.dll nss3.dll nssckbi.dll plc4.dll plds4.dll smime3.dll softokn3.dll ssl3.dll xpcom.dll xpcom_compat.dll xpistub.dll Mozilla might be finding the wrong ones (nor the right ones at all) and thus not starting up at all.
None of those DLLs were found in %PATH%, [Windir], or [WinSysdir] although some were found in places like Program Files/Common Files/mozilla.org/GRE/1.4b_2003050714/ Program Files/Common Files/mozilla.org/GRE/1.4f_2003062408/ Program Files/Firebird-0.6/MozillaFirebird/ Program Files/OLD-OpenOffice.org1.0/program/ Program Files/mozilla.org/Mozilla/ RECYCLER/S-1-5-21-1229272821-1563985344-1957994488-1000/Dc90.org/Mozilla-1.4/ Let me know if you want a detailed list. (Reminder, just in case: 1.4 installed successfully and is running great with the -greLocal option.)
On a Windows XP system, I was able to finally install 1.4 after 1. Running the uninstaller 2. Manually deleting the C:/Program Files/Mozilla.org directory 3. Manually deleting the C:/Program Files/Common Files/Mozilla.org directory 4. Removing most of the references to Mozilla from the registry HKEY_LOCAL_MACHINE (there were several, showing every version of Mozilla that had been installed previously) - I only left things that were necessary to preserve Netscape 7.1 items. I could not get Mozilla to install an run until I had done all 4 things, so the registry items may be the kicker. Also interesting to note is that Netscape 7.1 installed and ran fine on the same machine while Mozilla was refusing to run.
After installing the latest milestone release of Mozilla 1.4 over version 1.3, it began to launch then quickly generated an error message stating that mozilla.exe had a problem with xpcom.dll. I re-downloaded the installer, uninstalled Mozilla 1.4 and installed again. The same error message appeared. Re-installed the older Mozilla 1.3 and it is working again. My PC is running Windows XP Pro with certain SP1 patches.
I cannot reproduce any crashes installing windows 1.7 beta on top of 1.0 or 1.4. Is this still a problem for anyone?
the original report was bug 195600, fixed by bug 210731 Any issues discussed here that still exist should be reported elsewhere (after searching bugzilla) *** This bug has been marked as a duplicate of 195600 ***