Closed Bug 209896 Opened 21 years ago Closed 20 years ago

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

Categories

(SeaMonkey :: Installer, defect)

x86
Windows 2000
defect
Not set
blocker

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 195600

People

(Reporter: dwoldrich_ebay, Assigned: ssu0262)

References

()

Details

Attachments

(2 files)

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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.
Attached file 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.  

Assignee: dougt → ssu
Component: XPCOM → Installer
QA Contact: scc → bugzilla
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

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
See also bug 195600
and bug 200651
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.
Status: NEW → ASSIGNED
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 ***
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: