Issue 625065  has been merged into this issue.

Seeing the same thing here, running Windows 10 on two different machines, one desktop and one Optimus laptop. A fresh install of version 2785 worked fine, but after restarting it once I got the black screen (possibly due to update to 2786, but can't confirm).

Ken, can you get this bug to the right people?

I am the one who reported this first. I have found a solution, or rather a workaround:
1. Launch Canary. You should get the black screen.
2. Resize the Canary main window so that it is no longer maximized. Make it smaller.
3. Relaunch Canary. You should no longer get the black screen, and Canary should be working “normally”.

Unfortunately, you will get the black screen again if you shut down Canary. You’ll need to resize the main window again, before relaunching Canary.

Wow that simple.  It worked, thanks.

Submitter or Olli, could you please provide about:gpu from the affected Canary instance if at all possible? The Chrome 51 version in the bug submission clearly isn't Canary.

John, could you please take this and try to reproduce?

Mine actually is Canary, Version 53.0.2785.0 canary (64-bit)

The version of Canary affected by this on my Windows 10 system (64-bit) is Version 53.0.2785.0 canary (64-bit)

 Issue 625189  has been merged into this issue.

 Issue 625255  has been merged into this issue.

Ok, I can see this on my windows 10 machine. Currently working on bisecting.

Happens the same to me. However I can workaround this by simply minimizing the window and then from the chrome canary icon on the taskbar open a new window.

 Issue 625273  has been merged into this issue.

You are probably looking for a change made after 403320 (known good), but no later than 403341 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/50d0615528c167f0dd996dc03598590bfbb6d69f..840bb0f5eda052f9d0da148ced3a04610c4dc02d

https://chromium.googlesource.com/chromium/src/+/c110f1855d378172bcb74e0c26640bfc0d35d02d%5E%21/#F0 and https://chromium.googlesource.com/chromium/src/+/39ec034d1110e65d77481e1362c8f4ba6429f7fb seem pretty suspicious. I'm going to try building without those to see.

https://chromium.googlesource.com/chromium/src/+/c110f1855d378172bcb74e0c26640bfc0d35d02d%5E%21/#F0 was reverted in https://codereview.chromium.org/2115963002/ because of this problem.

 Issue 625046  has been merged into this issue.

There does indeed seem to be an issue here. The widget layout appears to be sensible for the selected widgets I saw and I'm at the compositor level trying to figure out why we aren't painting anymore.

Adjusting some flags since the change has been reverted.

This black screen problem is still happening after latest update Version 53.0.2785.1 canary (64-bit)

Yeah, I think we'll need to merge this fix to M53.

That should be picked up by today's branch, shouldn't it?

I stand corrected. Looks like we branched yesterday.

 http://crbug.com/625046  merged the revert to the release branch, clearing ReleaseBlock here.

Version 53.0.2785.3 canary (64-bit) solved this problem for me on Windows 10 64-bit. Thanks.

Good work,  Report an issue
Version 54.0.2786.0 canary (64-bit) working fine.
Thanks.

The issue is enabling-per-monitor-dpi subtly changes when the Window is shown.

BrowserView::Show contains this code:
  // If the window is already visible, just activate it.
  if (frame_->IsVisible()) {
    frame_->Activate();
    return;
  }

Because in per-monitor DPI the frame is already visible, it just activates the frame, failing to actually show the contents.

This code path is getting triggered during the maximize call within the Windows kernel when per monitor DPI is enabled:
0: kd>  # ChildEBP RetAddr
00 a1ca78dc 9048faba win32kfull!xxxSendTransformableMessageTimeout
01 a1ca7900 904861e7 win32kfull!xxxSendMessage+0x20
02 a1ca7968 904a9672 win32kfull!xxxInitSendValidateMinMaxInfoEx+0x1db
03 a1ca7a64 904f1e74 win32kfull!xxxMinMaximizeEx+0x408
04 a1ca7a7c 9046ab31 win32kfull!xxxShowWindowViaMinMax+0x14
05 a1ca7ad4 90520123 win32kfull!xxxShowWindowEx+0x29f
06 a1ca7ae0 90453f7e win32kfull!xxxShowWindow+0x15
07 a1ca7b14 9048eeaa win32kfull!xxxSysCommand+0x526
08 a1ca7ba0 9048e806 win32kfull!xxxRealDefWindowProc+0x5d2
09 a1ca7bc0 904906a7 win32kfull!xxxWrapRealDefWindowProc+0x40
0a a1ca7bf0 82337717 win32kfull!NtUserMessageCall+0x97
0b a1ca7bf0 775c1400 nt!KiSystemServicePostCall
0c 0014dfd8 76fb9d5a ntdll!KiFastSystemCallRet
0d 0014dfdc 76f97f70 USER32!NtUserMessageCall+0xa
0e 0014e060 76f97b24 USER32!RealDefWindowProcWorker+0x1a0
0f 0014e074 730b5d64 USER32!RealDefWindowProcW+0x34
10 0014e094 730b4275 uxtheme!DoMsgDefault+0x3a
11 0014e0a4 730bd9ce uxtheme!OnDwpSysCommand+0x35
12 0014e118 730bd0f8 uxtheme!_ThemeDefWindowProc+0x8be
13 0014e12c 76f97c9a uxtheme!ThemeDefWindowProcW+0x18
14 0014e184 5da74027 USER32!DefWindowProcW+0x14a
15 0014e1c4 5c990b2b chrome_5c6e0000!views::HWNDMessageHandler::OnSysCommand+0x15c
16 0014e1f0 5c99041a chrome_5c6e0000!views::HWNDMessageHandler::_ProcessWindowMessage+0x5f7
17 0014e230 5c7bf17c chrome_5c6e0000!views::HWNDMessageHandler::OnWndProc+0x6a
18 0014e248 5c7bf040 chrome_5c6e0000!gfx::WindowImpl::WndProc+0x57
19 0014e28c 76fb5b83 chrome_5c6e0000!base::win::WrappedWindowProc<&gfx::WindowImpl::WndProc>+0x25
1a 0014e2b8 76f99d1a USER32!_InternalCallWinProc+0x2b
1b 0014e350 76f9923a USER32!UserCallWinProcCheckWow+0x1aa
1c 0014e3ac 76f98fe7 USER32!SendMessageWorker+0x1da
1d 0014e3d4 5da730ac USER32!SendMessageW+0xe7
1e 0014e3ec 5da7367a chrome_5c6e0000!views::HWNDMessageHandler::ExecuteSystemMenuCommand+0x1c
1f 0014e3f4 5c98bf82 chrome_5c6e0000!views::HWNDMessageHandler::Maximize+0xa

Adjust component as this is more or less root caused.
Quick Summary:
Chrome is able to somehow avoid window show during maximization. This changes when per-monitor DPI is enabled and user32 shows the window before BrowserView::Show expects.

We lose the WS_MAXIMIZE but here:

3: kd> g
97617feb  06                                               .
 # ChildEBP RetAddr  
00 b1817e9c 9048f69b win32kfull!xxxSetWindowStyle+0x206
01 b1817ef0 9048f569 win32kfull!xxxSetWindowData+0x29
02 b1817f14 9048f4d1 win32kfull!xxxSetWindowLong+0x7b
03 b1817f3c 82337717 win32kfull!NtUserSetWindowLong+0x59
04 b1817f3c 775c1400 nt!KiSystemServicePostCall
05 0014de40 76fba4aa ntdll!KiFastSystemCallRet
06 0014de44 76f94b95 USER32!NtUserSetWindowLong+0xa
07 0014de70 76f94ab5 USER32!_SetWindowLong+0xd5
08 0014de80 5c9ea387 USER32!SetWindowLongW+0x15
09 0014deb8 5da73895 chrome_5c6e0000!views::HWNDMessageHandler::SetBoundsInternal+0x2e
0a 0014df9c 5c990661 chrome_5c6e0000!views::HWNDMessageHandler::OnDpiChanged+0x89
0b 0014dfcc 5c99041a chrome_5c6e0000!views::HWNDMessageHandler::_ProcessWindowMessage+0x12d
0c 0014e00c 5c7bf17c chrome_5c6e0000!views::HWNDMessageHandler::OnWndProc+0x6a
0d 0014e024 5c7bf040 chrome_5c6e0000!gfx::WindowImpl::WndProc+0x57
0e 0014e068 76fb5b83 chrome_5c6e0000!base::win::WrappedWindowProc<&gfx::WindowImpl::WndProc>+0x25
0f 0014e094 76f99d1a USER32!_InternalCallWinProc+0x2b
10 0014e12c 76f99af5 USER32!UserCallWinProcCheckWow+0x1aa
11 0014e188 76fa871c USER32!DispatchClientMessage+0xb5
12 0014e1b8 775c1336 USER32!__fnINOUTLPRECT+0x3c
13 0014e1f4 76fba5ba ntdll!KiUserCallbackDispatcher+0x36
14 0014e1f8 5c7be30b USER32!NtUserEnableChildWindowDpiMessage+0xa
15 0014e25c 5c99012c chrome_5c6e0000!gfx::WindowImpl::Init+0x128
16 0014e2ac 5c98fb7a chrome_5c6e0000!views::HWNDMessageHandler::Init+0xa2
17 0014e2d8 5c98cc35 chrome_5c6e0000!views::DesktopWindowTreeHostWin::Init+0xa4
18 0014e2f8 5c98c6df chrome_5c6e0000!views::DesktopNativeWidgetAura::InitNativeWidget+0xee
19 0014e3f0 5c98bed5 chrome_5c6e0000!DesktopBrowserFrameAura::InitNativeWidget+0x5e
1a 0014e520 5c98a540 chrome_5c6e0000!views::Widget::Init+0x2cb
1b 0014e638 5c989cfb chrome_5c6e0000!BrowserFrame::InitBrowserFrame+0x10f
1c 0014e664 5c9867b5 chrome_5c6e0000!BrowserWindow::CreateBrowserWindow+0x5b
1d (Inline) -------- chrome_5c6e0000!?A0x1225b5be::CreateBrowserWindow+0x6
1e 0014e70c 5d5f3637 chrome_5c6e0000!Browser::Browser+0x643
1f 0014e7e8 5d5f339f chrome_5c6e0000!chrome::OpenEmptyWindow+0x46

void HWNDMessageHandler::SetBoundsInternal(const gfx::Rect& bounds_in_pixels,
                                           bool force_size_changed) {
  LONG style = GetWindowLong(hwnd(), GWL_STYLE);
  if (style & WS_MAXIMIZE)
    SetWindowLong(hwnd(), GWL_STYLE, style & ~WS_MAXIMIZE);

Commenting out the WS_MAXIMIZE removal fixes the problem and keeps the old behavior.

Code introduced in
https://chromium.googlesource.com/chromium/src/+/2b107a348f2b27934fe38680ec8010d743f61765

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

commit 8e164fb9b1df48c5e01540190a108eaaad86feca
Author: robliao <robliao@chromium.org>
Date: Thu Jul 21 22:09:32 2016

Only Update the Scale Factor if the Scale Factor Actually Changed

WM_DPICHANGED may fire when the DPI hasn't actually changed. This occurs
during initialization with an interaction from EnableChildWindowDpiMessage.
For maximized windows, this causes the bounds logic to unset WS_MAXIMIZE from
the HWND, which leads to WM_SYSCOMMAND with SC_MAXIMIZE prematurely showing the
window, and short-circuting BrowserView::Show() causing it to skip showing the
contents of the window because the frame is already visible.

BUG= 625076 

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

[modify] https://crrev.com/8e164fb9b1df48c5e01540190a108eaaad86feca/ui/display/win/screen_win.cc
[modify] https://crrev.com/8e164fb9b1df48c5e01540190a108eaaad86feca/ui/display/win/screen_win.h
[modify] https://crrev.com/8e164fb9b1df48c5e01540190a108eaaad86feca/ui/display/win/screen_win_unittest.cc
[modify] https://crrev.com/8e164fb9b1df48c5e01540190a108eaaad86feca/ui/views/win/hwnd_message_handler.cc
[modify] https://crrev.com/8e164fb9b1df48c5e01540190a108eaaad86feca/ui/views/win/hwnd_message_handler.h