Closed Bug 713167 Opened 12 years ago Closed 12 years ago

Microsoft.VC80.CRT SideBySide errors, browsercomps.dll

Categories

(Firefox Build System :: General, defect)

x86
Windows XP
defect
Not set
major

Tracking

(firefox9 affected, firefox10+ verified, firefox11+ verified, firefox12 verified)

VERIFIED FIXED
mozilla12
Tracking Status
firefox9 --- affected
firefox10 + verified
firefox11 + verified
firefox12 --- verified

People

(Reporter: tete009+bugzilla, Assigned: ted)

References

Details

(Keywords: regression, verified-beta, Whiteboard: [qa!])

Attachments

(1 file, 3 obsolete files)

Attached image fx9_sxs_error_l.png (obsolete) —
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.
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.
Version: 9 Branch → Trunk
I have confirmed latest-trunk (firefox-11.0a1.en-US.win32) has the same problem.
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
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Component: General → Build Config
Keywords: regression
Product: Firefox → Core
QA Contact: general → build-config
Re-reading rules.mk, I was fairly certain we weren't supposed to embed manifests in DLLs unless we explicitly requested them?
Also Firefox 9.0.1 cannot open about:home when the problem has occurred.
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 ?
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.
Attached patch avoid to add manifest to dll (obsolete) — Splinter Review
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.
Attached patch avoid to add manifest to dll (obsolete) — Splinter Review
I upload it again.
Attachment #584380 - Attachment is obsolete: true
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.
Attachment #584380 - Flags: review-
(In reply to Ted Mielczarek [:ted, :luser] from comment #12)
> In fact, browsercomps.dll should be linked with the static CRT.

Er, why?
bug 376041. Looks like I fiddled this in bug 422360 though, which is why it broke when we stopped building our own CRT.
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.
(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.
Like this. I pushed this to try, so there should be builds to test soon.
Attachment #584382 - Attachment is obsolete: true
Attachment #583990 - Attachment is obsolete: true
Attachment #584433 - Flags: review?(khuey)
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.
Attachment #584433 - Flags: review?(khuey) → review+
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
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.
Assignee: nobody → ted.mielczarek
Status: NEW → ASSIGNED
(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.
In the future, isn't there a possibility that the other DLLs will be placed in the components directory?
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
https://hg.mozilla.org/mozilla-central/rev/06648345488e
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla12
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.
Attachment #584433 - Flags: approval-mozilla-beta?
Attachment #584433 - Flags: approval-mozilla-aurora?
Is this something QA can verify?
Whiteboard: [qa?]
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?
(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.
Attachment #584433 - Flags: approval-mozilla-beta?
Attachment #584433 - Flags: approval-mozilla-beta+
Attachment #584433 - Flags: approval-mozilla-aurora?
Attachment #584433 - Flags: approval-mozilla-aurora+
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
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
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.
I gave the best summary I can imagine in comment 25. I'm not aware of any actual risk in this patch.
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
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
Target Milestone: mozilla10 → mozilla12
Blocks: 714495
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?
Support thread about this bug: https://support.mozilla.org/en-US/questions/906369
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?
(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.
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.
You need to either have the CRT DLLs (+manifest) alongside your exe, or install the CRT redistributable package on the system.
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 ?
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
Marking bug as verified per my previous comments and comment #43.
Status: RESOLVED → VERIFIED
Status: VERIFIED → RESOLVED
Closed: 12 years ago12 years ago
Keywords: verified-beta
Whiteboard: [qa?] → [qa+][qa:10!]
Verified as fixed using Tete's steps on:
Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0
Whiteboard: [qa+][qa:10!] → [qa+][qa:10!][qa:11!]
Verified as fixed using Tete's steps on:
Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20100101 Firefox/12.0
20120320212821
Status: RESOLVED → VERIFIED
Whiteboard: [qa+][qa:10!][qa:11!] → [qa!]
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.