Swapping buffers hangs on Windows when opened on Secondary Monitor

When compiling on Windows 10 and using the Windows subsystem instead of Console, glutin hangs because calling gl::SwapBuffers seems to never return. However, this is not present when you launch the application from the terminal, regardless of if it is built with Windows subsystem or not.

When compiling on Windows, glutin's calls to gl::SwapBuffers will hang when the application is opened on a secondary monitor.

Steps to reproduce:

Clone the glutin repository. (As of right now master is 24812ca)
Add #![windows_subsystem = "windows"] to the top of window.rs in the examples so that the application will not be forced to open on the main monitor.
Build the example with cargo build --example window. (Do not use cargo run or the issue will not occur)
Navigate to the example executable in the target directory using Windows Explorer.
Drag Windows Explorer onto a secondary monitor and open the executable by double clicking on it. (So that the app will open on a secondary monitor)
The program will hang on a call to gl::SwapBuffers, meaning you end up with a white window that isn't responding.

Using a debugger I managed to locate the call to swap buffers that hung for me.

glutin/glutin/src/api/wgl/surface.rs

Line 104 in 24812ca

if gl::SwapBuffers(hdc) == 0 {

After messing with it some more, this only seems to happen when the window is opened from my second monitor (I have two). I did not notice previously because when opening with the console it always opened on my main monitor.

Edit: The issue has been updated accordingly.

I managed to find a similar issue on another repository as well, so this may be an issue with GDI itself.

Have you tried calling make_current right before GL commands? It seems to me that it's a windows issue and given that WGL documentation wrt that is lacking, I'm not sure one could figure it out.

Could suggest to try EGL if you have it.

Hmm after rebooting my machine I can no longer reproduce the issue so it might just be a random Windows bug. I'll close the issue for now.