This happened for my CL twice today:
https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_ng/builds/241715
https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_ng/builds/241469

https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_ng/builds/244293

qyearsley@ and dpranke@ do you know whom I should cc or assign this bug to?

Hmm, it seems strange that this should happen only sometimes, since the message makes it sound like it's related to system config

This particular check is done here:
https://cs.chromium.org/chromium/src/content/shell/app/blink_test_platform_support_win.cc?l=58), and it checks:

  ::GetSystemMetrics(SM_CXVSCROLL) != 17

where ::GetSystemMetrics is from windows.h, SM_CXVSCROLL is "The width of a vertical scroll bar, in pixels." (https://msdn.microsoft.com/en-us/library/windows/desktop/ms724385(v=vs.85).aspx)

If it is related to system config, and not related to the patch, then maybe it's possible that some of the VM slaves are configured differently?

This same error is happening when running layout tests on a hi-dpi Windows 7 laptop:  bug 620271 .

As for who might be able to provide more help, I'm not entirely sure -- jochen@ touched this code back in the past, and might potentially know more?

Yup, that would be my guess, that there are some machines configured inconsistently.

hi-dpi laptops are definitely gonna fail, but regular machines/vms should normally be consistent.

I would see if you can track down which VMs things are failing on and see if they need to be reimaged or if there's some other reason they might be different from the other machines in the pool.

I wrote this code originally, but so you could assign it to me, but I wouldn't be able to get to it any time soon and it's really more likely an infra problem.

Another example:
https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_ng/builds/244900

It does sound like some of the VMs that back https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_ng are configured differently than others. This is something the Infra team should look into.

Looks like it's limited to the new ones added per https://bugs.chromium.org/p/chromium/issues/detail?id=617159 ?

Nope.  Here's an older one failing the same way:
https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_ng/builds/245019/steps/webkit_tests%20%28with%20patch%29/logs/stdio

This may or may not be the same issue as what we're seeing in  bug 623613 . Let's see if we can fix that first and come back to this.

I just hit this in the CQ here: https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_ng/builds/246065/steps/webkit_tests%20%28with%20patch%29/logs/stdio

Should I stay in a holding pattern until 623613 is fixed?

Nope, this isn't dependent on  bug 623613 , no need to wait. I believe that in the case of  bug 623613 , Dirk showed that if the Windows system configuration is changed to use the "Basic" theme, then the builder no longer fails the layout test system dependency check.

So, our current suspicion is that some of the VMs for win_chromium_rel_ng (the ones that are having this problem) are not using the "Basic" theme. This hasn't been confirmed yet though, and I'm not sure how to confirm or change this. Mike, do you know how to check this?

The build mentioned in comment #9 failed on slave vm203-m4 - friedman@ can you check what theme that vm is using?

Windows 7 Basic

I hit this twice today:

vm196-m4:
https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_ng/builds/251033/steps/webkit_tests%20%28with%20patch%29/logs/stdio

and vm680-m4:
https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_ng/builds/251004/steps/webkit_tests%20%28with%20patch%29/logs/stdio

Labs: Looks like vm196-m4 and vm680-m4 are misconfigured.  Is there a way to get puppet to ensure that the themes are set to Aero or Basic?

As an aside, why does the theme matter with webkit tests?

The webkit_tests are doing screen captures of browser windows, and in some cases the output depends on settings obtained from the theme, as indicated in the comment here:

https://cs.chromium.org/chromium/src/content/shell/app/blink_test_platform_support_win.cc?rcl=0&l=56

It's possible there may be a way to rewrite that.

 Issue 626680  has been merged into this issue.

Duplicate bug was on vm147-m4

Assigning to dba@ to see if he can help with the puppet config.

The issue was relating to the vm template, which was updated at some point to use the classic theme. I've corrected that for future deploys.

I tried to see if theres a way to enforce the "basic" theme with puppet, but everything I found would result with control panel staying open without a clean way to close it. Instead I just found which vms on win_chromium_rel_ng were set to the classic theme and swapped them to the basic one.

Excellent, much thanks :-)

TIL basic != classic