If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Cairo-windows installer builds fail to install (C++ runtime error)

VERIFIED FIXED

Status

()

Core
Graphics
--
blocker
VERIFIED FIXED
12 years ago
12 years ago

People

(Reporter: Matt Lemieux, Assigned: ted)

Tracking

({regression, smoketest})

Trunk
x86
Windows XP
regression, smoketest
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments, 6 obsolete attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060225 Firefox/1.6a1
Build Identifier: 

Installer builds from Gaius have failed to install since 2006-02-24-11. They report the following error messages:
Runtime Error!

Program: D:\profile.cu\LOCALS~1\Temp\7zSDEB.tmp\setup.exe

R6034
An application has made an attempt to load the C runtime library incorrectly. Please contact the application's support team for more information

FOLLOWED BY:
1114 : Could not load D:\profile.cu\LOCALS~1\Temp\ff_temp\xpcom.ns\xpistub.dll

After pressing okay, the installer sits and does nothing.

Reproducible: Always

Steps to Reproduce:
1. Grab a recent installer build from Gaius
2. Run the installer
3. Upon the actual installation, first error appears.
4. Press okay.
5. Second error appears.
6. Press okay.
7. Watch the installer just sit there.

Actual Results:  
Two errors and an idle installer

Expected Results:  
Installer installs Firefox OR at least, fails a touch more gracefully.
(Reporter)

Comment 1

12 years ago
Created attachment 213181 [details]
First error

First error: C++ runtime
(Reporter)

Comment 2

12 years ago
Created attachment 213182 [details]
Second error

Second Error - DLL not found
*** Bug 328577 has been marked as a duplicate of this bug. ***

Comment 4

12 years ago
I am seeing the same behavior) with the nightly installer downloaded today (Feb 25,2006)

Comment 5

12 years ago
I also had this happen to me yesterday evening (~6 PM CST) with my own builds.

Confirming, based on comments 3 and 4.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 6

12 years ago
Oh crap.  I just had an inspired thought.  My patch to bug 326657 fixed the installing of manifest files into dlls.  I think that might have caused us to build a manifest into this DLL that points to the VC8 runtime, which doesn't exist yet because we haven't installed it!
(Assignee)

Comment 7

12 years ago
Ok, I can reproduce this.  Turns out I wasn't running the installer all the way.  Bug reporters: please remember to give as much information as possible when reporting a bug!  Knowing at what point the installer failed would have been nice...

After a discussion with bsmedberg (that I apparently missed most of), this is because setup.exe runs from some temp dir, unpacks xpcom.xpi to some other temp dir, then initializes xpcom.dll to continue the installation.  However, xpcom.dll requires the VC8 runtime, which is unpacked to the same dir as xpcom.dll, and setup.exe doesn't know to look there.
(Assignee)

Comment 8

12 years ago
For the record, here's the official Microsoft reference on this stuff:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/about_isolated_applications_and_side_by_side_assemblies.asp
(Assignee)

Comment 9

12 years ago
I think, according to this:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/searching_for_assembly_files.asp
that if we put a copy of the manifest in with resource ID 2, it will do the right thing.  We might have to put 2 copies of the manifest in, unless we can switch it up based on what we're compiling.  I need to test this first.

(Assignee)

Comment 10

12 years ago
Ok, so hacking all the dlls in xpcom.xpi to have two copies of the manifest at IDs 1 and 2 gets rid of the error, but I get "Error occurred during installation - Cross-Platform COM: -322 INIT_STUB_ERROR".  Is that the same problem, or something else?
(In reply to comment #10)
> Ok, so hacking all the dlls in xpcom.xpi to have two copies of the manifest at
> IDs 1 and 2 gets rid of the error, but I get "Error occurred during
> installation - Cross-Platform COM: -322 INIT_STUB_ERROR".  Is that the same
> problem, or something else?
> 
I've had both of these errors. 2 days ago I got the -322 INIT_STUB_ERROR when trying to install the latest Trunk, yesterday and today I got the Visual C++ Runtime error.

Comment 12

12 years ago
see also bug 312336

Updated

12 years ago
Summary: Gaius Installer Builds fail to Install (C++ runtime error) → Cairo-windows installer builds fail to install (C++ runtime error)
*** Bug 312336 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 14

12 years ago
So as it turns out, my patch on bug 326657 was wrong.  The right thing to do is going to be to not embed manifests in dlls at all, and use the Activation Context API to make the installer work.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/using_the_activation_context_api.asp

Basically we ship a manifest inside xpcom.xpi that points to the vc8 runtime, and call CreateActCtx() with that manifest to get an activation context that can find the runtime.  Then ActivateActCtx() to activate it, then LoadModule() should Just Work.  See the example "An assembly acts to take care of everything itself" from the API link.
(Assignee)

Comment 15

12 years ago
The installer already does some XP-specific stuff right here:
http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/installer/windows/wizard/setup/xpi.c#99

That's where all this code would go.
(Assignee)

Comment 16

12 years ago
I have a patch that just might work.
Status: NEW → ASSIGNED
(Assignee)

Updated

12 years ago
Assignee: nobody → ted.mielczarek
Status: ASSIGNED → NEW
(Assignee)

Comment 17

12 years ago
Created attachment 213289 [details] [diff] [review]
Do Activation Context magic on WinXP when building with VC8

This compiles, but I didn't test it.  I've never built the installer before.  Also, it's late.  But I think the logic is sound.  It's going to require us to ship xpistub.dll.manifest, but that should be easy.  We're also going to have to not embed manifests in dll files at all, but that's easy as well.
(Assignee)

Comment 18

12 years ago
Rob: is this code that's going away in the new installer?
bsmedberg: if not, can you take a look at this?  Someone needs to build an installer with this patch and test it before I ask for review obviously.  I don't have time for that right now.
(Assignee)

Comment 19

12 years ago
Created attachment 213291 [details] [diff] [review]
Don't embed manifests in DLL files

We will need this as well if this works.

Also we will need a tiny little bit of build-fu to copy/package xpistub.dll.manifest into xpcom.xpi, but I'm too tired to even look into that right now.
They shouldn't be required with the new installer unless something unforeseen happens. The new installer won't be complete until around alpha 2 though.
(Assignee)

Comment 21

12 years ago
Ah crap, after all that code, I think there's a much simpler solution.

Apply the "Don't embed manifests in DLL files" patch.  Then write a little build patch that does embed a manifest for xpistub.dll (at resource ID 2).  I'm 99% sure that will work.  When setup.exe loads xpistub.dll, it will use the manifest and find the vc8 runtimes in that directory.  Since xpistub.dll gets installed into the same directory as firefox.exe, it shouldn't matter that it's using its own manifest in that case, since the runtime files are right next to it.
Status: NEW → ASSIGNED

Comment 22

12 years ago
(In reply to comment #17)
> This compiles, but I didn't test it.  I've never built the installer before. 
To build the installer, do a |make| in browser/installer.
See http://developer.mozilla.org/en/docs/Build_and_Install#Installing_Your_Build
In any case this will be hard to test without just landing it because you need at least 2 systems to test this, one for building and a different one for testing.  You need to build on a system that has VC8 installed and test on a system that has vc7 installed but not vc8.  Even then, as far as I know the only builds anyone has had trouble getting to install are the ones created by gaius.  I have heard no reports af any difficulties with any third party builds.

Of course I could at least test with this under vc7 to make sure the installer still builds and runs correctly.  But it now sounds like we are not sure what the correct patch is.  The approach in comment #21 sounds reasonable to me.

Comment 24

12 years ago
To test the installer when vc8 is missing you can rely on the people following this bug, if you provide an installer they (and me in the list) will be happy to give it a run.
*** Bug 328756 has been marked as a duplicate of this bug. ***

Comment 26

12 years ago
Following what I posted in bug 326657, I build (on winXP) without any embedded manifest and actually, my installer works fine on a clean win2k so  here's a link for people wanting to test (note that as this was a private build official branding is enabled) 
Download link : http://caspar.regis.free.fr/various/firefox-1.6a1.en-US.win32.installer.exe (8.47MB)
(Reporter)

Comment 27

12 years ago
(In reply to comment #26)

I'm afraid it didn't work for me.

Comment 28

12 years ago
(In reply to comment #27)
> I'm afraid it didn't work for me.
Which OS? Error message? 

Comment 29

12 years ago
Please note that testing this change with win2k is almost pointless: win2k does not load DLLs according to manifests.
(Reporter)

Comment 30

12 years ago
Win XP, same errors.

(In reply to comment #28)
> 
> Which OS? Error message? 
> 

Comment 31

12 years ago
(In reply to comment #30)
> Win XP, same errors.
Let's try with a manifest (ID=2) in xpistub.dll (Like said Ted)
http://caspar.regis.free.fr/various/firefox-1.6a1.en-US.win32.installer_2.exe (8.47MB)

(In reply to comment #29)
> Please note that testing this change with win2k is almost pointless: win2k does
> not load DLLs according to manifests.
Ok

(Reporter)

Comment 32

12 years ago
First error 4 times then the second error, but the install does now exit rather than just sitting there.

(In reply to comment #31)
> Let's try with a manifest (ID=2) in xpistub.dll (Like said Ted)
> http://caspar.regis.free.fr/various/firefox-1.6a1.en-US.win32.installer_2.exe
> (8.47MB)
wgianopoulos - Virtual machines are a beautiful thing ;-) Microsoft makes a 45 day trial version of VirtualPC if you want to try it out.
(In reply to comment #33)
> wgianopoulos - Virtual machines are a beautiful thing ;-) Microsoft makes a 45
> day trial version of VirtualPC if you want to try it out.
> 

Oh good. So, since you are such and expert on this I guess you are volunteering to do this then?
Sure, but I haven't built with the installer enabled in quite some time, so I may need a day or so to try it out.
(Assignee)

Comment 36

12 years ago
Regis: neither of those builds work for me.  Might be the other dlls that are being loaded?  I guess we'll have to look at this Activation Context patch...
(Assignee)

Comment 37

12 years ago
bsmedberg: how would I go about getting xpistub.dll.manifest into xpcom.xpi?  I know about packages-static, but it won't be in dist\bin in the first place...

Comment 38

12 years ago
(In reply to comment #36)
> Regis: neither of those builds work for me.  Might be the other dlls that are
> being loaded?  I guess we'll have to look at this Activation Context patch...
Perhaps. I need first another clean winxp install then I'll test that activation context patch. Will report here results. 

Comment 39

12 years ago
(In reply to comment #33)
> wgianopoulos - Virtual machines are a beautiful thing ;-) Microsoft makes a 45
> day trial version of VirtualPC if you want to try it out.

Yes, Virtual PC is a good idea, or Virtual Server.

However, I would recommend VMware Player, it is free.  Or VMware Server, currently in Beta and also free.  Both have the advantage they can also be used on a Linux host, if that is where you say have disk & RAM to spare.

Comment 40

12 years ago
I'm not sure I understand why you need xpistub.dll.manifest (instead of, for instance, embedding the manifest directly in xpistub.dll), but if you *do* need it, then you should ship it to dist/bin.
(Assignee)

Comment 41

12 years ago
(In reply to comment #38)
> Perhaps. I need first another clean winxp install then I'll test that
> activation context patch. Will report here results. 

Regis: if you try that patch, make sure you have a copy of xpistub.dll.manifest in xpcom.xpi.

bsmedberg: Having the manifest embedded in the DLL doesn't seem to work, I think that activation context doesn't take hold for any other DLLs that get loaded.  I believe that creating an activation context using the API by loading the manifest file will create a context that applies to everything loaded.

That said, how do I get that manifest to ship to dist/bin?

Comment 42

12 years ago
Ship it in a libs:: rule from the end of http://lxr.mozilla.org/mozilla/source/xpinstall/stub/Makefile.in

ifeq (WINNT,$(OS_ARCH))
libs:: $(srcdir)/xpistub.dll.manifest
<tab>$(INSTALL) $^ $(DIST)/bin
endif
(Assignee)

Comment 43

12 years ago
Created attachment 213462 [details] [diff] [review]
Package xpistub.dll.manifest into xpcom.xpi

Ok, this should be the final piece to this.  Regis (or anyone else): if you can apply these three patches and build an installer with vc8, please give it a shot.
I'll give it a shot when I get home tonight and let you know.

Comment 45

12 years ago
(In reply to comment #41)
> Regis: if you try that patch, make sure you have a copy of xpistub.dll.manifest
> in xpcom.xpi.
(In reply to comment #43)
> Ok, this should be the final piece to this.  Regis (or anyone else): if you can
> apply these three patches and build an installer with vc8, please give it a
> shot.
Here's what I did : 
- patch -p0 the three patches
- make -C xpinstall/stub/ (my xpistub.dll had a manifest)
- make -C toolkit/mozapps/installer/windows/wizard/setup/ (rebuild setup.exe, gave some warnings about macro redefinition)
- make -C browser/installer/ installer
- checked that this installer and Firefox it installs both run (on win2k)

Now if someone can test on XP : 
http://caspar.regis.free.fr/various/firefox-1.6a1.en-US.win32.installer_3.exe
(Reporter)

Comment 46

12 years ago
(In reply to comment #45)
> 
> Now if someone can test on XP : 
> http://caspar.regis.free.fr/various/firefox-1.6a1.en-US.win32.installer_3.exe
> 

Works for me.
Regis - your installer build works fine on XPSP2 with NO .NET framework installed at all (1.1 or 2.0). Firefox also works just fine after installation :)

I'm doing my own build with the three patches applied too with MSVC8. Hopefully, I'll get the same results :)

Comment 48

12 years ago
(In reply to comment #47)
> Regis - your installer build works fine on XPSP2 with NO .NET framework
> installed at all (1.1 or 2.0). Firefox also works just fine after installation
> :)

So Ted's patches work ;) and this bug is over ^^

(Assignee)

Comment 49

12 years ago
(In reply to comment #45)
> Now if someone can test on XP : 
> http://caspar.regis.free.fr/various/firefox-1.6a1.en-US.win32.installer_3.exe

Sweet, that works!  Thanks so much for the builds!
 
(Assignee)

Updated

12 years ago
Attachment #213289 - Flags: review?(benjamin)
(Assignee)

Updated

12 years ago
Attachment #213291 - Flags: review?(benjamin)
(Assignee)

Updated

12 years ago
Attachment #213462 - Flags: review?(benjamin)

Updated

12 years ago
Attachment #213462 - Flags: review?(benjamin) → review+

Comment 50

12 years ago
Comment on attachment 213289 [details] [diff] [review]
Do Activation Context magic on WinXP when building with VC8

I'm going to have to look at this more carefully tomorrow... the MSDN docs are confusing me.
(Assignee)

Comment 51

12 years ago
Created attachment 213520 [details] [diff] [review]
Activation context magic + embed a manifest in xpistub.dll

This is going to obsolete attachment 213289 [details] [diff] [review] and attachment 213462 [details] [diff] [review], but I need to test it.  It just embeds a manifest in xpistub.dll, and loads it from there to create the activation context instead of having a .manifest laying around.
(Assignee)

Comment 52

12 years ago
Comment on attachment 213520 [details] [diff] [review]
Activation context magic + embed a manifest in xpistub.dll

The code works, but the build-fu does not.  The rule I added runs after the dll has been copied to $(DIST)/bin, so the dll there doesn't get a manifest.  Other than that this looks good.
Comment on attachment 213520 [details] [diff] [review]
Activation context magic + embed a manifest in xpistub.dll

You should use manifest resource ID whose value is larger than 16
because you are managing activation contexts on your own.
http://msdn.microsoft.com/library/en-us/sbscs/setup/using_side_by_side_assemblies.asp?frame=true
OS loader don't have to care about your manifest resource (just like as xpistub.dll.manifest file).
(Assignee)

Comment 54

12 years ago
Ah, thanks for the info.

Better link: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/using_side-by-side_assemblies_as_a_resource.asp

I'll fix this in the next version of the patch.  The makefile change needs tweaking anyway.
(Assignee)

Comment 55

12 years ago
Created attachment 213600 [details] [diff] [review]
Activation Context magic + embed at ID 17

I know the Makefile part needs work, but this is still cleaner than the .manifest file way.
Attachment #213289 - Attachment is obsolete: true
Attachment #213462 - Attachment is obsolete: true
Attachment #213520 - Attachment is obsolete: true
Attachment #213600 - Flags: review?(benjamin)
Attachment #213289 - Flags: review?(benjamin)
(In reply to comment #45)


 
> Now if someone can test on XP : 
> http://caspar.regis.free.fr/various/firefox-1.6a1.en-US.win32.installer_3.exe
> 
Can't install it. Error message "Setup has encountered a problem and needs to close". Re-downloaded, same thing. XP Home, SP2.

Comment 57

12 years ago
Installed on XP, worked fine.

(In reply to comment #56)
> (In reply to comment #45)
> > Now if someone can test on XP : 
> > http://caspar.regis.free.fr/various/firefox-1.6a1.en-US.win32.installer_3.exe
> > 
> Can't install it. Error message "Setup has encountered a problem and needs to
> close". Re-downloaded, same thing. XP Home, SP2.

(In reply to comment #45)
> Now if someone can test on XP : 
> http://caspar.regis.free.fr/various/firefox-1.6a1.en-US.win32.installer_3.exe
> 
I realize this is not the latest patch, but is the latest thing that there is a build for that I can test.  This installed perfectly with no issues under Windows XP SP2.  I am also one of the people who cannot install the Gaius builds, so this is a valid test.

Unfortunaetly, now the uninstaller fails with the same issue.

I don't know if your new fix addresses this issue, but evidently whatever is done to make the installer work needs to be done to the uninstaller as well.
smoketest blocker (hadn't tested Win trunk in over a week)
Severity: major → blocker
Keywords: regression, smoketest

Comment 60

12 years ago
(In reply to comment #56)
> (In reply to comment #45)
> 
> 
> 
> > Now if someone can test on XP : 
> > http://caspar.regis.free.fr/various/firefox-1.6a1.en-US.win32.installer_3.exe
> > 
> Can't install it. Error message "Setup has encountered a problem and needs to
> close". Re-downloaded, same thing. XP Home, SP2.

same thing , but after Re-donwloaded Work fine . Good work 

Comment 61

12 years ago
*** Bug 329166 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 62

12 years ago
Created attachment 213868 [details] [diff] [review]
The One True Patch

Ok.  This combines the two patches.  It modifies the embedding of manifests in rules.mk to be controlled by a variable EMBED_MANIFEST_AT, which you set to the ID number where you'd like your manifest to be embedded.  Tested and working on my xpsp2 box.

http://mavra.perilith.com/~luser/firefox-1.6a1.en-US.win32.installer.exe for anyone that wants to try it.

We should get this in so people can install again.
Attachment #213291 - Attachment is obsolete: true
Attachment #213600 - Attachment is obsolete: true
Attachment #213868 - Flags: review?(benjamin)
Attachment #213291 - Flags: review?(benjamin)
Attachment #213600 - Flags: review?(benjamin)

Comment 63

12 years ago
(In reply to comment #26)
> Following what I posted in bug 326657, I build (on winXP) without any embedded
> manifest and actually, my installer works fine on a clean win2k so  here's a
> link for people wanting to test (note that as this was a private build official
> branding is enabled) 
> Download link :
> http://caspar.regis.free.fr/various/firefox-1.6a1.en-US.win32.installer.exe
> (8.47MB)
> 

(In reply to comment #26)
> Following what I posted in bug 326657, I build (on winXP) without any embedded
> manifest and actually, my installer works fine on a clean win2k so  here's a
> link for people wanting to test (note that as this was a private build official
> branding is enabled) 
> Download link :
> http://caspar.regis.free.fr/various/firefox-1.6a1.en-US.win32.installer.exe
> (8.47MB)
> 

(In reply to comment #46)
> (In reply to comment #45)
> > 
> > Now if someone can test on XP : 
> > http://caspar.regis.free.fr/various/firefox-1.6a1.en-US.win32.installer_3.exe
> > 
> 
> Works for me.
> 
In reply to this message with the version_3 installer:

It worked ok, except when choosing Tools-> Options (to get to the that page), it crashed out--browser window closed quickly. Yet, the FF 1.5.0.1 build works *OK*

---Donald Bock, EndUser, Tester.
(In reply to comment #62)
> Created an attachment (id=213868) [edit]
> The One True Patch
> 
> Ok.  This combines the two patches.  It modifies the embedding of manifests in
> rules.mk to be controlled by a variable EMBED_MANIFEST_AT, which you set to the
> ID number where you'd like your manifest to be embedded.  Tested and working on
> my xpsp2 box.
> 
> http://mavra.perilith.com/~luser/firefox-1.6a1.en-US.win32.installer.exe for
> anyone that wants to try it.
> 
> We should get this in so people can install again.
> 

That WFM (XP Home,SP2)except no Talkback. Running it now.
(In reply to comment #62)
> Created an attachment (id=213868) [edit]
> The One True Patch
> 
> Ok.  This combines the two patches.  It modifies the embedding of manifests in
> rules.mk to be controlled by a variable EMBED_MANIFEST_AT, which you set to the
> ID number where you'd like your manifest to be embedded.  Tested and working on
> my xpsp2 box.
> 
> http://mavra.perilith.com/~luser/firefox-1.6a1.en-US.win32.installer.exe for
> anyone that wants to try it.
> 
> We should get this in so people can install again.
> 

Not quite perfect.

It installs fine and runs fine, but cannot be uninstalled, you get the error:

----------------------------------------------------------------------------

Runtime Error!

Program: C\Docume~1\WAG\LOCALS~1\Temp\nstmp85\uninstall.exe

R6034
An application has made an attempt to load the C runtime library incorrectly.
Please contact the application's support team for more information.

-----------------------------------------------------------------------------

The same fix needs to be applied to the uninstaller as I previously mentioned in comment #58.
(Assignee)

Comment 66

12 years ago
Filed bug 329237 for the uninstaller.  We're probably going to fix that differently.

Comment 67

12 years ago
Comment on attachment 213868 [details] [diff] [review]
The One True Patch

>Index: xpinstall/stub/Makefile.in

>+EMBED_MANIFEST_AT= 17

nit, add a space between AT=
Attachment #213868 - Flags: review?(benjamin) → review+
(Assignee)

Comment 68

12 years ago
Created attachment 213895 [details] [diff] [review]
nit, picked

Please checkin.

Thanks.
Attachment #213868 - Attachment is obsolete: true
Attachment #213895 - Flags: review+

Comment 69

12 years ago
fixed on trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Comment 70

12 years ago
verified Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a1) Gecko/20060304 Firefox/1.6a1 ID:2006030405
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.