Closed Bug 191874 Opened 22 years ago Closed 19 years ago

Personal Security Manager does not install on NT

Categories

(SeaMonkey :: Installer, defect)

x86
Windows NT
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED EXPIRED

People

(Reporter: williamsca, Assigned: KaiE)

Details

Attachments

(5 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3b) Gecko/20030203
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3b) Gecko/20030203

The latest nightly builds (since at least last Friday for sure) do not install
the Personal Security Manager.  Whenever I try to access a page using https, a
Windows dialogue pops up telling me Personal Security Manager is not installed
and to download it or contact my System Administrator.  I can't find it anywhere
on the Mozilla site to download, so what I have been doing is to download the
mozilla-win32.zip file from the nightly build and grab the files out of it.

A custom install does not show PSM as an option to check or uncheck.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
PSM is no longer a stand-alone or optional component.  It is now part of "GRE"
which, briefly, was a component you could check.  In the latest builds you will
see neither PSM nor GRE - they will be automatically installed.

I don't see any problem with secure sites.  (2003020308 / XP).

Have you tried a completely clean install and/or new profile?
I also don't see a problem on my Win2K machine at home, but I definitely have
issues under NT 4.0 at the office location.

Just to confirm, yes, I just now ran the uninstall of Mozilla, removed the
mozilla.org directory and performed a re-install of last night's build and the
problem still exists.  I ran profile manager to create a new profile and the
problem exists there.

Are there other things that I should try manually removing after an uninstall,
i.e. registry entries or something?  I also notice that there are
install_status.log and install_wizard.log in the GRE directory.  Should I attach
those here?  I can also provide screen shots of directories if that would be
helpful to show what files were actually installed.
QA Contact: ktrina → gbush
Actually I also had this problem when I was on a NT machine some time ago..
Cannot confirm anymore though, on windows 2000 now.
I tried this on NT machine - build 2003020408 and cannot reproduce.
please attach logs-
I downloaded last night's build, 2003020408, and it installed and there are no
complaints about PSM not being installed.  So, I guess, as of this morning's
build, it seems to work for me also.
I see the same problem on a totally different system, namely OpenVMS/Alpha 7.3
(no PC stuff) using Mozilla 1.3A. The message I get is:

This document cannot be displayed unless you install the personal security
manager (PSM). Download
and install PSM and try again, or contact your system manager.

This problem started today (2003-02-14), yesterday everything was fine. No changes 
of the installed software or my personal preferences. I first noticed this when I
tried to access my credit card account online. The bank keeps playing with stuff
like flash and other nonsense, so I thought it is their fault and they may need
some new feature (never noticed PSM before). So I installed Mozilla 1.3B. Same
problem.

Later I tried a test account and things were working. Therefore I ditched my
personal preferences. Mozilla created everything from scratch for my account.
After setting a few options the PSM message popped up again and I cannot access
any web page through SSL.
(OpenVMS specific part)
It seems that I ran out of P1 address space. That would explain why Mozilla
stopped working without any change of my Mozilla setup. Increasing CTLPAGES
fixed the problem for me. This information may be useful for someone else.

(General)
Perhaps the PSM problem shows up if something else goes south during Mozilla's
initialization (start). Mozilla's error handling is not exactly great. Errors
are often simply ignored.
It seems that this problem is back with the builds from the last two nights,
2003031208 and 2003031308.  I notice there are files in c:\program files\common
files\mozilla.org that are not in the regular mozilla.org\mozilla directory.  In
fact, if I copy the smime3.dll file out of common files and into the mozilla
directory, the PSM error message goes away and all seems to be happy.  Maybe the
install on NT is not properly copying files into the correct location?  I'm
attaching screen shots of both directories immediately following installation.
Turns out I had to copy a few more files in to get things working:

ssl3.dll
nss3.dll
js3250.dll
jsj3250.dll
This does not sound like an installer bug due to comment #8:

 "In fact, if I copy the smime3.dll file out of common files[\mozilla.org\GRE]
and into the mozilla directory, the PSM error message goes away and all seems to
be happy."

adding more people to the Cc: list. who might know what's going on.
Just a short note to say that this is still happening with all of the nightly
builds up to and including last night's build.  Each day I remove the previous
build, delete the mozilla.org directory, then install the new build.  After the
build I have to copy in nss3.dll, smime3.dll, ssl3.dll, and .autoreg (out of the
c:\program files\common files\mozilla.org\gre\1.4a_* location) to get the PSM
stuff to work.  I am not having this problem at home with the nightly builds on
Win2K.  Perhaps this is an NT only problem?
An update...  Still having the same problem with the 2003032611 build.
This is still happening with all of the builds from this week.

If I'm the only one having this problem, is there some debugging that can be
turned on during install or after that can help figure out why I am having this
problem?
as far as I'm aware, the files you are hand copying are being installed in the
correct place.  It might just be an NT4 thing.

