Last Comment Bug 713167 - Microsoft.VC80.CRT SideBySide errors, browsercomps.dll
: Microsoft.VC80.CRT SideBySide errors, browsercomps.dll
Status: VERIFIED FIXED
[qa!]
: regression, verified-beta
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: Trunk
: x86 Windows XP
: -- major (vote)
: mozilla12
Assigned To: Ted Mielczarek [:ted.mielczarek]
:
Mentors:
: 714185 717974 (view as bug list)
Depends on:
Blocks: 714495
  Show dependency treegraph
 
Reported: 2011-12-22 18:29 PST by Tetsuro Kato (tete)
Modified: 2012-03-22 09:40 PDT (History)
24 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
affected
+
verified
+
verified
verified


Attachments
fx9_sxs_error_l.png (28.28 KB, image/png)
2011-12-22 18:29 PST, Tetsuro Kato (tete)
no flags Details
avoid to add manifest to dll (1.16 KB, patch)
2011-12-26 20:38 PST, Atsushi Okawa
ted: review-
Details | Diff | Splinter Review
avoid to add manifest to dll (2.48 KB, patch)
2011-12-26 21:14 PST, Atsushi Okawa
no flags Details | Diff | Splinter Review
don't embed a manifest referencing the CRT in browsercomps.dll (1.50 KB, patch)
2011-12-27 07:38 PST, Ted Mielczarek [:ted.mielczarek]
khuey: review+
christian: approval‑mozilla‑aurora+
christian: approval‑mozilla‑beta+
Details | Diff | Splinter Review

Description Tetsuro Kato (tete) 2011-12-22 18:29:44 PST
Created attachment 583990 [details]
fx9_sxs_error_l.png

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Build ID: 20111220165912

Steps to reproduce:

Removed all .NET Framework and VC++ 2005 SP1 redistributable from Windows XP SP3.


Actual results:

Loading browsercomps.dll fails due to SideBySide error. This causes the problems such as the following:
* RSS feed function did not work correctly. For exanple: http://samlab.ws/rss/
* Decreased the number of items of "about:about".


Expected results:

Should load browsercomps.dll correctly.
Comment 1 Tetsuro Kato (tete) 2011-12-23 04:00:46 PST
I found a document that might be relevant to the problem.
http://stackoverflow.com/questions/2335476/loadlibrary-fails-to-load-dll-with-manifest-and-private-assembly

