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.

This is the only remaining blocker for being able to say that MSVC 2010 builds pass our regression and performance testing suites.

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

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

Comment on attachment 574893 [details] [diff] [review] OPSI package Worked as expected in staging!

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.

Comment on attachment 574893 [details] [diff] [review] OPSI package http://hg.mozilla.org/build/opsi-package-sources/rev/4905e94f93e5

(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

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

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]

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.