Closed Bug 167515 Opened 22 years ago Closed 22 years ago

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

Categories

(SeaMonkey :: Installer, defect)

Product:
SeaMonkey
Component:
Installer
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.2beta

People

(Reporter: zevious, Assigned: dveditz)

References

Details

(Keywords: crash)

Attachments

(7 files, 1 obsolete file)

install_wizard.txt
1.78 KB, text/plain
Details
install_status.log
3.31 KB, text/plain
Details
Attachments as asked for...
17.55 KB, application/x-zip-compressed
Details
The Error Report Log
19.21 KB, text/plain
Details
From "DR. Watson"
13.56 KB, text/plain
Details
Empty DLL to use to check DLL search path
40.00 KB, application/octet-stream
Details
v1 fix
1.66 KB, patch
dveditz
: review+
mscott
: superreview+
asa
: approval+
Details | Diff | Splinter Review 
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
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
Closed: 22 years ago
Resolution: --- → WORKSFORME
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 → ---
try finding the install log file for mozilla. it's in the mozilla.org/mozilla
directory. attach it to this bug report.
Attached file install_wizard.txt — 

    
    

    
  

      
      
      
      

        Attached file
          
        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

    
    

    
  
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.

    
    

    
  
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..

    
    

    
  
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...

    
    

    
  
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..

    
    

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

Glad it wasn't just me..

    
    

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

    
    

    
  


  
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!

    
  

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

    
    

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

    
    

    
  
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.

    
    

    
  

      
      
      
      

        Attached file
          
        The Error Report Log
        — 
      

    


  
Here's a copy of my error report log.

    
    

    
  
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?)

    
    

    
  
crashing users:

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

    
    

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

    
    

    
  
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.

    
    

    
  
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

    
    

    
  
crashed again.

    
    

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

    
    

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

    
    

    
  
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)

    
    

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

    
    

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

    
    

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

    
    

    
  
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.

    
    

    
  
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).

    
    

    
  
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!

    
    

    
  
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

    
    

    
  
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. ***

    
    

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

    
    

    
  
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

    
    

    
  
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 ?

    
    

    
  
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.

    
    

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

    
    

    
  
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>

    
    

    
  
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.

    
    

    
  
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)"

    
    

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

    
    

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

    
    

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

    
    

    
  
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.

    
    

    
  
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?..

    
    

    
  
How do I change application compatiblity?

    
    

    
  
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 ;-)

    
    

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

    
    

    
  
Compatibility mode for Windows 98/Windows ME also works.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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?

    
    

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

    
    

    
  
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.

    
    

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

    
    

    
  

      
      
      
      

        Attached file
          
        zlib.dll which causes problems (obsolete)
        — 
      

    


  

    
    

    
  
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).

    
    

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

    
    

    
  
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)

    
    

    
  
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$

    
    

    
  
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

    
    

    
  
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 ?)

    
    

    
  
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.

    
    

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

    
    

    
  
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)

    
    

    
  
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).


    
    

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

    
  
Blocks: 1.2b

    
    

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

Tom, sorry - the file is corrupted.

        Attachment #99274 -
        Attachment is obsolete: true

    
    

    
  
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.

    
    

    
  
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"..

    
    

    
  
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?

    
    

    
  
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"

    
    

    
  

      
      
      
      

        Attached file
          
        From "DR. Watson"
        — 
      

    


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

    
    

    
  
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?

    
    

    
  


  
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.

    
    

    
  
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".

    
    

    
  
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

    
    

    
  
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.

    
    

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

    
    

    
  
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. ***

    
    

    
  
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. ***

    
    

    
  
*** 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. ***

    
    

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

    
    

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

    
    

    
  
*** 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)

    
    

    
  
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 	

    
    

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

    
    

    
  
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 	


    
    

    
  
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?

    
    

    
  
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 	

    
    

    
  
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. ***

    
    

    
  
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.

    
    

    
  
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.

    
    

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

    
    

    
  
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.

    
    

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

    
    

    
  
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)."


    
    

    
  
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

    
    

    
  
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. ***

    
    

    
  
"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. ***

    
    

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

    
    

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

    
    

    
  
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 :)

    
    

    
  
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 ;)

    
    

    
  
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.

    
    

    
  
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. ***

    
  
Keywords: nsbeta1 → nsbeta1+

    
    

    
  
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.

    
    

    
  
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




    
    

    
  
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.


    
    

    
  

      
      
      
      

        Attached patch
          
          
        v1 fix
        — 
          — Splinter Review
      

    


  
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

    
    

    
  
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: blackbird

    
    

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

    
    

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

    
    

    
  
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 on attachment 102321 [details] [diff] [review]
v1 fix

sr=mscott

        Attachment #102321 -
        Flags: superreview+

    
  

        Attachment #102321 -
        Flags: review+

    
    

    
  
*** 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 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
Closed: 22 years ago → 22 years ago
Keywords: adt1.0.2 → adt1.0.2+
Resolution: --- → FIXED

    
    

    
  
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

    
    

    
  
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.

    
    

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

    
    

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

    
    

    
  
verified on trunk 2002101708
Status: RESOLVED → VERIFIED

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
*** 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. ***

    
    

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

    
    

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

    
    

    
  
*** 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.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: