procedure entry point NSS_CMSMessage_IsSigned could not be located in smime3.dll

VERIFIED WORKSFORME

Status

--
critical
VERIFIED WORKSFORME
16 years ago
10 years ago

People

(Reporter: williamsca, Assigned: ssaux)

Tracking

({stackwanted})

Other Branch
x86
Windows NT
stackwanted

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a) Gecko/20021212
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a) Gecko/20021212

All of the nightly builds have been having this problem this week.  It may have
started last week, but I had other Mozilla problems prior to getting to this one.

Any previous version of Mozilla is removed with whatever remaining directoeies
being deleted, the latest nightly build is installed, Mozilla starts, and the
following error is generated:

OleMainThreadWndName: mozilla.exe
The procedure entry point NSS_CMSMessage_IsSigned could not be located in the
dynamic link library smime3.dll.


When I click OK from the error, I then get the following:

The instruction at "0x612113b9" referenced memory at "0x0000000c". The memory
could not be "written".

When I click OK from that, Mozilla closes.  Talkback IDs are generated, but I
don't have their numbers due to having to remove Mozilla and put 1.3a back on so
that I could have a working browser.  There should be several under
williamsca@process.com from this morning's attempt.

Reproducible: Always

Steps to Reproduce:
1. Install latest nightly build
2. Click on Mozilla icon
3. See the crash

Comment 1

16 years ago
Did you install according to the installation notes?

Missing entry points indicate outdated installations. Make sure that eventual
installer files are downloaded/unpack to an empty dir. Also make sure to
uninstall and delete at least the "components" and "chrome" directories before
installing a new build. 
(Reporter)

Comment 2

16 years ago
Yes, as was indicated in my original problem posting, Mozilla was completely
removed, including any remaining directories, starting from mozilla.org and down
and then the nightly build installed.  If there is anything else that should be
removed, like registry entries, or files in other directories like WINNT (I did
remove mozver.dat), please let me know and I'll give it a shot.  I've been doing
this same uninstall/install procedure for months as I install each new nightly
build and have not had any problems until last week's changes with the GRE
stuff.  Since then, I have not been able to use any of the nightly builds and
have always had to go back to 1.3a.

I went ahead and did it again, mostly to grab a talkback ID:  TB16755050Y

Comment 3

16 years ago
Do you have addons in your mozilla user-profile's chrome directory?
Keywords: stackwanted
(Reporter)

Comment 4

16 years ago
Yes, there were additional things in the chrome directory from themes I had
tried in earlier versions and didn't like (I now use "modern" exclusively), so
here's what I tried:

I closed 1.3a version of Mozilla, deleted the chrome directory in the user's
location, and restarted 1.3a, allowing Mozilla to recreate the chrome directory
and put back the needed files.

I then removed 1.3a, deleted mozilla.org directory, installed last night's build
and got the same procedure entry point error followed by Mozilla crash.
smime is mailnews
Assignee: asa → ducarroz
Component: Browser-General → MIME
Product: Browser → MailNews
QA Contact: asa → stephend

Comment 6

16 years ago
Thanks for submitting the talkback info.
It shows you are crashing in

nsZipArchive::ReadInit
[c:/builds/seamonkey/mozilla/modules/libjar/nsZipArchive.cpp, line 604]
nsJARInputStream::Init
[c:/builds/seamonkey/mozilla/modules/libjar/nsJARInputStream.cpp, line 108]
nsJAR::GetInputStream [c:/builds/seamonkey/mozilla/modules/libjar/nsJAR.cpp,
line 346]
nsJARInputThunk::EnsureJarStream
[c:/builds/seamonkey/mozilla/netwerk/protocol/jar/src/nsJARChannel.cpp, line 105]
n

This looks like the recent crash bug 190460 that has been fixed today.

Could you please test again using tomorrow's build?

Comment 7

16 years ago
over to s/mime

While my previous comment addresses the crash, we of course need to look into
the procedure entry point message, too.

Charles, can you reproduce the problem, when having installed a recent Windows
build using the installer?
Assignee: ducarroz → ssaux
Component: MIME → S/MIME
Product: MailNews → PSM
QA Contact: stephend → carosendahl
Version: Trunk → unspecified
(Reporter)

Comment 8

16 years ago
Installed last night's build and still got the procedure entry point error when
Mozilla started itself as part of the install.  The crash has gone away!  YEAH!
 The interesting thing is that I exited the browser and started it again and the
procedure entry point error has gone away, too.  Go figure!

Comment 9

16 years ago
Weird. Setting to WORKSFORME based on reporters comment. Thanks.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 10

16 years ago
Verified - cannot reproduce on 20030131 builds
Status: RESOLVED → VERIFIED

Comment 11

16 years ago
I am getting this same error after installing today's trunk build (15 April
2003), but Mozilla starts correctly, PSM is not enabled. What information can I
add to the bug?
(Reporter)

Comment 12

16 years ago
Hi Peter:

I too am still getting this error, despite being the original reporter and
having this marked VERIFIED WORKSFORME based on my earlier feedback.

I am working what I think is a larger issue in bug 191874 which I *think* is
related to this one and is currently being worked on.  You might want to check
out that bug and try copying nss3.dll, smime3.dll, ssl3.dll, and .autoreg out of
the Common Files location into the Mozilla install location.  This should be a
workaround for what you are seeing.

Comment 13

16 years ago
Try the following:
- delete your mozilla bin directory completely
- reinstall mozilla

see if this cleans things up.  if not, try deleting the secmod.db file from your
profile directory.

Comment 14

16 years ago
Charles -

I had already tried all except removing secmod.db prior to posting, but
unfortunately your suggestions did not work. 

Curtis -

I had suspected an installer problem but hadn't found your bug. I am on W2K SP3,
so it does not appear to be an NT bug, I'll add my comments over there. Looks
like this bug may or may not be related, unfortunately as I said, I'm not sure
what information to add, nothing interesting shows up on the -console.

Cheers
Peter

Comment 15

16 years ago
Please look for smime3.dll in your Windows "system32"
directory, which is C:\WINDOWS\system32 or C:\WINNT\system32.

If you find it, could you look at the "Properties" of
that file?  Right mouse over the file and choose "Properties"
in the drop-down menu.  Then select the "Version" tab and
look at "Product Version".  I bet the version number is
smaller than 3.4.
(Reporter)

Comment 16

16 years ago
The file is there and has a version number of 3.3.2.

Comment 17

16 years ago
I have the file as well, version 3.3.1.0.

Comment 18

16 years ago
Thank you. With the information you provided, I
concluded that this bug is caused by bug 202326.
We probably should resolve this bug as a duplicate
of bug 202326.
(Reporter)

Comment 19

16 years ago
Fine with me.  But is there a workaround?  Can I safely delete the one in the
system location, or will that cause the NS Directory Server to break?  I'm
guessing it will.  I'm really getting tired of copying files for every nightly
build that I load onto my system.

Comment 20

16 years ago
The safest workaround is to copy the following NSS
DLLs from the GRE directory to the directory where
mozilla.exe resides:
nss3.dll
softokn3.dll
smime3.dll
ssl3.dll
(Reporter)

Comment 21

16 years ago
I've been doing that every morning for over a month.  It's really getting quite
tiresome.  Bug 191874 is another bug I've opened that's probably also related to
this.

Comment 22

16 years ago
I have Netscape Directory Server installed as well. That is [probably] where
those files in system32 came from.

Comment 23

16 years ago
I understand copying the NSS DLLs every day is
tiresome and I want to thank you for testing
the Mozilla daily build every morning.

The reason I cannot recommend the alternate
workaround is that it is less safe.  I need
to first point out its problems.

1. You need to be sure that Netscape Directory
Server is the only product that puts the NSS
DLLs in the system directory.
2. You need to remember to undo the change
when you uninstall or upgrade Netscape Directory
Server in the future.  This is what worries me
most.  Are you sure you will remember to do this?

If you are sure that you are fine with the above
two problems, here are the steps:
1. Save a copy of the following NSS DLLs in the
system directory:
    nss3.dll
    smime3.dll
    ssl3.dll
Note that NSS 3.3.x does not have softokn3.dll,
so there should be no softokn3.dll in the system
directory.
2. Stop Netscape Directory Server.
3. Copy nss3.dll, smime3.dll, and ssl3.dll to
the directory (or directories) where the Netscape
Directory Server executables (.exe's) reside.
4. Restart Netscape Directory Server.

Updated

14 years ago
Component: Security: S/MIME → Security: S/MIME
Product: PSM → Core

Updated

10 years ago
Component: Security: S/MIME → Security: S/MIME
Product: Core → MailNews Core
QA Contact: carosendahl → s.mime
You need to log in before you can comment on or make changes to this bug.