491488 - latest trunk 2009-05-05-03-> tb nightly fails to start with 'missing msvcr80.dll' error

Status: VERIFIED FIXED

(Thunderbird :: Build Config, defect)

Description

[klonos]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090503 Minefield/3.6a1pre (.NET CLR 3.5.30729)
Build Identifier: 

Long time since win32 nightlies had an update (since 04.19.2009 while mac and linux updates exist in the meantime) and finally 05.05.2009 is out.

Installed it and after restart it complained about missing msvcr80.dll. The file is in my system (3 different versions under C:\WINDOWS\WinSxS\) and copying it to either thunderbird's installation folder or C:\WINDOWS\ (I know... it's not the way to go, but for bug testings' sake) spits another error saying that the application failed to start '(0x80000003)'... whatever. If there is need to do so, I can translate the exact error messages (I'm running Greek OS) or even try it out in a Eng windows installation and post the actual error msgs. Let me know.

I tried both updating through the application and also by downloading and running the complete installer.exe from http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/... , but same thing happens every time.

... Anyways, reverting to 2009-04-19-05 solves the issue. Something must have gone wrong in the build I guess.

PS: If someone knows what prevents win32 nightlies from being built please explain or point to the bug.


Reproducible: Always

Steps to Reproduce:
1. simply update your win32 nightly to the latest 05-05-03 build and you'll see what I mean.

Actual Results:  
Application fails to start (or restart if the update was done through the application).


Expected Results:  
Should start or restart without any error messages.


(In order to update through the application I use the 'update channel selector' extension)

Comment 1

[Ludovic Hirlimann [:Usul]]

So this worked for me on vista and I ended up with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b5pre) Gecko/20090505 Shredder/3.0b3pre.

Issue seems to be the registration of the dll.

Comment 2

[Mark Banner (:standard8)]

Ok, I guess something is still busted after my fix for bug 489975. I'll take a look at this a bit later.

Comment 3

[[e-mail]]

Might be related:
trying to start today's (05.05.09) TB 3.1a1pre build ends up with an error:

Application could not be initialised properly (0xc0000142). 
[Translation might be slightly different though, I'm on German windows.]

Comment 5

[Mark Banner (:standard8)]

Update: I know what the issue is - the LDAP dlls aren't being linked correctly with jemalloc. I'm working on a patch for that.

(In reply to comment #0)
> PS: If someone knows what prevents win32 nightlies from being built please
> explain or point to the bug.

There was a problem with the build machines also compounded by an additional build problem (bug 489975), we fixed bug 489975 at the same time as we think we have fixed the problem with the build machines.

Comment 6

[Mark Banner (:standard8)]

The patch which will hopefully fix this is in bug 491545 - I haven't tested it yet.

Comment 7

[klonos]

(In reply to comment #1)
> So this worked for me on vista and I ended up with Mozilla/5.0 (Windows; U;
> Windows NT 6.0; en-US; rv:1.9.1b5pre) Gecko/20090505 Shredder/3.0b3pre.
> 
> Issue seems to be the registration of the dll.

I am talking about thunderbird 3.1a1pre comm central trunk nightlies, not 3.0x builds. I haven't tested those at all. Haven't tested on Vista either, I will as soon as I have some time to setup some VMs.

When you say that it seems to be a .dll registration issue, do you mean that simply a 'regvr32 mssvc80.dll' command solved the issue for you, or what then?

(In reply to comment #3)
> Might be related:
> trying to start today's (05.05.09) TB 3.1a1pre build ends up with an error:
> 
> Application could not be initialised properly (0xc0000142). 
> [Translation might be slightly different though, I'm on German windows.]

Same error with error code (0x80000003) though in Greek WinXP32. This happens when you have a copy of the msvcr80.dll in a directory that exists in your system's %PATH% variable (for example in your C:\WINDOWS\ or your C:\WINDOWS\System32\) or in thunderbird's installation directory.

My guess here is that you had a similar issue with some other application in the past and in order to solve it you've placed a copy of the .dll in one of the C:\WINDOWS\ or C:\WINDOWS\System32\ folders. If this is the case and there exists a version of the dll some place else than the C:\WINDOWS\WinSxS\ folder (some of it's subfolders to be exact), you get this error instead of the missing .dll error.

This is what most pages on the net guide you to do to get these missing .dll issues resolved. It is such a wrong way to go... don't get me started. This is not the right place to discuss this though. If you want more info on why you shouldn't simply place copies of .dlls elsewhere than where supposed to be, please see here (a fast google search spat this):

http://www.instant-registry-fixes.org/why-do-i-keep-receiving-msvcr80dll-missing-errors/

...where is says:

'...If you look for a solution to this error, you may be asked to download the latest version of the MSVCR80.dll file from the Web and copy it to the C:\System32 folder. However, this is not the correct solution. ...'

and explains why and what.

Comment 8

[Mark Banner (:standard8)]

klonos: No need for more testing, the problem is the application is being linked against the wrong dlls, I have a fix in progress that I'm currently testing out (as per comment 5 and 6).

Comment 9

[klonos]

ok Mark, was about to post about 2009-05-06-05 having the same issue. Now will wait for the fix.

Just a question though... if/once such an issue is detected and a bug is filed, don't you have a way to stop new versions from being built + perhaps remove the build with the issue from the ftp until we have one that at least starts? ... I mean since updating will cause such issues with win32 builds even not being able to start after install/update, I see no reason for them to exist there. This way, having extensions such as the Update Channel Selector will not mess our testing environment, since we would be offered an update only after the issue was gone.

Comment 10

[Mark Banner (:standard8)]

(In reply to comment #9)
> Just a question though... if/once such an issue is detected and a bug is filed,
> don't you have a way to stop new versions from being built + perhaps remove the
> build with the issue from the ftp until we have one that at least starts? ... 

This is a very rare situation. Normally with bustages we know about it quick and we can fix and respin within a few hours.

In this case the builds were broken for various reasons anyway for quite a while, and I did briefly think about stopping builds/removing the new one, but this will hopefully be fixed in a few days - in any case the only difference between 3.1a1pre and 3.0b3pre is the fact that we're building with a different version of the core gecko/toolkit. Hence from a Thunderbird perspective we'd like these builds not to be broken, but for a few days it doesn't matter because we're focusing 99.9% of our effort on getting Thunderbird 3 out the door and there's no specific dev going into 3.1a1pre.

Comment 11

[klonos]

I see now. Thanks for taking the time to explain.

Comment 12

[Mark Banner (:standard8)]

The fix for the blocking bug is checked into the LDAP c-sdk, and we've now upgraded Thunderbird/SeaMonkey to use the latest version of the LDAP c-sdk:

http://hg.mozilla.org/comm-central/rev/eed393b2e3af

For future reference the changes in this upgrade were:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=%2Fmozilla%2Fdirectory%2Fc-sdk%2F&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2009-05-08+02%3A41&maxdate=2008-09-11+09%3A08&cvsroot=%2Fcvsroot

The upgrade fixes this start up bug as well - I've checked an hourly build, I'm currently trying to generate a new nightly to pick up this fix.

Comment 13

[klonos]

ok, verifying fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090404 Lightning/1.0pre Shredder/3.1a1pre ID:20090509032325

FTR the 2009-05-08-03 build is the last non-working with the very next 2009-05-08-07 (same day) where the bug is fixed.

(last working build before the bug emerged was 2009-04-19-05... lots of patches committed since ... lots of bug-testing to do now)

Comment 14

[Rob]

Broken in http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mobile-trunk/fennec-1.0b5pre.en-US.win32.zip .

I fixed this by copying VMWare's msvcr80.dll (Version: 8.0.50727.762, from "vCenter Converter Standalone") to Fennec's executable's directory.

Rob

Comment 15

[Phil Ringnalda (:philor)]

This is a long-since fixed Thunderbird bug - if you see something with the same symptom in Fennec, please file a Fennec bug.