Closed
Bug 326657
Opened 19 years ago
Closed 18 years ago
Cairo windows builds don't run (VC8 runtime files not found)
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: ria.klaassen, Assigned: ted)
References
()
Details
Attachments
(2 files)
593 bytes,
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
2.39 KB,
application/octetstream
|
Details |
Since 10 days the Cairo windows builds don't start. http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/experimental/cairo/ The last one that worked was the 31 Jan 2006 build.
Comment 1•19 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060210 Firefox/1.6a1 ID:2006021006 WFM (starting today), fixed by one of Vlads unnumbered patches use http://manna.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/gaius-trunk/
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 2•19 years ago
|
||
This one does not run either. Stops at 11.732 kB.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 3•19 years ago
|
||
This might 'fix' the problem for you, copy these files (currently in the main Firefox dir) into the Components directory: Microsoft.VC80.CRT.manifest msvcm80.dll msvcp80.dll msvcr80.dll It also might give an indication of what's going on here. See also: http://forums.mozillazine.org/viewtopic.php?p=2080407#2080296 and further.
We may need to actually package the x86_redist installer and run it as part of the installer -- this situation is pretty crappy. Let's see what bsmedberg thinks.. the problem seems to be that dll's from the components dir can't find the vc8 runtime files, and extension component dll's can't seem to, either.
Summary: Cairo windows builds don't run → Cairo windows builds don't run (VC8 runtime files not found)
Comment 5•19 years ago
|
||
(In reply to comment #4) > We may need to actually package the x86_redist installer and run it as part of > the installer -- this situation is pretty crappy. Let's see what bsmedberg > thinks.. the problem seems to be that dll's from the components dir can't find > the vc8 runtime files, and extension component dll's can't seem to, either. > Don't forget that it's not just the installer - there's also the updater...
On a fresh Win2000 install, the VC8 builds run out of the box; I'll try WinXP next.
I am running Windows XP with SP2 (Post SP2 patches all installed). Can't get latest Cairo Windows build to start. Using windows taskmanager, firefox.exe is left in memory but firefox doesn't appear.
Assignee | ||
Comment 8•18 years ago
|
||
(In reply to comment #7) > I am running Windows XP with SP2 (Post SP2 patches all installed). > > Can't get latest Cairo Windows build to start. > Using windows taskmanager, firefox.exe is left in memory but firefox doesn't > appear. I see this same problem, which may or may not be related to the original focus of this bug. The cairo nightlies (and now the trunk nightlies) don't show a window. Running with NSPR logging on shows me: 0[3b46f8]: nsNativeModuleLoader::LoadModule("C:\fftrunk\firefox\components\jar50.dll") - load FAILED, rv: 80004003, error: error 14001 0[3b46f8]: nsNativeModuleLoader::LoadModule("C:\fftrunk\firefox\components\jsd3250.dll") - load FAILED, rv: 80004003, error: error 14001 0[3b46f8]: nsNativeModuleLoader::LoadModule("C:\fftrunk\firefox\components\xpinstal.dll") - load FAILED, rv: 80004003, error: error 14001
Assignee | ||
Comment 9•18 years ago
|
||
Ok, more information on this: ERROR_SXS_CANT_GEN_ACTCTX 14001 The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log for more detail. From the event log: "Dependent Assembly Microsoft.VC80.CRT could not be found and Last Error was The referenced assembly is not installed on your system." "Resolve Partial Assembly failed for Microsoft.VC80.CRT. Reference error message: The referenced assembly is not installed on your system." "Generate Activation Context failed for C:\fftrunk\firefox\components\jar50.dll. Reference error message: The operation completed successfully." Yes, I have msvc?80.dll in windows\system32. timeless says this is due to .manifest files and the manifest linker...
(In reply to comment #9) > Yes, I have msvc?80.dll in windows\system32. timeless says this is due to > .manifest files and the manifest linker... Actually, you don't want msvc?80.dll in system32, on XP at least. Having it there will cause problems. It lives \windows\WinSxS\Microsoft_blah_VC80_CRT\*. I still can't reproduce this problem though.. I'll poke at it today again.
Comment 11•18 years ago
|
||
We are installing msvc?80 and the corresponding .manifest in dist/bin, which is supposedly part of the assembly search path. Apparently that's not sufficient?
Reporter | ||
Comment 12•18 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060223 Firefox/1.6a1 ID:2006022308 It is running here. Had to cleanup all the little automatically generated files in my profile like compreg.dat, xpti.dat, xul.mfl etc. Don't know which one exactly did the trick but suddenly it started through.
Assignee | ||
Comment 13•18 years ago
|
||
http://mavra.perilith.com/~luser/firefox-cairo-dwi.zip Dependency Walker output for today's build, may be of interest. Too big to attach to bugzilla.
Updated•18 years ago
|
Severity: normal → critical
Comment 14•18 years ago
|
||
(In reply to comment #11) > We are installing msvc?80 and the corresponding .manifest in dist/bin, which is > supposedly part of the assembly search path. Apparently that's not sufficient? If I did understand well, dist/bin is not in the search path. In fact Microsoft.VC80.CRT.manifest "tells" where dll must be searched. Additionnaly, %WINDIR%\WinSxS\... (and the path?) is/are searched. One solution could be (keeping the applocal install) to have the build system "forge" Microsoft.VC80.CRT.manifest with relative path to the dll (ie ..\msvc*80.dll for componennts dir) each time a dll is made. see http://forums.mozillazine.org/viewtopic.php?p=2091593#2091593 and http://forums.mozillazine.org/viewtopic.php?p=2082093#2082093 (describe the manifest "forging")
Comment 15•18 years ago
|
||
It would be good to have links to Microsoft documentation for assembly search paths: the docs that I read seem to say that assemblies are searched in the application directory. Perhaps components search for assemblies next to the component, and not the application? http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconstep4locatingassemblythroughcodebasesorprobing.asp
Assignee | ||
Comment 16•18 years ago
|
||
Aha! After a bit of goofing around, I opened the three offending dll files in the resource editor, and noticed that their Manifest files had a resource ID of "2", whereas the one in firefox.exe had an ID of "1". I edited all three, changing them to "1" and saved them. Firefox starts now! I haven't looked at the build magic, but how are we running mt.exe to add the manifests?
Assignee | ||
Comment 17•18 years ago
|
||
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/config&command=DIFF_FRAMESET&file=rules.mk&rev2=3.497&rev1=3.496 Is the ;2 there a typo, or was that intended? That's essentially what I changed with my resource hacking.
Assignee | ||
Comment 18•18 years ago
|
||
I submit that this is a typo, compare to the original patch: https://bugzilla.mozilla.org/attachment.cgi?id=199692
Attachment #212990 -
Flags: review?(benjamin)
Assignee | ||
Comment 19•18 years ago
|
||
Oh yeah, given the tiny size of this patch, if you r+ it please just check it in for me.
Comment 20•18 years ago
|
||
(In reply to comment #15) > It would be good to have links to Microsoft documentation for assembly search > paths: the docs that I read seem to say that assemblies are searched in the > application directory. Perhaps components search for assemblies next to the > component, and not the application? That's suggested by the copy workaround (copy dll, CRT manifest in all subdir containing dll) and the manifest tricks suggested by auenf (see #14 link 2). From: http://msdn2.microsoft.com/en-us/library/ms235285(en-US,VS.80).aspx - "Note that the manifest ID is 1 for an EXE, 2 for a DLL." so 'Tiny little patch' ??? - "In scenario 1, there is only one copy of the Visual C++ DLLs in the WinSxS folder. In scenario 2, you will have two copies of the Visual C++ DLLs, installed in the application EXE's and DLL's local folders."
Comment 21•18 years ago
|
||
Comment on attachment 212990 [details] [diff] [review] Tiny little patch [checked in] Let's try it!
Attachment #212990 -
Flags: review?(benjamin) → review+
Comment 22•18 years ago
|
||
Comment on attachment 212990 [details] [diff] [review] Tiny little patch [checked in] Checked in on trunk, leaving the bug open pending verification that this is effective.
Attachment #212990 -
Attachment description: Tiny little patch → Tiny little patch [checked in]
Comment 23•18 years ago
|
||
the latest trunk installer gives me this eroor microsft visual c++ runtime erroor program c:\docume~1\owner\local~1\temp\7ds5.tmp\setup.exe r3604 an application has made an attempt to load the c runtime libaray incerrectly plese contact the applcations support team
Comment 24•18 years ago
|
||
had too download zip
Assignee | ||
Comment 25•18 years ago
|
||
(In reply to comment #24) > had too download zip > gabe: Can you try yesterday's installer build and see if the same problem exists?
Comment 26•18 years ago
|
||
(In reply to comment #25) > (In reply to comment #24) > > had too download zip > > > > gabe: Can you try yesterday's installer build and see if the same problem > exists? > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006-02-24-05-trunk/firefox-1.6a1.en-US.win32.installer.exe runs ok but http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/gaius-trunk/firefox-1.6a1.en-US.win32.installer.exe does not run
Comment 27•18 years ago
|
||
fyi i have all microsft updates installed including the optional ones
Reporter | ||
Comment 28•18 years ago
|
||
I tried it out on an old XP sp1 computer but the 1.9a1_2006022404 didn't start up fully but there was no problem with the 1.9a1_2006022408 build.
Assignee | ||
Comment 29•18 years ago
|
||
The build from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006-02-24-11-trunk/ starts up cleanly for me. A little update via email on the installer problem, the user is also getting the message: "1114 could not load c:\docume~1\owner\local~1\temp\ff_temp\xpcom.ns\bin\xistud.dll" I don't know if you want to track the installer issue on this bug or resolve this and open another bug if necessary.
Comment 30•18 years ago
|
||
From the installer of this build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006-02-24-11-trunk/ Microsft Visual C++ Runtime Error Program: c:\docume~1\owner\local~1\temp\7zSF90.tmp\setup.exe R3604 An application has made an attempt to load the C Runtime libaray incorrectly plese contact the applcations support team for more information. ----------------------------------------------------------------------------- Apart from this error message, from previous installers (starting from 0223 nightly trunk), the following error messsage also appeared: Error Occured during installation_Cross-Platform com: -322 INIT_SUB_ERROR
Comment 31•18 years ago
|
||
From the installer of this build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006-02-24-11-trunk/ Microsft Visual C++ Runtime Library Runtime Error Program: c:\docume~1\owner\local~1\temp\7zSF90.tmp\setup.exe R6034 An application has made an attempt to load the C Runtime libaray incorrectly plese contact the applcations support team for more information. ----------------------------------------------------------------------------- Apart from this error message, from previous installers (starting from 0223 Cairo nightly trunk), the following error messsage also appeared: Error Occured during installation_Cross-Platform com: -322 INIT_SUB_ERROR
Reporter | ||
Comment 32•18 years ago
|
||
Tried also an installer build (hourly, 1.9a1_2006022412) on two Win XP computers but no errors here.
Comment 33•18 years ago
|
||
i think you may have too have microsft.netframwork installed too see bug
Reporter | ||
Comment 34•18 years ago
|
||
(In reply to comment #33) On two XP computers no dotnet present and no errors on startup using installer builds.
Comment 35•18 years ago
|
||
I can confirm this on my XP machine... Multiple versions of DotNet installed. Same error as Comment #30 on the build here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006-02-24-11-trunk/ No problem on the build from here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006-02-24-05-trunk/
Reporter | ||
Comment 36•18 years ago
|
||
(In reply to comment #28) > I tried it out on an old XP sp1 computer but the 1.9a1_2006022404 didn't start > up fully but there was no problem with the 1.9a1_2006022408 build. > (In reply to comment #32) > Tried also an installer build (hourly, 1.9a1_2006022412) on two Win XP > computers but no errors here. > This result is not very surprising, since hourlies are NOT cairo-enabled. I didn't notice that. I tested it again on the old computer but now I saw the error on the 24/4 nightly. Waiting for the next cairo-enabled nightly to see if the fix has helped.
Comment 37•18 years ago
|
||
(In reply to comment #36) > (In reply to comment #28) > > I tried it out on an old XP sp1 computer but the 1.9a1_2006022404 didn't start > > up fully but there was no problem with the 1.9a1_2006022408 build. > > > (In reply to comment #32) > > Tried also an installer build (hourly, 1.9a1_2006022412) on two Win XP > > computers but no errors here. > > > This result is not very surprising, since hourlies are NOT cairo-enabled. I > didn't notice that. > I tested it again on the old computer but now I saw the error on the 24/4 > nightly. > Waiting for the next cairo-enabled nightly to see if the fix has helped. > gaius makes hourly cario builds
Reporter | ||
Comment 38•18 years ago
|
||
(In reply to comment #37) > OK, the fix has helped but the error still goes on.
Comment 39•18 years ago
|
||
(In reply to comment #38) > OK, the fix has helped but the error still goes on. Ria, can you try something, either download http://nitro.ausgamers.com/asdf.7z (if you can handle 7z archives) or use attachments I will add. Unzip in your firefox directory and try to start Firefox. If it start, and it should, auenf is right* and this issue can be fixed. * he spread MSVC8 Firefox builds since some times now so... (see http://forums.mozillazine.org/viewtopic.php?t=353008)
Comment 40•18 years ago
|
||
(see comment #39)
Reporter | ||
Comment 41•18 years ago
|
||
(In reply to comment #39) > No sure what you mean, since they already run. They can't run better than they do. And I agree that this bug can be closed for the original problem is solved. The installer problem is a separate issue, that has no direct connection with the original problem. So someone who suffers from this problem might file a new bug for that :)
Comment 42•18 years ago
|
||
(In reply to comment #41) > No sure what you mean, since they already run. They can't run better than they > do. Ooops, sorry I misreaded. Forget about my last comment..
Comment 43•18 years ago
|
||
on the latest trunk builds it says Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060224 Firefox/1.6a1 ID:2006022503 be nice if it said Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060224 Firefox/1.6a1 ID:2006022503 (cario enabled) or Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060224 Firefox/1.6a1 ID:2006022503 (cario disabled) based on about:buildconfig
Comment 44•18 years ago
|
||
(In reply to comment #43) > on the latest trunk builds it says > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060224 > Firefox/1.6a1 ID:2006022503 > > be nice if it said > > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060224 > Firefox/1.6a1 ID:2006022503 (cario enabled) > or > bah forget that im getting confuzed > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060224 > Firefox/1.6a1 ID:2006022503 (cario disabled) > > based on about:buildconfig >
Comment 45•18 years ago
|
||
(In reply to comment #41) > So someone who suffers from this problem might file a new bug > for that :) > Filed Bug 328579 https://bugzilla.mozilla.org/show_bug.cgi?id=328579
Reporter | ||
Comment 46•18 years ago
|
||
*** Bug 328577 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 47•18 years ago
|
||
Considered fixed by the patch of Ted Mielczarek.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 18 years ago
Resolution: --- → FIXED
Comment 48•18 years ago
|
||
(In reply to comment #20) > From: http://msdn2.microsoft.com/en-us/library/ms235285(en-US,VS.80).aspx > - "Note that the manifest ID is 1 for an EXE, 2 for a DLL." so 'Tiny little > patch' ??? Just because I don't like to not understanding something, I did some search about manifest id. Some could say here "who cares, it works" and I could understand but why a patch that goes against msdn explanation makes the things works. The most important finding was http://www.grimes.demon.co.uk/workshops/fusWSThirteen.htm which explains very well how assemblies work. At the end of "Unmanaged Assembly Versioning" author explains that when running an application which load a dll *without manifest*, _the DLL loader use application manifest_. At this point I thought that using resource ID=1 for Firefox's DLL embedded manifest was like inactivating "them". I then tried to remove them (using a resource editor) from jsd3250.dll, xpinstal.dll and xpcom.dll and Firefox works nice like that. Of course this has to be confirmed to works on win2000 too. Conclusion, even if everything is OK with msvc8 runtime now, I think the manifest embedding should be removed for all DLLs from the build process. This would change things in bug #249782 too... Tested on 20060224 nightly and a custom 20060226 build with all dll "non-manifested" on a bulk Windows 2000 installation (no updates, nothing installed except firefox 1.5.0.1 and "zip-install" of trunk build over that)
Assignee | ||
Comment 49•18 years ago
|
||
Regis: thanks for the detective work! That sucks. The only reason my patch works is because having the manifest at ID 1 is equivalent to not having a manifest... As far as I can tell, after reading that page, there's no straightforward way to make this work in both situations. 1) Running firefox loads dlls from the components/ dir. If those dlls have an embedded manifest (at ID 2), they will have their own activation context, and won't see the VC8 runtime files in the app directory. 2) Running the installer loads xpcom.dll from a separate directory, which contains the VC8 runtime files. If xpcom.dll does not contain a manifest, it will use the application manifest, which does not mention the VC8 runtime at all, so it can't be found. One thing we might be able to do is put a MSVCRT8 manifest in the components dir, which points to the parent directory to locate the runtime files.
Comment 50•18 years ago
|
||
(In reply to comment #49) > 2) Running the installer loads xpcom.dll from a separate directory, which > contains the VC8 runtime files. If xpcom.dll does not contain a manifest, it > will use the application manifest, which does not mention the VC8 runtime at > all, so it can't be found. I will take a look at the installer issue too. But I think it *could* be possible to fix the issue. Assuming all DLLs have no manifest let's add a manifest to the application that load xpcom.dll.
Assignee | ||
Comment 51•18 years ago
|
||
I've got plans hatching in bug 328579. Let's let this bug rest in peace.
Assignee | ||
Updated•13 years ago
|
Assignee: nobody → ted.mielczarek
You need to log in
before you can comment on or make changes to this bug.
Description
•