Cannot install on WinXP SP1 (crash or -207 error due to system zlib.dll)

VERIFIED FIXED in mozilla1.2beta

Status

SeaMonkey
Installer
--
critical
VERIFIED FIXED
16 years ago
7 years ago

People

(Reporter: Carl Schrader, Assigned: dveditz)

Tracking

({crash})

Trunk
mozilla1.2beta
x86
Windows XP
crash
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(7 attachments, 1 obsolete attachment)

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020908
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020908

Cannot install using today's build or last Friday's. Crashes with Widnows asking
if I want to send an error report.

Reproducible: Always

Steps to Reproduce:
1. Try to install from full installer
2. Witness crash
3.

Actual Results:  
Crash

Expected Results:  
Installed Mozilla

Comment 1

16 years ago
no problems here.

try to download a new installer
reboot and remove any old mozilla before installing the new one.
exit all other apps before installing mozilla
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 2

16 years ago
I've done that. I have a script that runs the uninstall of the old and 
installs the new with certain paramenters. I have also tried just downloading 
the latest installer and running that. I've removed the mozilla directory, no 
dice. I've installed to a new folder, same result. 

The crash occurs when it starts installing files, after the files are 
extracted. Unfortunately, I have been unable to figure out on which file since 
the Windows error dialog pops up really quick over the top and hoses the 
Mozilla display. 

This has to be SP1 related since I was able to install the 9:05 Build before 
installing SP1. After installing SP1, the Mozilla setup crashes. This occurs 
on the install from Friday, the 9:05 one and the lastest (12:30?) as well.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---

Comment 3

16 years ago
try finding the install log file for mozilla. it's in the mozilla.org/mozilla
directory. attach it to this bug report.
(Reporter)

Comment 4

16 years ago
Created attachment 98456 [details]
install_wizard.txt
(Reporter)

Comment 5

16 years ago
Created attachment 98457 [details]
install_status.log
Attachment #98457 - Attachment mime type: application/octet-stream → text/plain
Comment on attachment 98456 [details]
install_wizard.txt

it crashed before it started logging anything, very early in the process.
Attachment #98456 - Attachment mime type: application/octet-stream → text/plain

Comment 7

16 years ago
I'm pretty sure that this problem is a local problem related to your PC. Nobody
else has reported this problem and I cant reproduce it. Either please reinstall
SP1 or try installing mozilla on another winxpsp1 machine.
(Reporter)

Comment 8

16 years ago
I've reinstalled SP1. No dice. I'll try it on another SP1 machine tonight. Any
idea what could be going on? It bombs when it's installing XpCom. I can use the
nightly zips to get the latest version installed but I hate to have to do it
that way. The install process I have set up works really well with uninstalling
the previous version and installing the new with the options I want.. with a
single click..

Comment 9

16 years ago
1. uninstall old mozilla
2. delete any files in %tmp and %temp
3. remove entire mozilla.org/mozilla directory
4. redownload a new installer

then try to install mozilla again...
(Reporter)

Comment 10

16 years ago
ACK.. no dice. It doesn't seem to be a directory issue.. I have changed install
directories, cleared the tmp directories and set windows to use a diff temp dir.
It's bombing just after creating the uninstall directory as that's the last
entry in the log. I guess I am SOL.. oh well..we'll see if anyone else reports
this later on..
(Reporter)

Comment 11

16 years ago
AHA! A dupe:
http://bugzilla.mozilla.org/show_bug.cgi?id=167752

Glad it wasn't just me..

Comment 12

16 years ago
*** Bug 167752 has been marked as a duplicate of this bug. ***

Comment 13

16 years ago
Created attachment 98614 [details]
Attachments as asked for...

This is all the installer crash information I could find...

Error signature:
AppName: setup.exe AppVer: 1.0.0.2 ModName: jar50.dll ModVer: 1.1.0.0 Offset:
00001542

attached files, two log files from the failed installation, the error report
generated by winxp, and the actual error dump from the crash...enjoy!

Updated

16 years ago
Attachment #98614 - Attachment description: Attachments as asket for... → Attachments as asked for...

Comment 14

16 years ago
Confirming seeing it's been duped
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 15

16 years ago
Yep I'm getting the same problems, Mozilla 1.1 installer crashing durring the 
install on the Final XP-SP1. I've noticed it stops in the exact same spot 
everytime, I've tried to install 5x with diffrent downloads (Thinking maybe I 
corrupted it.) with no luck.

Comment 16

16 years ago
Created attachment 98640 [details]
The Error Report Log

Here's a copy of my error report log.

Comment 17

16 years ago
I am getting a different UA string with that build

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020908

am not crashing- have SP1 v.1089 (is that final?)

Comment 18

16 years ago
crashing users:

please try to download:
http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-installer.exe
and install. you still crash?

Comment 19

16 years ago
I still crash...the same spot, the same error, the same (well, almost, it's a 
new time) log

Comment 20

16 years ago
SP1 v.1089 was a earlier BETA SP1 build, 

I was on v.1094 and it crashed,

upgraded to the final release from MS and it crashed.

Going to try the latest nightly build now.

Comment 21

16 years ago
novel idea here -- but did anyone ever try to system restore to pre-sp1 times?

yeah, i know, revolutionary!


also -- the final build of xp sp1 is 1106, released sept 9

Comment 22

16 years ago
crashed again.

Comment 23

16 years ago
I'm having the same problem here. WinXP with SP1 (build 1106), tried about 5 
versions. All crash at same spot.

Comment 24

16 years ago
*** Bug 168178 has been marked as a duplicate of this bug. ***

Comment 25

16 years ago
Clarifying summary.

Has *anyone* managed to install on SP1-final (build 1106, according to comment 
21)?  i.e., is this a general problem that affects all users of XP SP1, or is 
it only affecting some people?.

Do the Mozilla 1.0 or 1.0.1 installs work on SP1, or do they crash as well?
Summary: Installer crashes after WinXP SP1 install → Cannot install on WinXP SP1 (installer crashes)

Comment 26

16 years ago
*** Bug 159564 has been marked as a duplicate of this bug. ***

Comment 27

16 years ago
There is some useful information in duplicate bug 159564, including a note to 
indicate that this problems exists back to the 1.0 installer.
(Reporter)

Comment 28

16 years ago
I've tried different versions on 2 machines - both crash at the same point..

Comment 29

16 years ago
I have installed a new copy of Windows XP and added the final release of SP1, 
and have tried to install Mozilla 1.1 and have crashed when it is copying 
files. I have seen a number of complaints in the news groups about this same 
problem. I have tried it on several machines with the exact same results. This 
appears to have started when Windows XP SP1 has been installed. I have also 
tried the Mozilla 1.2 Alpha version, and have the same results.

Comment 30

16 years ago
Ok.  So far, Henrik is the only person who has said that they can install 
Mozilla on XP SP1 (comment 1).

(cc'ing Henrik)
Henrik, are you sure you're using the 1106 build of SP1?

The next step would be for someone to debug the installer and identify where 
it's failing.  Can someone get a development environment set up on XP SP1 and 
run the installer via the debugger? (I have a development environment, but I 
don't have XP).

Comment 31

16 years ago
No need to CC me. I'm already on the list. I'm QA on the Win32 installer.

Somehow Windows managed to say "sp1 is install" while that actually didn't
happen. So we properly have a problem installing mozilla on WinXP sp1 systems!

Comment 32

16 years ago
Something wrong somewhere ;-)

I have SP1 (1106 build) installed on a clean XP install, and Mozilla installer
(1.2.0.2002091208) has finished its work without problem !

So Henry is not the only one who can install mozilla trunk build on WinXP-SP1

Comment 33

16 years ago
I can certainly confirm that it doesn't work properly - I've tried in 
installing on quite a few PC's with WinXP SP1 - always crashes in the same 
place.
*** Bug 168436 has been marked as a duplicate of this bug. ***

Comment 35

16 years ago
*** Bug 168356 has been marked as a duplicate of this bug. ***

Comment 36

16 years ago
just installed SP1 on my XP
I now have "Build 2600.xpsp1.020828-1920"

and then installed Mozilla with no problems!

So I tend to -> Worksforme...
This is happening to too many people too consistently to be WFM, but finding the
exact environment differences between a broken SP1 and a working SP1 are going
to be hard unless we can debug one of the broken systems. So far I haven't found
anyone local who crashes on win xp sp1

Comment 38

16 years ago
In answer to comment #37 :

3 possibilities :

- non final sp1 installed (not a build 1106 for XP-SP1)

- install sp1 over an "old and dirty" previous WinXP.

- overclocked hardware (?!)

Well, with a fresh install of WinXP and then SP1 (I made myself a WinXP-SP1
bootable CD-Rom in order to be practical), there seems to be no problem at all.

So ?

Comment 39

16 years ago
Tried to install the latest stable version - 1.0.1. System: WinXP SP1 (final) 
integrated, fresh install. Effect: Mozilla installer crashes at the same time, 
in the same way.

Comment 40

16 years ago
Works For Me - Moz1.2a onto Windows XP SP1 final (build 1106).

Comment 41

16 years ago
I am experiencing the same problem on all 5 of my XP computers that were just
recently upgraded to SP1. 
Win XP SP1 (IE 6 SP1)
I cannot install the latest build of Mozilla. I tried downloading the
bulild for Sept 11, 12 and 13 and everytime it starts to install it
crashes and the Microsoft Send Error Report window pops up asking me to
submit the error. I have tried multiple times. I tried downloading the
Zip installation file, the internet downloader and the regular 10.4 mb
exe installer and all of them do the same thing. The only thing that
changed on my pc is the installation of SP1. Is anyone else who is
running SP1 experiencing the installation issue? I have 5 different computers
all running Win XP SP1 and all experience the same problem. I also asked my
friends with XP SP1 to install mozilla and they have the same problem also.
Here is the report that MS Error Reporting is trying to send:
AppName: setup.exe     AppVer: 1.0.0.2     ModName: zlib.dll
ModVer: 1.31.0.1709     Offset: 00001157

<?xml version="1.0" encoding="UTF-16"?>
<DATABASE>
<EXE NAME="SETUP.EXE" FILTER="GRABMI_FILTER_PRIVACY">
    <MATCHING_FILE NAME="SETUP.EXE" SIZE="233280" CHECKSUM="0xC1449415"
BIN_FILE_VERSION="1.0.0.2" BIN_PRODUCT_VERSION="1.0.0.2" PRODUCT_VERSION="1, 0,
0, 2" FILE_DESCRIPTION="setup" COMPANY_NAME="mozilla.org" PRODUCT_NAME="Mozilla
Setup" FILE_VERSION="1, 0, 0, 2" ORIGINAL_FILENAME="setup.exe"
INTERNAL_NAME="setup" LEGAL_COPYRIGHT="Copyright © 2001" VERFILEDATEHI="0x0"
VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x1" MODULE_TYPE="WIN32"
PE_CHECKSUM="0x47DA1" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.0.0.2"
UPTO_BIN_PRODUCT_VERSION="1.0.0.2" LINK_DATE="09/13/2002 12:06:45"
UPTO_LINK_DATE="09/13/2002 12:06:45" VER_LANGUAGE="English (United States)
[0x409]" />
    <MATCHING_FILE NAME="SETUPRSC.DLL" SIZE="153472" CHECKSUM="0x30C693EF"
MODULE_TYPE="WIN32" PE_CHECKSUM="0x3363F" LINKER_VERSION="0x0"
LINK_DATE="09/13/2002 20:52:06" UPTO_LINK_DATE="09/13/2002 20:52:06" />
    <MATCHING_FILE NAME="xpcom.ns\bin\js3250.dll" SIZE="327616"
CHECKSUM="0x38A3C7CA" BIN_FILE_VERSION="4.0.0.0" BIN_PRODUCT_VERSION="4.0.0.0"
PRODUCT_VERSION="4.0" FILE_DESCRIPTION="Netscape 32-bit JavaScript Module"
COMPANY_NAME="Netscape Communications Corporation" PRODUCT_NAME="NETSCAPE"
FILE_VERSION="4.0" ORIGINAL_FILENAME="js3240.dll" INTERNAL_NAME="JS3240"
LEGAL_COPYRIGHT="Copyright Netscape Communications. 1994-96" VERFILEDATEHI="0x0"
VERFILEDATELO="0x0" VERFILEOS="0x10004" VERFILETYPE="0x2" MODULE_TYPE="WIN32"
PE_CHECKSUM="0x5EC23" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="4.0.0.0"
UPTO_BIN_PRODUCT_VERSION="4.0.0.0" LINK_DATE="09/13/2002 20:52:04"
UPTO_LINK_DATE="09/13/2002 20:52:04" VER_LANGUAGE="English (United States)
[0x409]" />
    <MATCHING_FILE NAME="xpcom.ns\bin\nspr4.dll" SIZE="160304"
CHECKSUM="0x5E001B64" BIN_FILE_VERSION="4.2.1.0" BIN_PRODUCT_VERSION="4.2.1.0"
PRODUCT_VERSION="4.2.1" FILE_DESCRIPTION="NSPR Library" COMPANY_NAME="Netscape
Communications Corporation" PRODUCT_NAME="Netscape Portable Runtime"
FILE_VERSION="4.2.1" ORIGINAL_FILENAME="nspr4.dll" INTERNAL_NAME="nspr4"
LEGAL_COPYRIGHT="Copyright © 1996-2000 Netscape Communications Corporation"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2"
MODULE_TYPE="WIN32" PE_CHECKSUM="0x2ED3D" LINKER_VERSION="0x0"
UPTO_BIN_FILE_VERSION="4.2.1.0" UPTO_BIN_PRODUCT_VERSION="4.2.1.0"
LINK_DATE="09/13/2002 20:52:04" UPTO_LINK_DATE="09/13/2002 20:52:04"
VER_LANGUAGE="English (United States) [0x409]" />
    <MATCHING_FILE NAME="xpcom.ns\bin\plc4.dll" SIZE="29792"
CHECKSUM="0x46EFCDC2" BIN_FILE_VERSION="4.2.1.0" BIN_PRODUCT_VERSION="4.2.1.0"
PRODUCT_VERSION="4.2.1" FILE_DESCRIPTION="PLC Library" COMPANY_NAME="Netscape
Communications Corporation" PRODUCT_NAME="Netscape Portable Runtime"
FILE_VERSION="4.2.1" ORIGINAL_FILENAME="plc4.dll" INTERNAL_NAME="plc4"
LEGAL_COPYRIGHT="Copyright © 1996-2000 Netscape Communications Corporation"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2"
MODULE_TYPE="WIN32" PE_CHECKSUM="0xA7AB" LINKER_VERSION="0x0"
UPTO_BIN_FILE_VERSION="4.2.1.0" UPTO_BIN_PRODUCT_VERSION="4.2.1.0"
LINK_DATE="09/13/2002 20:52:04" UPTO_LINK_DATE="09/13/2002 20:52:04"
VER_LANGUAGE="English (United States) [0x409]" />
    <MATCHING_FILE NAME="xpcom.ns\bin\plds4.dll" SIZE="25424"
CHECKSUM="0x93B05E7B" BIN_FILE_VERSION="4.2.1.0" BIN_PRODUCT_VERSION="4.2.1.0"
PRODUCT_VERSION="4.2.1" FILE_DESCRIPTION="PLDS Library" COMPANY_NAME="Netscape
Communications Corporation" PRODUCT_NAME="Netscape Portable Runtime"
FILE_VERSION="4.2.1" ORIGINAL_FILENAME="plds4.dll" INTERNAL_NAME="plds4"
LEGAL_COPYRIGHT="Copyright © 1996-2000 Netscape Communications Corporation"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2"
MODULE_TYPE="WIN32" PE_CHECKSUM="0x64DC" LINKER_VERSION="0x0"
UPTO_BIN_FILE_VERSION="4.2.1.0" UPTO_BIN_PRODUCT_VERSION="4.2.1.0"
LINK_DATE="09/13/2002 20:52:04" UPTO_LINK_DATE="09/13/2002 20:52:04"
VER_LANGUAGE="English (United States) [0x409]" />
    <MATCHING_FILE NAME="xpcom.ns\bin\xpcom.dll" SIZE="513680"
CHECKSUM="0x3384F698" BIN_FILE_VERSION="1.2.0.0" BIN_PRODUCT_VERSION="1.2.0.0"
PRODUCT_VERSION="1.2b" FILE_DESCRIPTION="" COMPANY_NAME="Mozilla, Netscape"
PRODUCT_NAME="Mozilla" FILE_VERSION="1.2b" ORIGINAL_FILENAME=""
INTERNAL_NAME="xpcom" LEGAL_COPYRIGHT="License: MPL 1.1/GPL 2.0/LGPL 2.1"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2"
MODULE_TYPE="WIN32" PE_CHECKSUM="0x8132F" LINKER_VERSION="0x0"
UPTO_BIN_FILE_VERSION="1.2.0.0" UPTO_BIN_PRODUCT_VERSION="1.2.0.0"
LINK_DATE="09/13/2002 20:52:06" UPTO_LINK_DATE="09/13/2002 20:52:06"
VER_LANGUAGE="Language Neutral [0x0]" />
    <MATCHING_FILE NAME="xpcom.ns\bin\xpistub.dll" SIZE="7664"
CHECKSUM="0xE67E579A" BIN_FILE_VERSION="1.2.0.0" BIN_PRODUCT_VERSION="1.2.0.0"
PRODUCT_VERSION="1.2b" FILE_DESCRIPTION="" COMPANY_NAME="Mozilla, Netscape"
PRODUCT_NAME="Mozilla" FILE_VERSION="1.2b" ORIGINAL_FILENAME=""
INTERNAL_NAME="xpistub" LEGAL_COPYRIGHT="License: MPL 1.1/GPL 2.0/LGPL 2.1"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2"
MODULE_TYPE="WIN32" PE_CHECKSUM="0x2FB3" LINKER_VERSION="0x0"
UPTO_BIN_FILE_VERSION="1.2.0.0" UPTO_BIN_PRODUCT_VERSION="1.2.0.0"
LINK_DATE="09/13/2002 20:52:06" UPTO_LINK_DATE="09/13/2002 20:52:06"
VER_LANGUAGE="Language Neutral [0x0]" />
    <MATCHING_FILE NAME="xpcom.ns\bin\zlib.dll" SIZE="39088"
CHECKSUM="0xBD9BAB5E" BIN_FILE_VERSION="1.2.0.0" BIN_PRODUCT_VERSION="1.2.0.0"
PRODUCT_VERSION="1.2b" FILE_DESCRIPTION="" COMPANY_NAME="Mozilla, Netscape"
PRODUCT_NAME="Mozilla" FILE_VERSION="1.2b" ORIGINAL_FILENAME=""
INTERNAL_NAME="zlib" LEGAL_COPYRIGHT="License: MPL 1.1/GPL 2.0/LGPL 2.1"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2"
MODULE_TYPE="WIN32" PE_CHECKSUM="0x15D73" LINKER_VERSION="0x1000D"
UPTO_BIN_FILE_VERSION="1.2.0.0" UPTO_BIN_PRODUCT_VERSION="1.2.0.0"
LINK_DATE="09/13/2002 20:52:04" UPTO_LINK_DATE="09/13/2002 20:52:04"
VER_LANGUAGE="Language Neutral [0x0]" />
    <MATCHING_FILE NAME="xpcom.ns\bin\components\jar50.dll" SIZE="28864"
CHECKSUM="0x9631F262" BIN_FILE_VERSION="1.2.0.0" BIN_PRODUCT_VERSION="1.2.0.0"
PRODUCT_VERSION="1.2b" FILE_DESCRIPTION="" COMPANY_NAME="Mozilla, Netscape"
PRODUCT_NAME="Mozilla" FILE_VERSION="1.2b" ORIGINAL_FILENAME=""
INTERNAL_NAME="jar" LEGAL_COPYRIGHT="License: MPL 1.1/GPL 2.0/LGPL 2.1"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2"
MODULE_TYPE="WIN32" PE_CHECKSUM="0x141CB" LINKER_VERSION="0x0"
UPTO_BIN_FILE_VERSION="1.2.0.0" UPTO_BIN_PRODUCT_VERSION="1.2.0.0"
LINK_DATE="09/13/2002 20:52:05" UPTO_LINK_DATE="09/13/2002 20:52:05"
VER_LANGUAGE="Language Neutral [0x0]" />
    <MATCHING_FILE NAME="xpcom.ns\bin\components\ucharuti.dll" SIZE="19904"
CHECKSUM="0x5D67486A" BIN_FILE_VERSION="1.2.0.0" BIN_PRODUCT_VERSION="1.2.0.0"
PRODUCT_VERSION="1.2b" FILE_DESCRIPTION="" COMPANY_NAME="Mozilla, Netscape"
PRODUCT_NAME="Mozilla" FILE_VERSION="1.2b" ORIGINAL_FILENAME=""
INTERNAL_NAME="unicharutil" LEGAL_COPYRIGHT="License: MPL 1.1/GPL 2.0/LGPL 2.1"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2"
MODULE_TYPE="WIN32" PE_CHECKSUM="0xEA58" LINKER_VERSION="0x0"
UPTO_BIN_FILE_VERSION="1.2.0.0" UPTO_BIN_PRODUCT_VERSION="1.2.0.0"
LINK_DATE="09/13/2002 20:52:04" UPTO_LINK_DATE="09/13/2002 20:52:04"
VER_LANGUAGE="Language Neutral [0x0]" />
    <MATCHING_FILE NAME="xpcom.ns\bin\components\xpinstal.dll" SIZE="137200"
CHECKSUM="0x63A0018B" BIN_FILE_VERSION="1.2.0.0" BIN_PRODUCT_VERSION="1.2.0.0"
PRODUCT_VERSION="1.2b" FILE_DESCRIPTION="" COMPANY_NAME="Mozilla, Netscape"
PRODUCT_NAME="Mozilla" FILE_VERSION="1.2b" ORIGINAL_FILENAME=""
INTERNAL_NAME="xpinstall" LEGAL_COPYRIGHT="License: MPL 1.1/GPL 2.0/LGPL 2.1"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2"
MODULE_TYPE="WIN32" PE_CHECKSUM="0x2FCEA" LINKER_VERSION="0x0"
UPTO_BIN_FILE_VERSION="1.2.0.0" UPTO_BIN_PRODUCT_VERSION="1.2.0.0"
LINK_DATE="09/13/2002 20:52:05" UPTO_LINK_DATE="09/13/2002 20:52:05"
VER_LANGUAGE="Language Neutral [0x0]" />
</EXE>
<EXE NAME="zlib.dll" FILTER="GRABMI_FILTER_THISFILEONLY">
    <MATCHING_FILE NAME="ZLIB.DLL" SIZE="69687" CHECKSUM="0x6FE96712"
BIN_FILE_VERSION="1.31.0.1709" BIN_PRODUCT_VERSION="1.31.0.1709"
PRODUCT_VERSION="1.31.0" FILE_DESCRIPTION="ZLib" COMPANY_NAME="Trend Micro Inc."
PRODUCT_NAME="Trend Active Update 1.31" FILE_VERSION="1.31.0.1709"
ORIGINAL_FILENAME="ZLib.dll" INTERNAL_NAME="ZLib" LEGAL_COPYRIGHT="Copyright (C)
1999-2002 Trend Micro Inc. All rights reserved." VERFILEDATEHI="0x0"
VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32"
PE_CHECKSUM="0x0" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.31.0.1709"
UPTO_BIN_PRODUCT_VERSION="1.31.0.1709" LINK_DATE="01/25/2002 18:18:23"
UPTO_LINK_DATE="01/25/2002 18:18:23" VER_LANGUAGE="English (United States)
[0x409]" />
</EXE>
<EXE NAME="kernel32.dll" FILTER="GRABMI_FILTER_THISFILEONLY">
    <MATCHING_FILE NAME="kernel32.dll" SIZE="930304" CHECKSUM="0xCBCCF8A9"
BIN_FILE_VERSION="5.1.2600.1106" BIN_PRODUCT_VERSION="5.1.2600.1106"
PRODUCT_VERSION="5.1.2600.1106" FILE_DESCRIPTION="Windows NT BASE API Client
DLL" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Microsoft® Windows®
Operating System" FILE_VERSION="5.1.2600.1106 (xpsp1.020828-1920)"
ORIGINAL_FILENAME="kernel32" INTERNAL_NAME="kernel32" LEGAL_COPYRIGHT="©
Microsoft Corporation. All rights reserved." VERFILEDATEHI="0x0"
VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32"
PE_CHECKSUM="0xE7ED3" LINKER_VERSION="0x50001"
UPTO_BIN_FILE_VERSION="5.1.2600.1106" UPTO_BIN_PRODUCT_VERSION="5.1.2600.1106"
LINK_DATE="08/29/2002 10:40:40" UPTO_LINK_DATE="08/29/2002 10:40:40"
VER_LANGUAGE="English (United States) [0x409]" />
</EXE>
</DATABASE>

Comment 42

16 years ago
After not being able to install 1.2a on an SP1 system, I've reinstalled XP with
SP1 and *succeeded* in installing 1.2a.  Same build of SP1.  Same hardware.

Comment 43

16 years ago
An addition to my last post.
My Computers have Win XP SP1. Version: 5.1.2600 SP1 Build 2600. 
Hardware Abstraction Layer	Version = "5.1.2600.1106 (xpsp1.020828-1920)"

Comment 44

16 years ago
*** Bug 168715 has been marked as a duplicate of this bug. ***

Comment 45

16 years ago
*** Bug 168718 has been marked as a duplicate of this bug. ***

Comment 46

16 years ago
with application compatiblity turned on on setup.exe you can install mozilla!
(set to windows 95)

Comment 47

16 years ago
Confirmed (Comment #46) : when compatibility mode (win9x) is applied to the 
setup file, Mozilla 1.2a installs without problems on my system. But of course 
this is not the solution of the problem in general.

Comment 48

16 years ago
hey thanks matthias .. when I set the application compatiblity setting to 
win95 on the setup.exe it installed perfectly! so i guess the question is... 
is the installer incompatible with winxp-sp1 or is winxp-sp1 incompatible with 
the installer?..

Comment 49

16 years ago
How do I change application compatiblity?

Comment 50

16 years ago
I too had success, thanks

right click on the .exe, select properties, click on the compatability tab at 
the tab, check the run in compatability mode box, select win9x
In bug 168715 matthias.ableitner@gmx.de reports

"with application compatiblity turned on on setup.exe it works! (set to windows 95)"

Could some of you guys crashing try that? And at our end we'll try turning that
off and see if we can find the crash. Failing that one of you guys will have to
send me your machine ;-)

Comment 52

16 years ago
Changing compatability mode for the setup.exe to Win 95 worked for me.

Comment 53

16 years ago
Compatibility mode for Windows 98/Windows ME also works.

Comment 54

16 years ago
It's worth noting that *some* (but not all) of the crashes reported here have
something in common - when the error is reported in zlib.dll, the 'loaded
modules' section (I assume that's what it is) includes *two* versions of
zlib.dll - the Mozilla one, and another one that's part of the 'Trend Active
Update 1.31' product.

To reiterate - this isn't something we're seeing in every crash, but I thought
it looked odd enough to mention.

See for example attachment 98640 [details] or comment 41, but not attachment 98640 [details].

Relavent? I'm not sure.

Comment 55

16 years ago
I'm also seeing the Trend file in my crash w/ XP SP 1. I changed the 
compatibility mode to Win95 and it installed fine. In my case, the file's a 
remnant Trend's uninstaller left behind, and I disabled the Trend management 
agent running at startup, so it surprises me that its zlib.dll is loading as 
well. System Information reports that the only version I have loaded right now, 
with Mozilla running, to be the Mozilla version of zlib.dll.

Comment 56

16 years ago
I'm not sure whether the Trend zlib.dll is actually being loaded, but it seemed
notable to me that it's mentioned in the application report.  Can anyone who's
experiencing a crash temporarily remove or rename the Trend zlib.dll and see
whether the installer still crashes?

Comment 57

16 years ago
newest zlib.dll file can be downloaded at:
http://www.winimage.com/zLibDll/

Comment 58

16 years ago
Success :) Removed zlib.dll from Windows\System32 dir and tried to install 
Mozilla *without* compatibility mode enabled and the install went smoothly. 
When I put this file back into \System32 - the installer crashed as usual. So 
I think this zlib.dll is a problem here.

