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

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.

try finding the install log file for mozilla. it's in the mozilla.org/mozilla directory. attach it to this bug report.

Comment on attachment 98456 [details] install_wizard.txt it crashed before it started logging anything, very early in the process.

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!

Confirming seeing it's been duped

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.

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?

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

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

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.

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?

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.

Comment on attachment 99274 [details] zlib.dll which causes problems Tom, sorry - the file is corrupted.

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"

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

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

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.

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

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.

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.

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

Comment on attachment 102321 [details] [diff] [review] v1 fix sr=mscott

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

Checked in last night to the trunk, still waiting on drivers approval for the branch.

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

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.

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

verified on trunk 2002101708

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