Install VC++ 2010 debug CRT on talos slaves

RESOLVED FIXED

Status

Release Engineering
Other
P3
normal
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: ted, Assigned: rail)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
In the same way that bug 562459 installed the VC8 debug CRT, we need to install the VC10 debug CRT so we can run tests on VC10-produced debug builds.

I haven't looked to see if Microsoft gives us an easy way to do this like they did with the VC8 install. I'll take this bug to figure that out before someone in RelEng takes it.
(Reporter)

Updated

6 years ago
Assignee: nobody → ted.mielczarek
This is the only remaining blocker for being able to say that MSVC 2010 builds pass our regression and performance testing suites.
(Assignee)

Updated

6 years ago
Assignee: ted.mielczarek → rail
Priority: -- → P3
(Assignee)

Comment 2

6 years ago
Just to confirm: do we need just 2 dlls (msvcp100d.dll and msvcr100d.dll)? Do we need any of mfc*d.dll libs?
(Reporter)

Comment 3

6 years ago
Okay, I looked back at what I did in bug 562459 and my local VC10 install, and this should work:

a) On a build slave:
  1) Download msm2msi from http://www.ethalone.com/articles/61-using-windows-installer-merge-modules-in-ghost-installer-studio.html
  2) Run msm2msi.exe "C:\Program Files\Common Files\Merge Modules\Microsoft_VC100_DebugCRT_x86.msm", which should produce Microsoft_VC100_DebugCRT_x86.msi in the same "Merge Modules" directory.

b) On a Talos slave:
  3) Install the resulting msi on the Talos slave (msiexec /i Microsoft_VC100_DebugCRT_x86.msi)

(I haven't tested these personally, but these are basically the exact steps we used for VC8, from bug 562459 comment 25)
For win7 slaves I had to deploy the DebugCRT manually through RDP/VNC:
https://bugzilla.mozilla.org/show_bug.cgi?id=562459#c41

For XP it was easier:
http://hg.mozilla.org/build/opsi-package-sources/rev/9126788ed78a
(Assignee)

Comment 5

6 years ago
Created attachment 574893 [details] [diff] [review]
OPSI package
(Assignee)

Comment 6

6 years ago
Comment on attachment 574893 [details] [diff] [review]
OPSI package

Worked as expected in staging!
Attachment #574893 - Flags: review?(armenzg)
Comment on attachment 574893 [details] [diff] [review]
OPSI package

This looks good.

The only neat I have is if you could use a different log to output to ("c:\tmp\vcdebugcrt_x86.log") so it does not get reused for both packages (not that we look at these that often). I am OK either way.
Attachment #574893 - Flags: review?(armenzg) → review+
(Assignee)

Comment 8

6 years ago
Comment on attachment 574893 [details] [diff] [review]
OPSI package

http://hg.mozilla.org/build/opsi-package-sources/rev/4905e94f93e5
Attachment #574893 - Flags: checked-in+
(Assignee)

Comment 9

6 years ago
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #7)
> The only neat I have is if you could use a different log to output to
> ("c:\tmp\vcdebugcrt_x86.log") so it does not get reused for both packages
> (not that we look at these that often). I am OK either way.

Fixed in http://hg.mozilla.org/build/opsi-package-sources/rev/63e96c8b7308
(Assignee)

Comment 10

6 years ago
The libs have been deployed on w7 and xp talos slaves and ref machines with the following exceptions:

talos-r3-w7-024: bug 696280
talos-r3-w7-036: bug 685879
talos-r3-w7-053: bug 703639
talos-r3-xp-045: bug 661377
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
This could have caused bug 703996.

[12:24pm] mak: ah thank you, was not aware of it
[12:24pm] mak: fwiw, should be easy to disable dwwin from starting, it's a regedit change though
[12:24pm] mak: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug
[12:24pm] lsblakk|afk is now known as lsblakk.
[12:27pm] armenzg: what we don't know is what triggered this to start happening
[12:27pm] armenzg: nothing changed on the machines except perhaps the DebugCRT for VS2010
[12:27pm] mak: I suppose (but can't tell) a crash
[12:28pm] armenzg: oh!
[12:28pm] armenzg: perhaps the registry got modified with the DebugCRT
[12:29pm] mak: so installing it set back an automatic debugger?

If you search for AeDebug:
http://mxr.mozilla.org/build/search?string=AeDebug
that we forgot to remove the key:
    12 [Registry_delete_JIT_debugging]
    13 deleteKey [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger]
    14 deleteKey [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\DbgManagedDebugger]
(Assignee)

Comment 12

6 years ago
I checked those registry keys after deploying and they were absent. To be sure I've just checked the keys on some xp and w7 talos machines and they still absent.
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.