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.

First error: C++ runtime

Second Error - DLL not found

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

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

I also had this happen to me yesterday evening (~6 PM CST) with my own builds. Confirming, based on comments 3 and 4.

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!

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.

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

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.

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.

see also bug 312336

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

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.

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.

I have a patch that just might work.

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.

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.

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.

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.

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

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. ***

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) I'm afraid it didn't work for me.

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

Please note that testing this change with win2k is almost pointless: win2k does not load DLLs according to manifests.

Win XP, same errors. (In reply to comment #28) > > Which OS? Error message? >

(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

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.

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

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

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

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

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.

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

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

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.

(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

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

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

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

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.

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.

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).

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.

I know the Makefile part needs work, but this is still cleaner than the .manifest file way.

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

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)

(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

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

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.

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

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

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=

Please checkin. Thanks.

fixed on trunk.

verified Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a1) Gecko/20060304 Firefox/1.6a1 ID:2006030405