Comment 59

16 years ago
could you attach the zlib.dll file to this bug report?

Comment 60

16 years ago
Created attachment 99274 [details]
zlib.dll which causes problems

Comment 61

16 years ago
As for that .dll which caused problems: unfortunatelly, I deleted it :(. I 
have recovered it but can't say if it's damaged or not - the header looks OK. 
Maybe it can help so I'm attaching it. It is significantly larger than the 
version downloaded from http://www.winimage.com/zLibDll/ (which worked for me) 
but this is correct for that file. I wanted to copy this file from another 
machine with XP SP1 (final) but there was no such file. So probably 
that "corrupted" zlib.dll is copied to \System32 by a particular, rather 
popular application (I can't say what app though).

Comment 62

16 years ago
*** Bug 168823 has been marked as a duplicate of this bug. ***

Comment 63

16 years ago
from bug 168823 :
the crashing *is* due to having zlib.dll in the C:\WinNT\system32 directory.

Temporary solution: move zlib.dll out of C:\WinNT\system32 directory
Summary: Cannot install on WinXP SP1 (installer crashes) → Cannot install on WinXP SP1 (installer crashes) (due to zlib.dll)

Comment 64

16 years ago
Just a slight modification to comment #63 :

It is not c:\winnt\ but c:\windows\ under WinXP.

C:\winnt is only true for any NT OS before WinXP.

Just my 0.02$

Comment 65

16 years ago
yes, removing c:\windows\system32\zlib.dll works :-)
What *stops* working now that you've removed the system32 zlib.dll? Some program
put it there and probably expects to find it.
Blocks: 168860
I guess the question is did Service Pack 1 change the program load order, or did
it install this zlib.dll, and if the latter why do some people not crash?
No longer blocks: 168860
Status: NEW → ASSIGNED
Blocks: 168860

Comment 68

16 years ago
In answer to comment #67 : No zlib.dll in my \windows\system32 folder.

SP1 does not install it. It seems to be related to some Trend Software (like
PC-Cillin Antivirus ?)

Comment 69

16 years ago
Dan,

Yes - I wondered about that.  MSDN implies that some DLL-loading functionality
was changed in SP1 - the Get/SetDllDirectory functions were added to allow the
application to modify the search path.  However, it doesn't explain exactly how
the wrong DLL could be picked up in SP1 compared to RTM.

The following excerpt from LoadLibrary's documentation shows the search sequence
for DLLs:

   1. The directory from which the application loaded.
   2. The current directory.

Windows XP:
If HKLM\System\CurrentControlSet\Control\SessionManager\SafeDllSearchMode is 1,
the current directory is searched after the system and Windows directories, but
before the directories in the PATH environment variable. The default value is 0
(current directory is searched before the system and Windows directories).

   3. The system directory.
      Windows NT/2000/XP: The name of this directory is System32.
   4. Windows NT/2000/XP: The 16-bit system directory. The name of this
directory is System.
   5. The Windows directory.
   6. The directories that are listed in the PATH environment variable.

Crashing people: could you check what value is set in the registry for
HKLM\System\CurrentControlSet\Control\SessionManager\SafeDllSearchMode

Dan: In the case of the installer, will the directory the executable is located
in also contain the zlib DLL?

Not all the crashes appear to be due to zlib.dll - but they may all be due to
the same root cause - loading the wrong DLL.

Comment 70

16 years ago
I don't have "SafeDllSearchMode" entry in the location given.

Comment 71

16 years ago
I don't have SafeDllSearchMode in my registry either.  The zlib.dll in my system32 directory is version 1.1.4.0 93696 bytes.  I do have ActiveState perl 5.6 on my path and it has a 69632 byte zlib.dll in C:\Perl\site\lib\auto\Compress\Zlib.  It's registered as:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\79B16496062A26542B89E8F0AA6007CF (291B64A794B22C24E82B8298A0D0D05C=C:\Perl\site\lib\auto\Compress\Zlib\Zlib.dll)

Comment 72

16 years ago
More data points, but first:

HKLM\System\CurrentControlSet\Control\SessionManager\SafeDllSearchMode
                                      ^^^^^^^^^^^^^^
That should be "Session Manager" (the space).

Anyway, I have a Dell-standard WinXP Pro installation with an SP1 update, and:

* no SafeDllSearchMode value there (or anywhere else), and
* no zlib.dll (but we already knew that, I think).

Comment 73

16 years ago
I haven't seen this on my XPSP1 install, but I'll try to reproduce it some more.

Updated

16 years ago
Blocks: 168066

Comment 74

16 years ago
Comment on attachment 99274 [details]
zlib.dll which causes problems

Tom, sorry - the file is corrupted.
Attachment #99274 - Attachment is obsolete: true

Comment 75

16 years ago
Malcolm: as soon as I determine which application is copying that file I'll 
give a note here and attach this file if necessary but for now no idea what 
app that could be.

Comment 76

16 years ago
I don't have any zlib.dll in my windows system folder and I have never installed
any Trend products. I also tried deleting all files in every temp folder and
uninstalling and then deleting the mozilla folder.. All to no avail.. only thing
that works is changing the properties for the setup.exe for me.. If I don't I
always get the error message that says "Mozilla XPCOM: -207 CANT_READ_ARCHIVE"..

Comment 77

16 years ago
Isnt zlib.dll some sort of open source compression utilities and can be used 
by any program that chooses to utilize it. I searched my pc for zlib.dll and 
found that this file is located in the Windows directory, Mozilla folder, I 
also have a PERL compiler and that file is located there also, as well as 
several other programs. They might use the same name but server different 
purpose but as far as I understand zlib.dll is used for compressing and 
decompressing files and is not installed by any specific program. Here is the 
zlib.dll webpage:
http://www.gzip.org/zlib/

I have tried putting the latest version of zlib.dll which is 1.1.4.0 into the 
C:\Windows directory but that doesnt resolve the issue. What is the zlib.dll 
in the Mozilla folder?

Comment 78

16 years ago
HA!... I just searched my computer and have found a version of Zlib.dll that was
not included in my windows/system32 folder but directly in my windows folder! I
don't know how it got there.. I have NEVER installed any Trend product.. So I'm
guessing that more than one product has to be using the Trend version of
Zlib.dll. But still, why did the problem surface after installing SP1?.. Also
according to the file properties the file mysteriously created on 'Sunday, July
07, 2002, 8:03:23 PM' and is 68.0 KB (69,687 bytes). Here is the info I
extracted from the file... 
1 VERSIONINFO
FILEVERSION 1,31,0,1709
PRODUCTVERSION 1,31,0,1709
FILEOS 0x40004
FILETYPE 0x2
{
BLOCK "StringFileInfo"
{
	BLOCK "040904b0"
	{
		VALUE "Comments", ""
		VALUE "FileDescription", "ZLib"
		VALUE "InternalName", "ZLib"
		VALUE "OriginalFilename", "ZLib.dll"
		VALUE "CompanyName", "Trend Micro Inc."
		VALUE "LegalCopyright", "Copyright (C) 1999-2002 Trend Micro Inc. All rights
reserved."
		VALUE "LegalTrademarks", "Copyright (C) Trend Micro Inc."
		VALUE "PrivateBuild", "Build 1709 - 1/25/2002"
		VALUE "ProductName", "Trend Active Update 1.31"
		VALUE "ProductVersion", "1.31.0"
		VALUE "SpecialBuild", "1709"
		VALUE "FileVersion", "1.31.0.1709"

Comment 79

16 years ago
Created attachment 99491 [details]
From "DR. Watson"

Here is the chunk of data that relates to the crash from my drwtsn32.log file.

Comment 80

16 years ago
I think this bug may be becoming confused.
Here's where we are at the moment:

1. *Some* people on XPSP1 are crashing within zlib.dll during the install.  Some
people are getting a decompression error message (that's bug 168860).
2. One common data point in the crashes is that the Windows Error Reporting
manifest includes a 'foreign' zlib dll.
3. zlib is a general-purpose compression library.  We use it, other people use it.
4. There is nothing wrong with having multiple versions of the zlib dll, but we
should only ever be loading our version.  The crashes identify the foreign zlib
dll as a 'Trend Micro' version (probably from a virus scanner), but that's
mostly irrelevant - it's the fact that it's not ours that's causing the problem.
5. *We do not know for sure* whether the foreign dll is being loaded, but if it
were, that would explain the errors reported, so we are proceeding under that
assumption.
6. The DLL loading mechanism has changed slightly within XP SP1, but our
application *should* be unaffected.

Where to go:
1. Getting a hold of the Trend zlib dll would probably not be immediately
helpful, except to reproduce the crashes.
2. Does anyone who is crashing have the SafeDllSearchMode value set in the
registry?  The correct location is in comment 72.  Please don't reply if you
don't, only if you do.
3. If anyone who is crashing is running a virus scanner, please disable it and
try re-running the installer. If that now works, please tell us.

Here's a description of the install process, as I understand it:
1. nsinstall decompresses everything to %temp%\ns_temp and runs setup.
2. setup contains a statically-linked version of zlib and inflates the xpi files.
xpcom.xpi contains (among others):
xpinstal.dll, placed in %temp%\ns_temp\xpcom.ns\bin\components\.
zlib.dll, placed in %temp%\ns_temp\xpcom.ns\bin\.

3. Somebody (setup?) loads xpinstal.dll, which needs zlib.dll.

Based on the description of the DLL search path in comment 69, could someone
explain to me how xpinstal.dll is supposed to find zlib.dll in any case?

Comment 81

16 years ago
Created attachment 99497 [details]
Empty DLL to use to check DLL search path

Ok, here's an idea.  We don't know whether we really are loading the foreign
zlib dll, and we don't know whether the DLL load order changed with XPSP1.

The attached DLL is a stub DLL that doesn't contain any exports.  The DllMain
function attempts to display a message on the screen (though it seems that
DllMain doesn't always get called if the requested export doesn't exist).  If a
program attempts to load this DLL, it will fail (in some fashion).

1. Could someone who is/was crashing save this DLL as
\windows\system32\zlib.dll (you will probably want to back up the original
first) and re-run the installer?  If we are really loading the dll from
system32, something bad should happen (and the installation will fail).

2. Could someone on XPSP1 and someone on XPRTM who *aren't* crashing do the
same? If the behaviour changed in SP1, this should show it up.

I tried this on W2K.  If this DLL is in System32, the installation suceeds. 
Only if I copy it to %temp%\ns_temp will the installation fail.  The error I
get is 'Error occurred during installation - Mozilla XPCOM: -322
INIT_STUB_ERROR', which I think is fair enough.

Comment 82

16 years ago
Placed that dll Malcolm gave in \windows\System32 dir. Mozilla installer 
crashes giving a msg: "Error occured during installation - Mozilla XPCOM: -322 
INIT_STUB_ERROR".

Comment 83

16 years ago
by saving http://bugzilla.mozilla.org/attachment.cgi?id=99497&action=view
as "zlib.dll" and putting that into c:\windows\system32 I'm also getting the
STUB_ERROR.

We should fix this so that the mozilla installer always searching the paths used
in the setup temp dirs and not just counting on the system not having any
similar named dll's. there could potentially be other that just "zlib.dll"

link to MSDN article is:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/loadlibrary.asp

Comment 84

16 years ago
Henrik, agreed - this is the root cause of the problem.

The thing I don't understand is how this is working at the moment (at ALL).
How are we expecting to find %temp%\ns_temp\xpcom.ns\bin\zlib.dll?  Magic?

Check off the items in the list I posted (and you linked to):

0. A full path? Maybe, but that won't take care of dependencies, unless we 
ensure that we load everything in the right order.
1. The directory from which the application loaded.
   Nope - that's %temp%\ns_temp
2. The current directory.
   Maybe - but highly unlikely (then the question becomes: how are we loading 
stuff in bin/components).
3. The system directory. Nope.
4. The 16-bit system directory. Nope.
5. The Windows directory. Nope.
6. The directories that are listed in the PATH environment variable.
   I don't think so - otherwise this problem would be reproducable in W2K.

Now, it *does* work, and we don't see this problem in W2K (or WXP RTM, by the 
looks of things), so something changed.  I think if we can understand how it's 
resolving the DLL's at the moment, we might have a clue as to why it's not 
working in SP1.

Comment 85

16 years ago
*** Bug 145844 has been marked as a duplicate of this bug. ***

Comment 86

16 years ago
Win XP SP1
I took the zlib.dll file from the Mozilla folder on my computer and then put 
it in C:\Windows\
I then downloaded Mozilla and it installed without crashing this time.
*** Bug 169273 has been marked as a duplicate of this bug. ***

Comment 88

16 years ago
Hmm, Mozilla also crashes on my WinXP with SP1. I don't have the 
SafeDLLSearchMode in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager, but 
I have a zlib.dll in the \Windows\System32 folder. This zlib.dll is part of the 
Novell Client which is installed! Renaming this dll solves the problem.

Regards,
Cornelis
*** Bug 169810 has been marked as a duplicate of this bug. ***

Comment 90

16 years ago
*** Bug 170033 has been marked as a duplicate of this bug. ***
Severity: blocker → critical
Keywords: crash
*** Bug 170104 has been marked as a duplicate of this bug. ***

Comment 92

16 years ago
*** Bug 170278 has been marked as a duplicate of this bug. ***

Comment 93

16 years ago
*** Bug 170563 has been marked as a duplicate of this bug. ***

Comment 94

16 years ago
*** Bug 168860 has been marked as a duplicate of this bug. ***
Updated the summary to cover bug 168860 symptoms since it was duped to this one.
Summary: Cannot install on WinXP SP1 (installer crashes) (due to zlib.dll) → Cannot install on WinXP SP1 (crash or -207 error due to system zlib.dll)

Comment 96

16 years ago
As I understand it, at some time Setup.exe is to blame for the problem as it
tries to open zlib.dll in Local_settings\Temp\ns_temp, and as it cannot find
zlib.dll there, it uses the system32 variant if available.
see the following output from filemon:
139
12:27:51.592
SETUP.EXE:1468
IRP_MJ_CREATE
H:\DOCUME~1\hjs\LOCALS~1\Temp\ns_temp\zlib.dll
FILE NOT FOUND	Attributes: Any Options: Open 	
140
12:27:51.592
SETUP.EXE:1468
IRP_MJ_CREATE
H:\WINXP\System32\zlib.dll
SUCCESS
Attributes: Any Options: Open 	

Comment 97

16 years ago
if you remove zlib.dll from the system32 dir what does filemon then say? because
the zlib function are used from somewhere...

Comment 98

16 years ago
As I remove zlib.dll from system32, it is searched along the following path:
H:\DOCUME~1\hjs\LOCALS~1\Temp\ns_temp\
H:\WINXP\System32\
H:\WINXP\system\zlib.dll
H:\WINXP\zlib.dll
H:\DOCUME~1\hjs\LOCALS~1\Temp\ns_temp\xpcom.ns\bin\
and finally found where it should be
See output of filemon (filtered for zlib.dll):
14:55:51.750	SETUP.EXE:3896	IRP_MJ_CREATE
H:\DOCUME~1\hjs\LOCALS~1\Temp\ns_temp\zlib.dll	FILE NOT FOUND	Attributes: Any
Options: Open 	
14:55:51.750	SETUP.EXE:3896	IRP_MJ_CREATE	H:\WINXP\System32\zlib.dll	FILE NOT
FOUND	Attributes: Any Options: Open 	
14:55:51.750	SETUP.EXE:3896	IRP_MJ_CREATE	H:\WINXP\system\zlib.dll	FILE NOT
FOUND	Attributes: Any Options: Open 	
14:55:51.750	SETUP.EXE:3896	IRP_MJ_CREATE	H:\WINXP\zlib.dll	FILE NOT FOUND
Attributes: Any Options: Open 	
14:55:51.750	SETUP.EXE:3896	IRP_MJ_CREATE
H:\DOCUME~1\hjs\LOCALS~1\Temp\ns_temp\xpcom.ns\bin\zlib.dll	SUCCESS	Attributes:
Any Options: Open 	

Comment 99

16 years ago
it's interesting how it ends up searching in:
H:\DOCUME~1\hjs\LOCALS~1\Temp\ns_temp\xpcom.ns\bin\

and anybody find this in the mozilla source where it does that?

Comment 100

16 years ago
I also checked the search order for zlib.dll on XP (without SP1) and found the
following:
C:\DOCUME~1\vivette\LOCALS~1\Temp\ns_temp\
C:\DOCUME~1\vivette\LOCALS~1\Temp\ns_temp\xpcom.ns\bin\
so obviously the difference between XP original and XP_SP1 is that the
system-paths are included in the SP1 search path, and not in pre-SP1.

this is output of filemon:
16	12:50:32.749	SETUP.EXE:992	FASTIO_QUERY_OPEN
C:\DOCUME~1\vivette\LOCALS~1\Temp\ns_temp\zlib.dll	FAILURE		
17	12:50:32.749	SETUP.EXE:992	IRP_MJ_CREATE
C:\DOCUME~1\vivette\LOCALS~1\Temp\ns_temp\zlib.dll	FILE NOT FOUND	Attributes:
Any Options: Open 	
18	12:50:32.749	SETUP.EXE:992	FASTIO_QUERY_OPEN
C:\DOCUME~1\vivette\LOCALS~1\Temp\ns_temp\zlib.dll	FAILURE		
19	12:50:32.749	SETUP.EXE:992	IRP_MJ_CREATE
C:\DOCUME~1\vivette\LOCALS~1\Temp\ns_temp\xpcom.ns\bin\zlib.dll	SUCCESS
Attributes: Any Options: Open 	

Comment 101

16 years ago
BTW: it's not only zlib.dll that can cause the problem. Try renaming zlib.dll 
in c:\windows\system32 to js3250.dll and you also get into problems. same 
error message as zlib.dll. No supprise there.
So basiclly the fix is, of cause, to first search "component.ns\bin" for 
libraries.
and perhaps make the "stup error" better.
Henk: we already know all that -- see comment 69. The DLL search order is
*exactly* what SP1 changed.
*** Bug 170788 has been marked as a duplicate of this bug. ***

Comment 104

16 years ago
I found that the same issues applied to me regarding crashing during the install
on a XP SP1 machine.  I did some looking on my system and found a zlib.dll 1.1.3
version sitting in c:\windows\system32\.  The version that Mozilla is using is
1.1.1.  I looked at the version information and it was owned by Novell, Inc.  I
did some research on the Novell support site and found that it is used for their
NDPS network printing service.  

I tried upgrading my Novell client that includes a generic (non-modified) 1.1.4
version of zlib.dll and reinstalling Mozilla 1.2a.  It crashed again at the
XPCOM portion of the install.  So the newer version didn't help.  I renamed the
zlib.dll and the install ran perfectly

Checking the zlib.org site I found that there are over 500 applications that use
zlib including Symantec for Norton AV and Microsoft for Office.  I am sure that
everyone out there doesn't have a NetWare client installed on their computer but
a lot are going to have Norton Antivirus or M$ Office.

It might help if Mozilla updated the version of zlib that they are using for the
installation.

Comment 105

16 years ago
Nominating for blackbird.
Keywords: nsbeta1
Despite the incorrect version in the rc file we are using version 1.1.4

The problem is not the source code version, it's that we're not finding our own
copy of the library created with compatible build settings.

Comment 107

16 years ago
*** Bug 170874 has been marked as a duplicate of this bug. ***

Comment 108

16 years ago
It looks (from casual inspection) like we may be calling LoadLibraryEx with the 
full path and the flag LOAD_WITH_ALTERED_SEARCH_PATH set to ensure we load the 
correct DLL.

What I think is causing the problem is how we find dependencies.  For example, 
xpinstal.dll depends upon zlib.dll.  We pick up the right xpinstal.dll (in
%temp%\ns_temp\xpcom.ns\bin\components), but the loader (LoadLibraryEx) is 
responsible for finding zlib.dll (which is in %temp%\ns_temp\xpcom.ns\bin).

Using LOAD_WITH_ALTERED_SEARCH_PATH, it will first check %temp%
\ns_temp\xpcom.ns\bin\components\ before continuing at step 2 in the search 
strategy (see comment 69).

[From MSDN]
Note that the standard file search strategy and the alternate search strategy 
differ in just one way: the standard strategy starts its search in the calling 
application's directory, and the alternate strategy starts its search in the 
directory of the executable module that LoadLibraryEx is loading.

Good idea using filemon, btw.  That confirms (I think) that the XPSP1 behaviour 
of LoadLibrary(Ex) may have moved the current directory to the end of the 
search path.  I'm not quite sure, but I think we may set the current directory 
to \ns_temp\xpcom.ns\bin\ before we load xpinstall.dll.

Either that, or we're setting the application's PATH, and W2K and XPRTM 
incorrectly check that *before* going to the system directories.  I don't see 
how we could expect the loader to find zlib.dll without doing one or the other.

[Actually, we *could* preload all the dependencies of each DLL so that they are 
all in memory when the loader goes to check, but I'm fairly sure we're not 
doing that].

One approach we could try is to use SetDllDirectory (added in XPSP1) to change 
the search path.  Any directories passed to SetDllDirectory *should* be checked 
by LoadLibrary after step 1, instead of the current working directory.

Comment 109

16 years ago
*** Bug 171182 has been marked as a duplicate of this bug. ***

Comment 110

16 years ago
I checked everything everyone mentioned above.  Removing zlib.dll from my 
\windows directory on my XP sysytem did work.

There is a quicker fix though.  Add the registry key
HKLM\System\CurrentControlSet\Control\SessionManager\SafeDllSearchMode
and set it to zero.

This also fixes the problem, and mozilla installs and breaths fire.  My guess
is after service pack 1, the key no longer defaults to zero if not there.

A short .reg file for XP owners on mozillas homepage would be a quick fix
until a new build.

"HKLM\System\CurrentControlSet\Control\SessionManager\SafeDllSearchMode is 1,
the current directory is searched after the system and Windows directories,
but before the directories in the PATH environment variable. The default value
is 0 (current directory is searched before the system and Windows
directories)."

Comment 111

16 years ago
reg fix reply to #69 Malcolm Rowe:

---save "turnoffproblem.reg"--------
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]
"SafeDllSearchMode"=dword:00000000
---endcut-------------------------

---save "turnonproblem.reg"--------
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]
"SafeDllSearchMode"=dword:00000001
---endcut-------------------------

Comment: Tests on one XP system with SP1 shows that if no
SafeDllSearchMode key is present, it defaults as if 1 is set.

Putting the first reg edit in the install before the rest of
the installation should fix the problem.  

Note: Since these problem appears in all versions of 
mozilla binary builds, the old and the new, it probably makes
more sense to put the reg fix with the downloads instead of redoing
every old build.
 
for windows

Comment 112

16 years ago
Right, so I guess that's the change that's causing all the problems we're seeing
for XPSP1.  Changing the DLL search order back to XPRTM behaviour system-wide
really isn't the right way to fix this problem (especially as I'd guess there
was a good reason for SP1 to include that change).

I'd like someone to explore using SetDllDirectory to set the search path before
we load our libraries (comment 108).  Unfortunately, MSDN is silent on what
happens to the search path if you call SetDllDirectory and have
SafeDllSearchMode set.  I don't have XP, or I'd already have looked at it.
*** Bug 171392 has been marked as a duplicate of this bug. ***
*** Bug 171386 has been marked as a duplicate of this bug. ***

Comment 115

16 years ago
"Right, so I guess that's the change that's causing all the problems we're 
seeing for XPSP1.  Changing the DLL search order back to XPRTM behaviour 
system-wide really isn't the right way to fix this problem (especially as I'd 
guess there was a good reason for SP1 to include that change)."

Not the best way, but you can always change it right back after the install.
It beats having everyone with XP and SP1 having their installs fail for the 
last three weeks without explanation.  Sortof confirming in their minds 
that 'open source isn't ready for primetime.  Besides, I've seen lots of 
companies provide such quick fixes when something like this changes until the 
permament fix is built into the package. 

I'd also bet that mozilla install isn't the only package that will have this 
problem. (Maybe someone should look around and see)   I'd like to see an 
official microsoft statement on the change warning vendors, or I'd call it a 
bug.  That quote about how the default behavior is suppose to behave I grabbed 
off a microsoft site after reading your first message.

"I'd like someone to explore using SetDllDirectory to set the search path 
before we load our libraries (comment 108).  Unfortunately, MSDN is silent on 
what happens to the search path if you call SetDllDirectory and have
SafeDllSearchMode set.  I don't have XP, or I'd already have looked at it."

This is probably the right way to change it in new builds.  We ought to 
provide a quick fix on the download page before then or a warning.

*** Bug 171431 has been marked as a duplicate of this bug. ***
*** Bug 145844 has been marked as a duplicate of this bug. ***
*** Bug 171431 has been marked as a duplicate of this bug. ***

Comment 119

16 years ago
*** Bug 172428 has been marked as a duplicate of this bug. ***
*** Bug 172644 has been marked as a duplicate of this bug. ***

