1279167 - Disable Windows Error Reporting for TaskCluster Windows worker types

Status: RESOLVED INCOMPLETE

(Taskcluster :: Workers, defect)

Description

[Pete Moore [:pmoore][:pete]]

In bug 1269809 we hit a bug whereby a build would appear to hang, because a dialogue window would pop up with an error message during a Windows build.

This requires somebody to click a button in order for the task to continue.

In some ways this is a good thing - certainly when troubleshooting, it means you can run ProcessExplorer, for example, and find the details about the exact process spawned by the build task that has caused the problem. On the downside though, it leaves the worker running the task until it times out, rather than failing quickly.

Therefore we should probably disable the Windows Error Reporting so that tasks don't have it on by default. Ideally we'd leave it enabled for interactive sessions when we support interactive sessions at some point in the future.

I'm in two minds about this, because tasks might sometimes gloss over errors, so you might end up getting green runs when there was a serious problem, if the task isn't handling the error correctly.

Note: the implementation is trivial - there is a powershell command `Disable-WindowsErrorReporting` which can be added to the userdata run when creating the AMIs for the worker type.

Comment 1

[Pete Moore [:pmoore][:pete]]

See https://technet.microsoft.com/en-us/library/jj590826%28v=wps.630%29.aspx

Comment 2

[Dustin J. Mitchell [:dustin] (he/him)]

Pete, can we either do this or close the bug?

Comment 3

[Pete Moore [:pmoore][:pete]]

I'll have a look at this next week. I need to revisit this topic. Thanks for the reminder!

I'll leave the needinfo open, so I don't forget. ;)

Comment 4

[Pete Moore [:pmoore][:pete]]

I never really got to the bottom of this. The problem disappeared, and it wasn't quite clear to me if it was really needed or not. Rather than implement it, and not appreciate the full implications, I'd prefer to close, and revisit if this becomes an issue again in the future.

I'm going to mark as "incomplete" since the full scope of impact was never established, so it is not clear if it would be a good or a bad thing to implement, at this time.