From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.9) Gecko/20010305 BuildID: 2001030505 NSPR:EventReceiver:mozilla.exe - Entry point not found The procedure entry point ?Recycle@nsString@@SAXPAV1@@Z could not be located on the dynamic link library xpcom.dll This occurs every time I start Mozilla. I can 'ok' through this and mozilla then starts fine. Reproducible: Always Steps to Reproduce: start mozilla by clicking on the quickstart icon

Sounds like bug 60791 reassigning to profile manager

Sure doesn't sound like profile mgr to me. Back to XPCOM - for lack of a better place.

It appears that my bug report (Bug ID# 75702) is a duplicate of this one, though with a slight difference ... I only see the "entry point not found" error on first run of an installation and do not see it if running from a non-Installer build even on first run. Dale

*** Bug 75702 has been marked as a duplicate of this bug. ***

I am running Mozilla Build ID: 2001041704 on WinNT 4 w/ SP5. I am now encountering the Entry Point Not Found error report when I am in Bugzilla and I enter a bug ID to find. The title (as in earlier reports here and in Bug ID 75702) identifies Mozilla.exe, but the specific error message in this case mentions a different entry point in xpcom.dll: "Entry point ??0nsInputFileStream@@QAE@ABV0@@Z could not be located in dynamic link library xpcom.dll." As in the other cases, dismissing the error dialog lets Mozilla continue (apparently) with what was requested. Dale

More on the Entry Point Not Found bug when interacting with Bugzilla forms: Other form controls, buttons etc., in Bugzilla also trigger the Entry Point Not Found in xpcom.dll errors. I don't know if all do, but the Commit and Login buttons do, however the Reset button does not trigger the error. Dale

I've been getting the Entry Point not found on startup with the past couple of nighlty builds, but the entry point is: ??0nsInputFileStream@@QAE@ABV0@@Z also in xpcom.dll I'm running an NT 4 box

This is the error I get: NSPR:EventReceiver: mozilla.exe - Entry Point Not Found The procedure entry point ??0nsInputFileStream@@QAE@ABV0@@Z could not be located in the dynamic link library xpcom.dll But I get it only the first time start Mozilla after I unzip a new build. I've noticed this with the last few nightly builds on Windows 2000.

Confirming. I see this too. Nominating for mozilla 0.9. Can't do a milestone build with these warning dialogs.

*** Bug 76045 has been marked as a duplicate of this bug. ***

I'll bet this is related to the code ordering stuff. An entry point named by code-ordering files, but no longer exists? A symbol that looks like an out-of-lined |inline| function? Then it complains at load time? Perhaps because the function is no longer out-of-lined? dprice can probably fix this in 30 seconds or less.

Please also look at the form submission symptom in bug 76045, if only to make sure it's really a dup.

I guess that I don't fully understand the problem. Are you saying that when the linker re-orders the functions in xpcom.dll it is picking up some inline functions and moving them to a place where they are no longer inline? If that's the case we'd have to tweak trace.dll to ignore inline functions. We are currently skipping over any function with a displacement greater than 0. When the linker finds a function in the order files that is not in the .obj files, it throws a warning and ignores it. I don't see this on Windows 2000 when I run a build from yesterday. Is it an NT 4 only problem? CCing waterson and jband, they may have better insights.

as of the 4/19 nightly (bld 2001041804) on an NT 4.0 system, the error message only appears on the first run of the program after I unzip the DL,

I have a Dell Inspiron with Windows 2000 and I see it when submitting forms. I am running the 4/19 build

report from one user shows When I run Netscape 6.5 I always get the following error: Procedure entry point ?Recycle@NString@@SAXPAV1@@Z could not be located in dynamic link library xpxom.dll 2001042304 I also seen this error msg from previous builds. putting this on 0.9.1

0.9.1? Ugh. I get this error every time I submit a form. Isn't there something we can do for 0.9?

I used to get: (title)NSPR:EventReceiver: mozilla.exe - Entry Point Not Found (dialog contents)The procedure entry point ??OnsInputFileStream@@QAE@ABV0@@Z could not be located in the dynamic link library xpcom.dll. [OK] on starting every nightly build right after unzipping it (no other times; it went away after the first start). After removing the d:\moreapps\moz-nightly directory tree and unzipping into it afresh back into there, the dialogs stopped. I haven't seen it since. Anyone else want to verify that this is what caused it to go away? [NT4, SP6a+] Since it's a really annoying bug, should we bump it up a couple of severity levels? I didn't want to do this since I'm fairly new.

Yes, I just confirmed this on Win2000. I've been unzipping the nightlies to the same folder as previous builds (milestones etc.) and experiencing the popups after each unzip. I deleted the entire directory structure and unzipped again into a fresh folder with no popups on startup this time.

Isn't this just due to bad depend builds, or random libraries remaining in the install directory that are being picked up by the component loader? I've never seen this with installer installed builds.

I believe this does happen with installer builds. I've gotten one report via email from an AOL employee who ran into this problem with our installed builds. This person probably has never had any debug builds on his system.

Same prob on the installer builds. I only use the installer builds, installing over the previous nights installation everyday. Get the exact same pop up error as the non-installer builds. Also I would like to note that I do not get this error on launching mozilla, either from the start menu / quickstart icon / or desktop... I only get this error when I attempt to submit information to a form. Finally, can we jack the severity up to normal and mozilla .9 .... this is probably the most annoying bug and showstopper I have ever seen in 1 year of using Mozilla with w2k.

Re: IS it in Installer builds? YES ... I have seen it in every installer build for a long time ... in fact as of today's experience, I'd say it's been there since the Installer builds on WinNT 4 have stopped asking if I want to delete the existing directory. Today, like ususal, I did an installer build over the existing directory and when the program went into its "first run" the unfound entry point error dialog appeared. I cancelled the run, deleted the existing Mozilla directory from the path "C:\Program Files\Mozilla.org\Mozilla" and reinstalled. On this "first run" there was NO error dialog. I have never seen this on a non-installer build because I have always manually deleted the existing directory, if there was one. I have also never seen it on a Mac build because the Mac installer still asks if you want to delete the existing directory and does it, like the WinXX installers used to do. Bring back the delete and the problem may be solved. Dale

I don't know about the rest of you, but I'd really like to know what causes it. So we know that the symptoms go away after a delete and re-install. Is it a gronky lib that got introduced several builds back and was never overwritten? Or maybe it's no longer necessary, but the dependency is in there, notwithstanding?

I am sorry, my "solved" was incorrect ... I should have said "side stepped". I agree, the problem should actually be solved by determing what's causing it and fixing that so it doesn't come back to bite again. I am also happy to report that I just downloaded build 2001043004 and did another on-top-of-existing-installation install. This time I got no error dialog on the first run. I don't know if my deleting the previous directory cleaned up something that had hung around a long time or if something was done in the installer version for this build, but for now it's looking clearer than it has in a long time. Dale

dveditz: Is the installer expected to remove all DLLs when installing over an installation? What about old plugins that may be registered as components? Do you see a way for this error to be coming up due to 'leftover' DLLs? At this point it looks to me like we have no evidence to say whether this problem is likely to be an installer sort of problem - that we can understand and deal with - OR if this is order-file related voodoo that we *must* figure out through experimentation and research. This is not an area where we want to accept a WORKSFORME resolution and walk away.

When digging through the list of files on my harddrive that have "nsInputFileStream" in them, I stumbled across "psmglue.dll" in the "components" directory. Whilst all the other files were dated today or yesterday, this one was modified April 9, 2001 and created March 26th... Removing just this file and restarting moz seems to have made it go away. Best of all, others have spotted this, <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=77927">Bug #77927</a>,

*** Bug 76045 has been marked as a duplicate of this bug. ***

fixing 77927 should fix this as well.

*** Bug 79364 has been marked as a duplicate of this bug. ***

*** Bug 79545 has been marked as a duplicate of this bug. ***

*** Bug 79815 has been marked as a duplicate of this bug. ***

new entry point not found bugs keep cropping up. We're not seeing a real win for the ordering that's there now. So after talking this over with waterson, choffman and kandrot I'm going to disable the use of the win32.order files unless MOZ_COVERAGE is set. This will turn it off for the optimized builds. here's a diff for your enjoyment: Index: dll.inc =================================================================== RCS file: /cvsroot/mozilla/config/dll.inc,v retrieving revision 3.6 diff -u -r3.6 dll.inc --- dll.inc 2001/02/15 23:04:33 3.6 +++ dll.inc 2001/05/10 00:23:11 @@ -83,7 +83,7 @@ !ifdef MAPFILE /MAP:$(MAPFILE) !endif -!if exist(win32.order) && !defined(MOZ_DEBUG) +!if exist(win32.order) && !defined(MOZ_DEBUG) && defined(MOZ_COVERAGE) /ORDER:@win32.order !endif $(LFLAGS)

Disabling the win32 ordering stuff until it can be shown to make a significant difference is fine by me. But, at least one of the "entry point not found" errors was clearly caused by the old psmglue.dll being left over from previous installations (I can confirm this). I believe(?) that installer bug has since been fixed. I think there is a serious question about installer cleanup here. Is there any clear evidence that the win32 order stuff was contributing to this entry point problem? It seems like the installer strategy changed somewhere along the way so that it no longer whacks *all* old stuff and instead removes only stuff it expects to need to remove. Is this the case? This *might* well be a good thing in a world of third party components (is that the reason for the installer change?). But it requires more careful maintainence to keep things working smoothly as the codebase evolves. It is also questionable since the third party need to keep in sync with our evolving codebase anyway... There is no promise that components that work with mozilla version X will not cause a crash of mozilla version X+1.

lets get this turned off for 0.9.1 and the betas that will come from that branch until we learn more from rogc cord work and other investigations.

yes, I have turned off the "nuke from orbit" feature under the windows installer. I was afraid that we might accidently delete the user's entire hard drive, if memory and/or file table were corrupted. There was one case that I've read that the user had lost his entire [program files] folder after installing mozilla using the windows installer. Even though it was not reproduceable, I removed the "nuke from orbit" feature. I also removed it because it would nuke 3rd party files/plugins (as jband had indicated) not installed by our installer. It's really bad to delete files we didn't install. QA has already been informed that they need to add an additional test to their set of test cases. They need to find out the file difference (only obsolete files) after installation of the latest build of mozilla ontop of a previous build as compared to an installation into a new folder. Once this set of obsolete files have been determined, the installers will need to be updated to remove such files (like it does with psmglue.dll - bug 77927). Actually, we can update the install scripts as we find such files. Even though this is more work, it is the rigth way to handle obsolete files and product upgrades, and not use a "nuke from orbit" feature.

resolving this as fixed.

Have gotten two reports (marek@netscape.com and marina@netscape.com)with getting an entry point error on startup using today's build. Error is: "The procedure entry point ... could not be located in the dynamic library xpcom.dll." This is on Win2K Will reopen this bug report. If you want a new bug report, pls let me know. Thank you.

It would help if someone took the time to record the actual string you represent by '...'. We *really* need to nail the issue of whether this is: a) a failure of the installer to remove old dlls. b) some old plugin that the installer doesn't think it should remove c) a broken built part we should not be installing d) something even remotely associated with the win32.order files e) something else. dprice: are you going to attack this today? Do you want to reassign it to installer people? or what?

dbragg's mail to the hook today suggests that he might be a good owner for this bug if it is a real ongoing problem. cc'ing him

Marek reports: "the procedure entry point ??_7nsLocalString@@6B@ could not be located in the [...] xpcom.dll". I'm going to try to do upgrade installs (from 6.0->6.01->daily builds) to see if I can run into this problem.

I'm looking in to this too. The think is, if my stuff was a problem we'd have seen it last week. The thing I checked in last night was for the case of 6.0x->latest version update installs only. If Marek was using a daily build from earlier than Wed. of last week and then updated to today he'd very likely have this problem.

I found the culprit files: ...\components\gkhtml.dll ...\components\mozucth.dll there are other obsolete files that I've noticed too: oji.dll (not sure if this is ours) ...\components\signed.dll I'll update the native win32 installer to remove all of the above mentioned files. This is bug 81601

So Sean, Marek was running the installer and not un update and these are simply obsolete files. Is that what you're saying? If so, this is unrelated to my recent check-ins.

I installed yesterday's build on the pit cam system. I see the problem there. you can check it out.

Don, this is not your problem. Tis mine. It's actually bug 81601.

If you delete: ...\components\gkhtml.dll ...\components\mozucth.dll The error messages should disappear. Does anyone know if it's okay to delete the oji.dll file? anyone? anyone? It looks like it was part of 6.01 an no longer in the latest builds. Oji.dll is not causing the error message, only the first two listed files. But I'd still like to remove oji.dll since it seems obsolete.

sean - perhaps you may want to inquire with Sun folks for this oji file.

changing component to installer and reassigning this to myself.

marking this bug fixed because patches were attached and checked in with bug 81601. 1) install Netscape 6.01 2) install one of the daily builds ontop of 6.01 3) ...\components\gkhtml.dll and ...\components\mozucth.dll should have been removed. 1) install Netscape 6.0 (into a clean folder) 2) install one of the daily builds ontop of 6.0 3) ...\components\gkhtml.dll and ...\components\mozucth.dll should have been removed.

*** Bug 82866 has been marked as a duplicate of this bug. ***

*** Bug 84659 has been marked as a duplicate of this bug. ***

*** Bug 85068 has been marked as a duplicate of this bug. ***

*** Bug 85209 has been marked as a duplicate of this bug. ***

Reopening this because there are four bugs that were filed after this bug was closed and marked as duplicate of this. I'm looking at this because I was asked to relnote this bug but I'm not sure what to say.

The relnote i'd suggest is: The most likely reason for receiving this error message is installing a new mozilla over an old mozilla. mozilla.org does not recommend ever doing this, it is wholy unsupported and can lead to problems such as this one. Workaround: install mozilla elsewhere. If you have specific information about your problem you can of course add it to bug 71010.

How about this slightly more diplomatic version? ---- Unfortunately this bug is caused by dynamically linked files left over from older installs that the newer installers don't know to erase. This is a side-effect of fast-paced development. Newer Mozilla installs don't dare wipe the directory for fear of removing something user-installed like a plugin or test code or second-party component. The easiest solution is to wipe the mozilla directories and perform a fresh install. That will of course entail reinstalling plugins and other add-in components. The more confident user might wish to sort the sub-directory "components" by file creation time and look for a couple of old files. Most of the files after a fresh install should have the same date so they should stick out rather obviously. Remove those files to a safe place and restart Mozilla. You'll want to kick all the tires and look for odd failures. I that happens try adding things back in manually one at a time or reinstalling 3rd party add-ons that fail. ---- maybe Mozilla should reserve "components" for itself and mark those files with it's own version number? Perhaps the xpcom.dll shouldn't be loading things from that directory it doesn't know for sure matches it's expectations? Force 3rd party stuff to plugins or somewhere else?

*** Bug 85885 has been marked as a duplicate of this bug. ***

*** Bug 88418 has been marked as a duplicate of this bug. ***

*** Bug 88585 has been marked as a duplicate of this bug. ***

*** Bug 88845 has been marked as a duplicate of this bug. ***

*** Bug 89304 has been marked as a duplicate of this bug. ***

*** Bug 89434 has been marked as a duplicate of this bug. ***

*** Bug 89871 has been marked as a duplicate of this bug. ***

Endico: Can we get this in the release notes ? BTW: Bug 82430 is the same bug. (misssing entry point in xpcom.dll, works after a complete reinstall)

*** Bug 90245 has been marked as a duplicate of this bug. ***

*** Bug 90796 has been marked as a duplicate of this bug. ***

*** Bug 92227 has been marked as a duplicate of this bug. ***

*** Bug 92227 has been marked as a duplicate of this bug. ***

*** Bug 94108 has been marked as a duplicate of this bug. ***

*** Bug 95333 has been marked as a duplicate of this bug. ***

*** Bug 94380 has been marked as a duplicate of this bug. ***

This bug is now a useless mess. How many different "missing entry point" problems are lumped into the same bug? Each and every one is a different build/configuration/packaging issue, and although similar in cause and effect each will usually have to be fixed individually. I'm closing this bug. Most of the early ones are fixed and the NS_NewGenericModule problems are covered in bug 94108. If you find new and *different* missing entry points please file separate bugs, and put the entry point name in the bug summary to discourage future lumping.

Added two early culprits of many of the dupes in this bug to the summary to forestall reopening.

verified