37792 - Entry Point Not Found in XPCOM.DLL when starting browser first time

Status: VERIFIED DUPLICATE of bug 37125

(Core :: XPCOM, defect, P3)

Description

[Todd Shelley]

"mozilla.exe - Entry Point Not Found"

"The procedure entry point ?Compare@nsString@@UBEHABV1@HH@Z could not be located
in the dynamic link library xpcom.dll."

Comment 1

[Asa Dotzler [:asa]]

[e-mail], please refer to the Bug Writing Guidelines to see the 
kind of information we need to get this bug assigned properly.  You can find the 
guidelines linked to at http://mozilla.org/quality/help .  Also consider using 
the Bugzilla Helper to report future bugs.  It is also linked to from the /help 
page.  Most importantly for a crasher bug like this is what build you tested.  
It would also be helpful to know if you had previous builds installed and if you 
deleteds those and related files before trying your current build.  Thanks for 
your help in testing Mozilla and reporting bugs.

Comment 2

[Sean Richardson]

The reporter's comment is the verbatim content of the title and body of an
alert window that I've seen coming up the first time and only the first time 
lauching a freshly unzipped nightly binary for the last week or so. This alert
has a white "x" over a red circle, and an [Ok] button; after clicking on it,
Mozilla continues to load and appears to work properly. No crash.

I unzip each browser build into directories like 
G:\mozilla\2000-05-01-11-M16.talkback\ -- removing mozregistry.dat has no 
effect on reproducing this alert, only unzipping into a new directory.

Asa, you've never seen this alert?

Passing to XPCOM component, although this might also be a packaging issue.

Comment 3

[Suresh Duddi (gone)]

We have got a large number of these bugs and all of them turned out to be 
unzipping a new fresh install onto an existing directory. That leaves some 
stale dlls from the previous install. First time, we try to load it fails. We 
mark it as bad dll and never attempt to load it from next time on.

Can you check this theory. Try unzip onto a new directory and running. If you 
still get the error, the theory is flawed and reopen the bug.

Comment 4

[Sean Richardson]

REOPENing. After controlling for the issues brought up by [e-mail]
and a few more, this alert still showed up.

To test this, I:
1. Started with an NT box that hasn't been used to run a Mozilla binary
   in a month, and on which the Entry Point alert has never been seen.
2. Removed the mozregistry.dat file.
3. Downloaded today's nightly binary and unzipped it into a fresh directory
   (G:\2000-05-02-09-M16.talkback\) that was not a subdirectory of the 
   directory where directories for previous nightlies have been created.
4. Renamed the latter directory (G:\mozilla -> G:\mozill) to ensure .dlls there
   could not be called.
5. Rebooted the NT box to make sure a old .dll was not still in memory.
6. Started Mozilla.

The alert appeared over the splash image.  With those controls, it appears that
the code calling the unfound entry point must be in the current package. 

Comment 5

[Suresh Duddi (gone)]

Thanks for the test. Ray ? 

Comment 6

[Ray Whitmer]

I cannot duplicate the bug.  I tried with today's build, then with both 
mentioned in this bug report, using the exact directory names (except drive) and 
eliminating old directories and rebooting between tests, as described.  I was 
unable to reproduce the problem.

How did you invoke mozilla in these tests?  I opened a DOS shell, went to the 
drive and the bin subdirectory of the unzipped directory, and executed 
"mozilla".  Is it possible you are not exactly invoking what you think you are?

Comment 7

[Chris Hubick]

I experience exactly this.  Using build 2000050513 on Win2K.

I also filed bug 38336 which occurrs immediately after, and on subsequent 
launches. I don't know if they are related.  That bug has a regmon log 
(http://bugzilla.mozilla.org/showattachment.cgi?attach_id=8378) of my launch 
which may help isolate this bug.

Comment 8

[John Morrison]

I believe that this is a duplicate of bug #37125. The deal here is that the 
*-talkback.zip builds available on mozilla.org are packaged with an obsolete 
DLL. Hence, the link error -- we are setting ourselves up for failure.

To verify, delete the file 'ender.dll' in components after re-installing a build 
that is known to exhibit this problem -- should be no more alert|dump()

*** This bug has been marked as a duplicate of 37125 ***

Comment 9

[Sean Richardson]

So this *was* a packaging problem. VERIFYing after testing with 
the mozilla-win32-talkback.zip build at 
ftp://ftp.mozilla.org/pub/mozilla/nightly/2000-05-07-16-M16/ --
After unzipping it into two distinct directories and removing ender.dll from 
one before running, the results were exactly as John predicted: no alert if no
ender.dll.

Comment 10

[John Noonan]

marking verified/duplicate