Deleting a RT_MANIFEST from the resource of browsercomps.dll fixed the problem, but I don't know whether this is the best solution.
Comment 2 Tetsuro Kato (tete) 2011-12-23 17:54:11 PST
I have confirmed latest-trunk (firefox-11.0a1.en-US.win32) has the same problem.
Comment 3 Alice0775 White 2011-12-24 00:02:08 PST
Confirmend on newly installed WindowsXP sp3.
http://hg.mozilla.org/releases/mozilla-release/rev/c4405d7a95f6
Mozilla/5.0 (Windows NT 5.1; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
http://hg.mozilla.org/releases/mozilla-beta/rev/c130e43aa4b5
Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20100101 Firefox/10.0
http://hg.mozilla.org/releases/mozilla-aurora/rev/7c408ff60a8e
Mozilla/5.0 (Windows NT 5.1; rv:11.0a2) Gecko/20111223 Firefox/11.0a2
http://hg.mozilla.org/mozilla-central/rev/c5b90ea7e475
Mozilla/5.0 (Windows NT 5.1; rv:12.0a1) Gecko/20111223 Firefox/12.0a1

Error in Error Console;
Failed to load native module at path 'C:\Program Files\Mozilla Firefox\components\browsercomps.dll': (80004003) error 14001
Comment 4 Alice0775 White 2011-12-24 00:38:16 PST
Regression winodw(m-c)
Works:
http://hg.mozilla.org/mozilla-central/rev/e0acef471ab2
Mozilla/5.0 (Windows NT 5.1; rv:9.0a1) Gecko/20110824 Firefox/9.0a1 ID:20110824034944
Fails:
http://hg.mozilla.org/mozilla-central/rev/d3e15e7073f9
Mozilla/5.0 (Windows NT 5.1; rv:9.0a1) Gecko/20110825 Firefox/9.0a1 ID:20110825082055
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e0acef471ab2&tochange=d3e15e7073f9
Comment 5 Ted Mielczarek [:ted.mielczarek] 2011-12-24 07:20:18 PST
Re-reading rules.mk, I was fairly certain we weren't supposed to embed manifests in DLLs unless we explicitly requested them?
Comment 6 Tetsuro Kato (tete) 2011-12-24 21:43:49 PST
Also Firefox 9.0.1 cannot open about:home when the problem has occurred.
Comment 7 Mike Hommey [:glandium] 2011-12-25 23:36:33 PST
I wonder how come we haven't been able to catch this until actual release? I mean, does no one in the million beta testers have XP without VC 8.0 CRT ?
Comment 8 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-12-26 04:51:09 PST
Apparently not.
Comment 9 ABE Hiroki (:hATrayflood) 2011-12-26 07:34:18 PST
I got same error on newly installed Vista RTM.

Vista RTM: NG, msvcr80/msvcp80 is 8.00.50727.312.
Vista SP1: OK, 8.00.50727.1434 is added.
Vista SP2: OK, 8.00.50727.4016 is added.
Comment 10 Atsushi Okawa 2011-12-26 20:38:08 PST
Created attachment 584380 [details] [diff] [review]
avoid to add manifest to dll

Tete-san builds with applying this patch on VS2005 SP1.
http://www1.plala.or.jp/tete009/mozilla-release-bug713167.7z

So hATrayflood-san said that this Firefox was able to run on WinXP SP3.
Comment 11 Atsushi Okawa 2011-12-26 21:14:37 PST
Created attachment 584382 [details] [diff] [review]
avoid to add manifest to dll

I upload it again.
Comment 12 Ted Mielczarek [:ted.mielczarek] 2011-12-27 06:54:41 PST
Comment on attachment 584380 [details] [diff] [review]
avoid to add manifest to dll

We can't use this patch as-is, it will break things like accessibility. The original intent was for only certain DLLs to embed a manifest. Perhaps we screwed this up along the way?

In fact, browsercomps.dll should be linked with the static CRT.
Comment 13 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-12-27 06:55:37 PST
(In reply to Ted Mielczarek [:ted, :luser] from comment #12)
> In fact, browsercomps.dll should be linked with the static CRT.

Er, why?
Comment 14 Ted Mielczarek [:ted.mielczarek] 2011-12-27 06:58:02 PST
bug 376041. Looks like I fiddled this in bug 422360 though, which is why it broke when we stopped building our own CRT.
Comment 15 Ted Mielczarek [:ted.mielczarek] 2011-12-27 06:58:49 PST
Alternately, I guess we can just statically link the CRT when we're building against a libxul SDK, and skip embedding a manifest in the normal case, which should work.
Comment 16 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-12-27 06:59:46 PST
(In reply to Ted Mielczarek [:ted, :luser] from comment #15)
> Alternately, I guess we can just statically link the CRT when we're building
> against a libxul SDK, and skip embedding a manifest in the normal case,
> which should work.

Yeah, this sounds like the right way to go.  Components that are built with Firefox should be allowed to assume things like which CRT is available.
Comment 17 Ted Mielczarek [:ted.mielczarek] 2011-12-27 07:38:44 PST
Created attachment 584433 [details] [diff] [review]
don't embed a manifest referencing the CRT in browsercomps.dll

Like this. I pushed this to try, so there should be builds to test soon.
Comment 18 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-12-27 07:42:12 PST
Comment on attachment 584433 [details] [diff] [review]
don't embed a manifest referencing the CRT in browsercomps.dll

Review of attachment 584433 [details] [diff] [review]:
-----------------------------------------------------------------

If it works, ship it.
Comment 19 Mozilla RelEng Bot 2011-12-27 11:20:28 PST
Try run for bb47358dee18 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=bb47358dee18
Results (out of 2 total builds):
    success: 2
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/tmielczarek@mozilla.com-bb47358dee18
Comment 20 Ted Mielczarek [:ted.mielczarek] 2011-12-27 11:26:08 PST
If someone who can reproduce the problem would like to test the build here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/tmielczarek@mozilla.com-bb47358dee18/try-win32/

Please let me know if it fixes the problem.
Comment 21 Tetsuro Kato (tete) 2011-12-27 17:08:16 PST
(In reply to Ted Mielczarek [:ted, :luser] from comment #20)
> Please let me know if it fixes the problem.

The problem is fixed in the try build on my Windows XP SP3.
Comment 22 Tetsuro Kato (tete) 2011-12-27 17:31:31 PST
In the future, isn't there a possibility that the other DLLs will be placed in the components directory?
Comment 23 Ted Mielczarek [:ted.mielczarek] 2011-12-28 05:22:09 PST
It's possible, but extremely unlikely. Also, if we switch to VC2010, this problem will go away because the VC2010 CRT does not use a SxS manifest.

Pushed to inbound:
http://hg.mozilla.org/integration/mozilla-inbound/rev/06648345488e
Comment 24 Matt Brubeck (:mbrubeck) 2011-12-28 11:14:41 PST
https://hg.mozilla.org/mozilla-central/rev/06648345488e
Comment 25 Ted Mielczarek [:ted.mielczarek] 2011-12-28 11:35:03 PST
Comment on attachment 584433 [details] [diff] [review]
don't embed a manifest referencing the CRT in browsercomps.dll

[Approval Request Comment]
Regression caused by (bug #): bug 678195
User impact if declined: Some browser functionality broken on some Windows XP systems (those without the Visual C++ 2005 runtime libraries installed system-wide).
Testing completed (on m-c, etc.): Tryserver builds tested, patch just landed on mozilla-central, so 12/29/2011 nightly builds should be tested.
Risk to taking this patch (and alternatives if risky): Low risk. No code changes involved, the patch simply stops the build system from embedding a resource in browsercomps.dll.
Comment 26 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-12-28 11:59:31 PST
Is this something QA can verify?
Comment 27 Ted Mielczarek [:ted.mielczarek] 2011-12-28 12:05:22 PST
Yes, you should be able to verify this if you have a stock Windows XP system. There are somewhat-STR in comment 0. Tete: can you give QA a more specific set of STR?
Comment 28 [:Cww] 2011-12-28 14:25:42 PST
(In reply to Mike Hommey [:glandium] from comment #7)
Total number of comments related to this pre-release: 18

http://input.mozilla.com/en-US/?q=url+valid&product=firefox&version=9.0&date_start=2011-10-01&date_end=2011-12-19

Got lost in the 30K total input requests we got.... that's why we didn't see this.
Comment 29 [:Cww] 2011-12-28 16:32:34 PST
Ted says this patch is really low risk (can you elaborate on what the possible risk is or is it not even risky enough for that?)

Since a lot of software redistributes the .NET Framework, it's not as common on SUMO/Input as one would expect BUT our current userbase is skewed towards early adopter types (and people who seek out updates) who are more likely to have such software.  I think this patch is a good candidate for a ridealong to a potential 9.0.2
Comment 30 Tetsuro Kato (tete) 2011-12-28 20:53:20 PST
I have confirmed the problem is fixed in the following tinderbox-build on my Windows XP SP3.

Mozilla/5.0 (Windows NT 5.1; rv:12.0a1) Gecko/20111228 Firefox/12.0a1 ID:20111228110518
Comment 31 Tetsuro Kato (tete) 2011-12-29 00:52:36 PST
When installing .NET Framework 2.0 SP1 or SP2 to Windows XP SP3, ".NET Framework CRT" is also installed and the problem is fixed in Firefox 9.0.1.
I could not uninstall ".NET Framework CRT" alone. I guess it is VC++ 2005 SP1 CRT.
Comment 32 Ted Mielczarek [:ted.mielczarek] 2011-12-29 04:30:41 PST
I gave the best summary I can imagine in comment 25. I'm not aware of any actual risk in this patch.
Comment 33 Tetsuro Kato (tete) 2011-12-29 06:05:39 PST
On my Windows XP, I checked by which version of .NET Framework the problem doesn't occur:

.NET Framework 2.0:     NG
.NET Framework 2.0 SP1: OK
.NET Framework 2.0 SP2: OK
.NET Framework 3.0:     NG
.NET Framework 3.0 SP1: OK (2.0 SP1 included)
.NET Framework 3.5:     OK (2.0 SP1 included)
.NET Framework 3.5 SP1: OK (2.0 SP2 included)
.NET Framework 4.0:     NG

From these results, to reproduce the problem on Windows XP, it's necessary to uninstall the following from Windows:

.NET Framework 2.0 SP1 or SP2
Visual C++ 2005 SP1 Redistributable Package
Comment 34 Tetsuro Kato (tete) 2011-12-29 14:13:47 PST
I have confirmed the problem was fixed in 12/29/2011 nightly build on my Windows XP SP3.

Mozilla/5.0 (Windows NT 5.1; rv:12.0a1) Gecko/20111229 Firefox/12.0a1 ID:20111229031056
Comment 36 Frank Wein [:mcsmurf] 2012-01-03 08:25:39 PST
*** Bug 714185 has been marked as a duplicate of this bug. ***
Comment 37 Ioana (away) 2012-01-13 08:14:04 PST
Verified using Tete's steps on:
Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20100101 Firefox/10.0 (20120111092507)

The issue doesn't reproduce anymore, except that the number of items in "about:about" is still decreased - "about:neterror" is missing. Is this by design or is it a bug?
Comment 38 Loic 2012-01-13 14:19:34 PST
*** Bug 717974 has been marked as a duplicate of this bug. ***
Comment 39 Loic 2012-01-13 14:21:48 PST
Support thread about this bug: https://support.mozilla.org/en-US/questions/906369
Comment 40 Ioana (away) 2012-01-17 04:35:25 PST
From what can be read in the support thread, installing Visual C++ 2005 SP1 or .Net Framework 3.5 seems to solve the issue about the missing items in about:about.

My question stays valid though. Is this by design? Is it ok that if the user uninstalls both Visual C++ 2005 SP1 and .Net Framework 3.5, there are items missing from about:about?
Comment 41 Tetsuro Kato (tete) 2012-01-17 06:09:20 PST
(In reply to Ioana Budnar [QA] from comment #40)
> Is it ok that if the user
> uninstalls both Visual C++ 2005 SP1 and .Net Framework 3.5, there are items
> missing from about:about?

That is not enough to reproduce the problem on Firefox 9.0.1. A user also needs to uninstall .NET Framework 2.0 SP1 or SP2 because they have ".NET Framework CRT", which seems to be Visual C++ 2005 SP1 CRT.

When a user installs .NET Framework 3.5, .NET Framework 2.0 SP1 or SP2 is installed automatically.
Comment 42 tmax 2012-01-18 05:23:17 PST
I'm getting an C runtime error R6034 when trying to run NS_InitXPCOM2 to embed FF10 in my application. My Application is build using VC90 with auto generated and built in manifest file.

The error occurs because the manifest in browsercomps.dll is missing.
Comment 43 Ted Mielczarek [:ted.mielczarek] 2012-01-18 05:39:19 PST
You need to either have the CRT DLLs (+manifest) alongside your exe, or install the CRT redistributable package on the system.
Comment 44 tmax 2012-01-18 06:41:22 PST
A small Test.exe works if i put msvcrt80.dll + manifest in the same folder. 
But my real setup is a bit more difficult :

I start a java process which im communicating with a c++-dll.
This dll is calling NS_InitXPCOM2 then. 

it worked without any error up to firefox 9. But now with the changes made because of this bugzilla issue I can't get it working again.

Any hints on that ?
Comment 45 Ted Mielczarek [:ted.mielczarek] 2012-01-18 08:08:40 PST
Can you take this discussion to a newsgroup? It'll be better than doing it in bugzilla. If you can post the details of what you're trying to do to somewhere like dev.platform we can probably get you sorted out:
https://lists.mozilla.org/listinfo/dev-platform
Comment 46 Ioana (away) 2012-01-27 06:17:02 PST
Marking bug as verified per my previous comments and comment #43.
Comment 47 Ioana (away) 2012-02-02 08:07:49 PST
Verified as fixed using Tete's steps on:
Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0
Comment 48 Ioana (away) 2012-03-22 09:40:33 PDT
Verified as fixed using Tete's steps on:
Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20100101 Firefox/12.0
20120320212821

Note You need to log in before you can comment on or make changes to this bug.