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)

Product:
Core
Component:
Graphics
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: ria.klaassen, Assigned: ted)

References

(
URL
)

Details

Attachments

(2 files)

Tiny little patch [checked in]
593 bytes, patch
benjamin
: review+
Details | Diff | Splinter Review
Microsoft.VC80.CRT with relative paths
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.
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
This one does not run either. Stops at 11.732 kB.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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)
(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.
(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

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.

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?
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. 
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.
Severity: normal → critical
(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")


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
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?

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)
Oh yeah, given the tiny size of this patch, if you r+ it please just check it in for me.

(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 on attachment 212990 [details] [diff] [review]
Tiny little patch [checked in]

Let's try it!
Attachment #212990 - Flags: review?(benjamin) → review+
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]
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
had too download zip
(In reply to comment #24)
> had too download zip
> 

gabe: Can you try yesterday's installer build and see if the same problem exists?

(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

fyi i have all microsft updates installed including the optional ones
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.
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.
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



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
Tried also an installer build (hourly, 1.9a1_2006022412) on two Win XP computers but no errors here.
i think you may have too have microsft.netframwork installed too see bug
(In reply to comment #33)
On two XP computers no dotnet present and no errors on startup using installer builds.



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/
(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. 
(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

(In reply to comment #37)
> 
OK, the fix has helped but the error still goes on.
(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)
(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 :)
(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..

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
(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
> 


(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
*** Bug 328577 has been marked as a duplicate of this bug. ***
Considered fixed by the patch of Ted Mielczarek.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 18 years ago
Resolution: --- → FIXED
(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)
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.

(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.
I've got plans hatching in bug 328579.  Let's let this bug rest in peace.
Assignee: nobody → ted.mielczarek
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: