0
\$\begingroup\$

I run into an issue if my game application becomes unresponsive when running in fullscreen on Windows. This mostly applies when I want to use breakpoints in Visual Studio, however if the application crashes, such as from a memory error, the window doesn't close.

I don't think this is strictly a WGL/GLFW/Cocos2D problem, since I have seen this problem in other Windows games, including ones that use Direct3D.

I searched around, but I can't find a definitive answer as to what causes this problem or how to fix it. From what I have read, this issue is only supposed to be caused by using HWND_TOPMOST (or maybe HWND_TOP); however, even changing all uses of that in GLFW to HWND_NOTOPMOST doesn't seem to fix the problem.

I imagine that registering a custom signal handler using std::signal might work, but I am not sure which parts of the Windows API, if any, I should call in an exit handler, that would solve this problem.

\$\endgroup\$
0
\$\begingroup\$

The "problem" is that when running the application within Visual Studio, even in Release mode, it automatically attaches its debugger. This appears to be strictly related to Visual Studio trying unsuccessfully to become the active window underneath another unresponsive window. And of course the "deadlock" occurs because it is the MSVC debugger itself keeping the process open/suspended, and preventing the window from closing.

| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.