Comment 121

16 years ago
OK, just to confirm this bug, I too, have SP1 installed. I tried to install
windows builds from 03-10 and 04-10, with the sea installers (10MB) they all
crashed due to that zlib.dll problem. With the net installer from 04-10, the setup  
 was trying to download more than it needed, i canceled it at 120% or more than
12000K, and i deselected debbuger and DOM in the setup. Setting the aplication
compatibility to windows 95 fixed the problem. My zlib.dll it's from Trend Micro
Inc., due to that free online virus scan (housecall), because i try to avoid
anti-virus just like the virus themselfs :)

Comment 122

16 years ago
confirm, work around to winxp sp1 bug is to run the installer in a 
compatibility mode.  I just ran 2002100508 installer in windows 2000 
compatibility mode and it worked fine.

Still would be nice for there to be a fix, as alot of people wouldn't take the 
2 seconds to figure this out.  I know its an MS problem, but mozilla and or 
netscape needs to work around it, or sue MS for yet again messing things up 
unfairly ;)

Comment 123

16 years ago
I accidently found this as I had same problem installing netscape7 on win XP 
SP1. I found 4 copies (differnt versions) of zlib.dll on my machine. I tried 
to move one in c:/windows/system32 directory but then netscape installtion 
won't even start and complain zlib.dll missing. Also have activeperl installed 
and removing file in that directory did not help. Do not the registry entry
afeDllSearchMode in the suggested path so so could not change it.

I know netscape 7 is differently packaged than molzilla but since it depends 
on it I thought it may help sombody to know it is happening there as well.

Comment 124

16 years ago
Tried with mozilla 1.2 on same system. Still same problem. Already tried 
compatibility mode win95, win2000 and it did not work. Still crashes trying to 
install xpcom
*** Bug 173007 has been marked as a duplicate of this bug. ***
*** Bug 173085 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Keywords: nsbeta1 → nsbeta1+

Comment 127

16 years ago
Re Comment #64 (and #63). Windows system files aren't always in c:\windows\,
they can be anywhere the installer tells the Win installer to put them. For
example, all by windows files are in c:\wind\, and hence the problem .DLL would
be in c:\wind\system32.

This is probably a mute point based on the registry "fix", but I thought I'd
better clarify.

Comment 128

16 years ago
Could anyone tell me the way to build the installer for windows under the new 
system?  I've downloaded and compiled mozilla many times the last weekend,
but the installer builder under xpinstall/wizard/windows uses nmake, 'no 
longer supported' according to mozilla build faqs.  

I applied several patches that I found on bugzilla from august that were 
suppose to fix the problem with the installer, but they didn't work on my 
system.

I guess my question is, how is mozilla building the installer?  I would have 
already applied a fix to the installer, but right now I can't even get it to 
compile with or without patches.

Any help would be appreciated.  When I first had the problem with the 
installer on xp, it was the first time I had tried mozilla.  So the source 
code is also new to me.

Max Kennedy


Comment 129

16 years ago
If you want to build the stub installer, do a make in
mozilla\xpinstall\wizard\windows\setup.

If you want to create the scripts and package up a new set of xpi's and such,
run mozilla\xpinstall\wizard\windows\builder\build.pl.  The results will land in
mozilla\dist\setup.
Created attachment 102321 [details] [diff] [review]
v1 fix

Here's an untested fix, I don't have an XP machine at hand at the moment. I
only guessed that there's an "A" form of SetDllDirectory, but the docs on
msdn.microsoft.com only mention the 'W' form explicitly. Will investigate
tomorrow

Comment 131

16 years ago
Yes, there is a SetDllDirectoryA in XPSP1.

Hopefully this will fix the problem, although as I mentioned in comment 112, 
there isn't actually any documentation on MSDN that describes what happens if 
you use SetDllDirectory and SafeDllSearchMode is set (as it is by default on 
XPSP1).  Guess we'll just have to wait and see.
Blocks: 168047

Comment 132

16 years ago
debugging this patch now that I have winxp sp1 installed and can duplicate.

Comment 133

16 years ago
Entry point is being found, must not like the argument (perhaps because it is 
dosified 8.3 mangled version?) Investigating.

Comment 134

16 years ago
Patch actually works fine (I just modified my debug tree here, if I leave out 
the patch, things fail as described). If I add the patch, it works. I guess 
the setup.exe build Dan gave me didn't really have the patch applied. Or 
something.

So, r=syd assuming there was no additional work (for example, SetDllDirectoryA 
returns a 0 on failure, should we be checking for that and failing the 
install? Or asserting?)
keyword soup
Keywords: adt1.0.2, mozilla1.0.2, mozilla1.2

Comment 136

16 years ago
Comment on attachment 102321 [details] [diff] [review]
v1 fix

sr=mscott
Attachment #102321 - Flags: superreview+
Attachment #102321 - Flags: review+

Comment 137

16 years ago
*** Bug 173910 has been marked as a duplicate of this bug. ***
*** Bug 173964 has been marked as a duplicate of this bug. ***
*** Bug 173966 has been marked as a duplicate of this bug. ***

Comment 140

16 years ago
Comment on attachment 102321 [details] [diff] [review]
v1 fix

a=asa for checkin to 1.2beta (on behalf of drivers)
Attachment #102321 - Flags: approval+
Checked in last night to the trunk, still waiting on drivers approval for the
branch.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago16 years ago
Keywords: adt1.0.2 → adt1.0.2+
Resolution: --- → FIXED

Comment 142

16 years ago
Just in case anyone cares, I was only able to fix the bug by changing my TEMP 
and TMP folders from the default %Username% stuff to a normal folder - probably 
cause my account containts "ö".
a=rjesup@wgate.com for 1.0 branch; change mozilla1.0.2+ to fixed1.0.2 when
checked in 
Keywords: mozilla1.0.2 → mozilla1.0.2+
Ruben: we care, but that sounds like an entirely different problem. You're on
WinXP SP1 and in prior builds setting the compatibility mode to Win98 worked for
you?

Fix checked into 1.0 branch.
Keywords: mozilla1.0.2+ → fixed1.0.2
Target Milestone: --- → mozilla1.2beta

Comment 145

16 years ago
Yes, I am aware that it's a quite different bug but as mine was marked as a 
duplicate of this one, but you closed mine :)
Anyways, I've reopened mine.

Comment 146

16 years ago
Please verify this bug on the branch and change the fixed1.0.2 keyword to
verified1.0.2. Thanks.

Comment 147

16 years ago
finally reproduced error and verified it is fixed on branch build 20021017
marking verified1.0.2
Keywords: fixed1.0.2 → verified1.0.2

Comment 148

16 years ago
verified on trunk 2002101708
Status: RESOLVED → VERIFIED

Comment 149

16 years ago
*** Bug 175570 has been marked as a duplicate of this bug. ***
*** Bug 176572 has been marked as a duplicate of this bug. ***

Comment 151

16 years ago
*** Bug 176682 has been marked as a duplicate of this bug. ***

Comment 152

15 years ago
*** Bug 176884 has been marked as a duplicate of this bug. ***

Comment 153

15 years ago
*** Bug 177188 has been marked as a duplicate of this bug. ***
*** Bug 177411 has been marked as a duplicate of this bug. ***

Comment 155

15 years ago
*** Bug 179884 has been marked as a duplicate of this bug. ***

Comment 156

15 years ago
*** Bug 175570 has been marked as a duplicate of this bug. ***
*** Bug 181175 has been marked as a duplicate of this bug. ***
*** Bug 181694 has been marked as a duplicate of this bug. ***

Comment 159

15 years ago
*** Bug 182046 has been marked as a duplicate of this bug. ***

Comment 160

15 years ago
*** Bug 182801 has been marked as a duplicate of this bug. ***

Comment 161

15 years ago
*** Bug 173964 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.