I took a close look at my changes in 
desktop_capture_device_unittest.cc and it seems very unlikely to be related to those changes.

zijiehe@ could you please take a look at this? Based on the logs, it seems that you have seen this issue before?

Yes, the error log is newly added to the ScreenCapturerWinGdi, which is the capturer DesktopCaptureDevice is backed by default. Before webrtc change https://codereview.webrtc.org/2553353002, ScreenCapturerWinGdi will silently ignore the error, and return a white or black, I cannot quite remember :(, desktop frame. But considering in desktop_capture_device_unittest, it actually did not check the result returned, the test failed silently before. To the 0x00000005, it's access denied. But I cannot quite tell the reason of this return value, otherwise I would have fixed it already.

Since you do not actively check the capturer result, I think a reliable way to do in DesktopCaptureDeviceTest is to use fake DesktopCapturer implementations.
There is a FakeScreenCapturer implementation in desktop_capture_device_unittet.cc, or you can also try https://cs.chromium.org/chromium/src/third_party/webrtc/modules/desktop_capture/fake_desktop_capturer.h?q=fakedesktopcapturer&sq=package:chromium&l=34.

Adding sergeyu@ and miu@ hoping for additional comments from them.

I agree we could avoid running into this issue by using a fake DesktopCapturer implementation, but that would change the purpose of the test. Is the test supposed to be an integration test that verifies that desktop capture works on the supported platforms? Or is it a unit test that is supposed to test class DesktopCaptureDevice in isolation?

Sorry, I misunderstood the context, I thought you were the new owner of the DesktopCaptureDevice.
I have no background knowledge about DesktopCaptureDeviceTest. But the DesktopCaptureDeviceTest.Capture test does not check any pixels returned from DesktopCapturer, so I assume it only tests DesktopCaptureDevice itself instead of underlying DesktopCapturer. And it's also not reasonable to test DesktopCapturer in DesktopCaptureDeviceTest, they are covered by their own test cases. These are my two cents.
AFAICT, QiangChen@ has done some work recently on it, maybe he could provide more information.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/tools/build.git/+/bef4fdb2ad55bbe00d026723a88df417d303e057

commit bef4fdb2ad55bbe00d026723a88df417d303e057
Author: Takuto Ikuta <tikuta@google.com>
Date: Tue Jan 17 01:11:18 2017

Enable auto_reboot on Goma canary buildbot

CrWinGoma (goma canary bot) on chromium.fyi failed nearly one month.
https://build.chromium.org/p/chromium.fyi/builders/CrWinGoma

Reboot maybe fix the issue temporarily.

BUG=678864,679651

Change-Id: I8416460971e775ea8f173ae1f1ced833cf0428c3
Reviewed-on: https://chromium-review.googlesource.com/428595
Reviewed-by: Paweł Hajdan Jr. <phajdan.jr@chromium.org>
Reviewed-by: Yoshisato Yanagisawa <yyanagisawa@chromium.org>
Reviewed-by: Fumitoshi Ukai <ukai@chromium.org>
Reviewed-by: Shinya Kawanaka <shinyak@chromium.org>
Commit-Queue: Takuto Ikuta <tikuta@google.com>

[modify] https://crrev.com/bef4fdb2ad55bbe00d026723a88df417d303e057/masters/master.chromium.fyi/master.cfg

Won't be able to work on this for the foreseeable next weeks => marking as available