kaie@netscape.com might know what's going on.
Assignee: dveditz → kaie
this bug might be related to bug 199162
Curtis, are you able to install cygwin and work with a UNIX type command line?
If you can, it might be helpful to see how your Mozilla directory looks after
the installation. We could compare that with the output of a directory on a
Windows 2000 machine.

Alternatively, we could provide a listing of how the directories could look like.

Assuming everything gets installed into a single directory, one could start the
cygwin command line, use "cd" to go to the Mozilla install dir, and run this
command:

  find . -type f | xargs ls -l
I will be attaching a file called mozilla.lst which contains the info you asked.

I removed Mozilla via the Control Panel.  I then removed the mozilla.org
directory.  I ran the setup from last night's nightly build.  After the install
was complete, Mozilla started on its own.  I executed the requested find
command, so the output from that command should be accurate without having my
hand-copied files.
Sean, now that that we see this output, I suspect an installer problem. Files
pipnss.dll and pipboot.dll are not installed.
right.  the list is only for the mozilla dir.  I found my copy of pipnss.dll and
pipboot.dll in the GRE dir:
  c:\Program Files\Common Files\mozilla.org\GRE\1.4b_2003040708\components

Curtis, can you look for the GRE directory and provide a similar listing outupt?
 The GRE dir should be in a Common Files dir within a mozilla.org subdir.  If
there isn't one can you do a search for the files on your entire hard drive?
mozillacommon.lst is attached.

cygwin doesn't seem to be able to deal with the space in the "Setup GRE"
directory.  I got the following back from the command:

ls: ./GRE/1.4b_2003040808/Setup: No such file or directory
ls: GRE/config.ini: No such file or directory
ls: ./GRE/1.4b_2003040808/Setup: No such file or directory
ls: GRE/gre.xpi: No such file or directory
ls: ./GRE/1.4b_2003040808/Setup: No such file or directory
ls: GRE/greuninstall.zip: No such file or directory
ls: ./GRE/1.4b_2003040808/Setup: No such file or directory
ls: GRE/install.ini: No such file or directory
ls: ./GRE/1.4b_2003040808/Setup: No such file or directory
ls: GRE/license.txt: No such file or directory
ls: ./GRE/1.4b_2003040808/Setup: No such file or directory
ls: GRE/SETUP.EXE: No such file or directory
ls: ./GRE/1.4b_2003040808/Setup: No such file or directory
ls: GRE/setuprsc.dll: No such file or directory
ls: ./GRE/1.4b_2003040808/Setup: No such file or directory
ls: GRE/xpcom.xpi: No such file or directory
Ok, I forgot about GRE being installed into a separate directory.


Doug, it seems that PSM files are correctly installed on this user's system, but
still, the following code in nsSocketProviderService::GetSocketProvider does not
seem to find the socket providers that come with PSM:

  nsCAutoString contractID(
          nsDependentCString(NS_NETWORK_SOCKET_CONTRACTID_PREFIX) +
          nsDependentCString(aSocketType));

This is the only place in the code that produces error
NS_ERROR_UNKNOWN_SOCKET_TYPE, which triggers the error message reported in this bug.

Is it possible that some registry creation is broken on Windows NT 4?
Curtis, could you attach the generated ...\Mozilla\components\*.dat files to
this bug?  That might help reveal if there are registration issues.
Attached file compreg and xpti dat files (obsolete) —
Attachment #120037 - Attachment is obsolete: true
I'm not an export on interpreting the .dat files, but from looking at
compreg.dat, it looks like your pipboot.dll is in both the mozilla component's
dir and gre component's dir.  it should only be in the gre component's dir.

Can you make sure:
* mozilla is not running
* pipboot.dll is only in the gre component's dir
* delete mozilla\component\compreg.dat
* create a file (empty or not) mozilla\.autoreg
* start mozilla.exe again

see if that helps.
I checked the mozilla\components directory and did not see a pipboot.dll there.
 I *think* I may have copied that in there yesterday as a test to see if it
made any difference, so when I installed last night's build this morning it
would have removed that file.

So, I closed mozilla, checked for pipboot.dll and did not find it, deleted
compreg.dat, deleted nss3.dll, smime3.dll, ssl3.dll from the mozilla directory,
created .autoreg, started mozilla, exited mozilla and then started mozilla.  No
change.  Still tells me PSM is not installed.

I am attaching new compreg.dat and xpti.dat.
Please note possibly related bug 191285.
logs from dependency walker
<http://www.mozilla.org/quality/help/dependency-walker.html>
and regmon <http://www.sysinternals.com> would be helpful.
Product: Browser → Seamonkey
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
Component: Installer: XPI Packages → Installer
QA Contact: agracebush → general
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: