Mozilla 1.4rc2 crashes on first run, subsequent too, no talkback, prefs do not migrate.

RESOLVED DUPLICATE of bug 195600

Status

SeaMonkey
Installer
--
blocker
RESOLVED DUPLICATE of bug 195600
15 years ago
13 years ago

People

(Reporter: Dave Woldrich, Assigned: Sean Su)

Tracking

Trunk
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

15 years ago
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.

Comment 1

15 years ago
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".

Comment 2

15 years ago
oops, I forgot step 3 for the work around: reinstall mozilla 1.4rc2.

Comment 3

15 years ago
I am also having this problem. 1.4rc2 crashes, and the uninstaller crashes 
too.  xpcom error.  Help!  marking new.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

15 years ago
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?

Comment 5

15 years ago
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.
(Reporter)

Comment 6

15 years ago
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.

Comment 7

15 years ago
what are all of the DLL files in this directory:   e:\\Mozilla\\

Comment 8

15 years ago
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.

Comment 9

15 years ago
chris, I thought the noun "reporter" was defined.
(Reporter)

Comment 10

15 years ago
Created attachment 126343 [details]
My e:\mozilla dll's.

This list was generated from my currently running Mozilla 1.3.1 install.

Comment 11

15 years ago
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.  

Assignee: dougt → ssu
Component: XPCOM → Installer
QA Contact: scc → bugzilla
(Assignee)

Comment 12

15 years ago
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.
(Reporter)

Comment 13

15 years ago
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

ssu@netscape.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

Comment 14

15 years ago
See also bug 195600
and bug 200651

Comment 15

15 years ago
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.  
(Reporter)

Comment 16

15 years ago
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!  :)

Comment 17

15 years ago
dave, you are asking the right questions.  sean su is working on a fix to this
problem.
(Reporter)

Comment 18

15 years ago
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.

Comment 19

15 years ago
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. 
(Assignee)

Comment 20

15 years ago
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.
Status: NEW → ASSIGNED

Comment 21

15 years ago
win2k sp3.  Tried upgrade install at first, then uninstall + delete dirs. 

-greLocal fixed it! 

Comment 22

15 years ago
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)
(Assignee)

Comment 23

15 years ago
Esa, do you have write access to [program files]\common files dir?

Comment 24

15 years ago
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 
(Assignee)

Comment 25

15 years ago
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.

Comment 26

15 years ago
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.) 

Comment 27

15 years ago
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.

Comment 28

15 years ago
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.

Comment 29

14 years ago
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?

Comment 30

14 years ago
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 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.