Repros locally like so (use @google for auth):

C:\src\chrome\src>> python tools\swarming_client\auth.py login --service=https://isolateserver.appspot.com

C:\src\chrome\src>python tools\swarming_client\isolateserver.py download -I https://isolateserver.appspot.com --namespace default-gzip -s ded70ee03c1e229d491ec8dcb9610a3703b83780 --target foo

C:\src\chrome\src>cd foo\out\Release

C:\src\chrome\src\foo\out\Release>C:\python_27_amd64\files\python.exe ..\..\testing\test_env.py ./remoting_unittests.exe --brave-new-test-launcher --test-launcher-bot-mode --asan=0 --msan=0 --tsan=0

Looking at `file remoting_unittests.exe` and `file *.dll`, it looks like all files in that archive are 32-bit binaries except for libEGL.dll and libGLESv2.dll, which are 64-bit somehow:

libEGL.dll:                                    PE32+ executable (DLL) (console)                                                           x86-64, for MS Windows
libGLESv2.dll:                                 PE32+ executable (DLL) (console)                                                           x86-64, for MS Windows


That explains the error -- now, why did this happen?

IIRC we only build 32-bit chromoting binaries. Not sure why 64-bit angle binaries are pulled in. CC'ed joedow@ since he may know more about the Windows build set up.

If you want an urgent fix for this issue, I can just disable the OpenGL unittest on Windows.

We don't need an urgent fix, just want to figure it out eventually.

With respect to 32-bit and 64-bit binaries.  We don't currently package/ship 64-bit binaries but we may want to in the future (a likely scenario is that we find a capture or compression algorithm that greatly benefits from an increase in bitness).  We wouldn't want to try and get everything building again (also it wouldn't be possible to test/compare anyway) so we want to continue building and testing our components with 64-bit builds to allow us the choice and flexibility in the future.

Aha, the 32-bit debug lld bot doesn't run tests.

I'm guessing lld defaults to 64 bits somewhere. If it has a good reason to do so, we need to add an explicit /arch:x86 in a good place (close to the -m32 / -m64); else this is an lld bug. I'll try to find out what's happening.

Buildling 'libGLESv2' or 'libEGL' locally with the same args.gn as the bot does produce a 32-bit dll. Hm.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/781204305cdc8bb696fb9b068b03cbd3d1b51a26

commit 781204305cdc8bb696fb9b068b03cbd3d1b51a26
Author: Nico Weber <thakis@chromium.org>
Date: Mon Aug 29 19:44:47 2016

Spell dbg lld win bot names correctly in json file listing tests.

The debug bots have strange names due to path name limitations.
I got this wrong in https://codereview.chromium.org/1948593003/

I happened to notice that 'cause tests currently fail on 32-bit LLD
builds, but the debug 32-bit bot was happy when it shouldn't
have been.

BUG= 642027 
R=hans@chromium.org

Review URL: https://codereview.chromium.org/2294513002 .

Cr-Commit-Position: refs/heads/master@{#415026}

[modify] https://crrev.com/781204305cdc8bb696fb9b068b03cbd3d1b51a26/testing/buildbot/chromium.fyi.json

Is the cl in #8 expected to fix this, or will it just make the test run (and fail) on the bots that were previously unaffected?

The latter.

Sergey, both the linked CLs are yours; could you take a look?

I reviewed these CL, but they aren't mine. After https://codereview.chromium.org/2196493002 we have unittests that depend on OpenGL. This code is not likely to be useful on Windows ever, so potentially we could just disabled them there. OTOH it may still be useful to figure out what happens there. libGLESv2 comes from third_party/angle.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/408c95610a59dec6ff6321809b51e13eb356e064

commit 408c95610a59dec6ff6321809b51e13eb356e064
Author: yuweih <yuweih@chromium.org>
Date: Thu Sep 08 23:46:09 2016

[Remoting Client] Disable OpenGL renderer on Windows

CL 2196493002 brought ANGLE libGLESv2 dependency to the remoting unittest on
Windows. For some reason the Windows clang tester built 64-bit unittest
binary but tries to link it with a 32-bit ANGLE binary. Since the OpenGL
renderer is not used on Windows anyway, we may just disable the unit test on
Windows until we figure out what went wrong with the build setup.

BUG= 642027 

Review-Url: https://codereview.chromium.org/2303883004
Cr-Commit-Position: refs/heads/master@{#417440}

[modify] https://crrev.com/408c95610a59dec6ff6321809b51e13eb356e064/remoting/client/BUILD.gn

Hi thakis@, we have disabled the renderer test on Windows. Could you verify that remoting_unittests won't crash now?

Yes, the bot is happy now.

We still don't understand the linking thing though. Should we have a separate bug for that, or should we keep this open for that?

I don't have a strong opinion. You can reopen this bug and assign this to somebody in charge of porting ANGLE if you like.