453260 - Not all win32 slaves disable debugging properly

Status: RESOLVED WORKSFORME

(Release Engineering :: General, defect, P3)

Description

[Nick Thomas [:nthomas] (UTC+12)]

Definitely qm-win2k3-moz2-01 (and maybe moz2-win32-slave06 and other recently created VMs) get stuck when executables crash out, prompting to terminate or debug. The app is still holding its locks to other executables at this point, which does bad things to subsequent runs when they try to update these files.

It looks like
  https://wiki.mozilla.org/ReferencePlatforms/Win32#Disable_JIT_Debugger
has already been done so I'm not sure what's happening here. Some Google results suggest that renaming vsjitdebugger.exe but it's not clear if this a reliable fix.

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

I noticed (over in bug 460535) that the reference platform didn't have 
  HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework\DbgJITDebugLaunchSetting
set to 1 (which dumps a stack), but to octal 10 (which throws the dialog for interactive processes, otherwise spawns the debugger). I've updated the reference platform to value 1, and now we need to go through moz2-win32-slave1-->18 and update them all. It's unclear at this stage if a reboot is required.

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

Actually, slave1 has the octal 10 setting too, so this appears to be a red-herring.

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

Rolling out bug 420216 makes this a nuisance only (we can kill crashed processes, and just get harmless dialogs hanging round). I have dumps of the registry from moz2-win32-slave01 and 06 if anyone is interested in digging further.

Comment 4

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Havent seen this in a while - reopen if we hit this again.

Comment 5

[Chris Cooper [:coop] (he/him)]

Moving closed Future bugs into Release Engineering in preparation for removing the Future component.