Closed
Bug 191285
Opened 22 years ago
Closed 22 years ago
procedure entry point NSS_CMSMessage_IsSigned could not be located in smime3.dll
Categories
(MailNews Core :: Security: S/MIME, defect)
Tracking
(Not tracked)
VERIFIED
WORKSFORME
People
(Reporter: williamsca, Assigned: ssaux)
Details
(Keywords: stackwanted)
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
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•22 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
Do you have addons in your mozilla user-profile's chrome directory?
Keywords: stackwanted
Reporter | ||
Comment 4•22 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.
Comment 5•22 years ago
|
||
smime is mailnews
Assignee: asa → ducarroz
Component: Browser-General → MIME
Product: Browser → MailNews
QA Contact: asa → stephend
Comment 6•22 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•22 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•22 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•22 years ago
|
||
Weird. Setting to WORKSFORME based on reporters comment. Thanks.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Comment 10•22 years ago
|
||
Verified - cannot reproduce on 20030131 builds
Status: RESOLVED → VERIFIED
Comment 11•21 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•21 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•21 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•21 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•21 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•21 years ago
|
||
The file is there and has a version number of 3.3.2.
Comment 17•21 years ago
|
||
I have the file as well, version 3.3.1.0.
Comment 18•21 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•21 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•21 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•21 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•21 years ago
|
||
I have Netscape Directory Server installed as well. That is [probably] where those files in system32 came from.
Comment 23•21 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.
You need to log in
before you can comment on or make changes to this bug.
Description
•