locked
wglMakeCurrent in Windows 8 64 bit always returns FALSE RRS feed

  • Question

  • In an MFC project which uses OpenGL the call to wglMakeCurrent fails and GetLastError returns 6 (Invalid Handle). Thus, no OpenGL can be used. This happens only in 64 bit mode under Windows 8. With Windows 7 64 bit the code runs fine. The initialisation code remained unchanged since the time of Windows 2000 and 32 bit executables built from the source run fine in all versions of Windows.

    This problem is also reproducible with the Cubeview Sample. In cubeview.cpp, lines 248/249 when the original code is changed to

        hrc = wglCreateContext(m_pDC->GetSafeHdc());
        if (!wglMakeCurrent(m_pDC->GetSafeHdc(), hrc))
        {
            DWORD dw = ::GetLastError();
            TRACE1("wglMakeCurrent -> %d", dw);
        }

    dw is always 6 when the programme is executed in Windows 8.

    Has anybody an idea what could be wrong?

    Best regards

    Tuesday, April 9, 2013 5:17 AM

Answers

  • After some more digging, I also have conclude that this problem only occurs in a VM (Parallels in my case) -- on actual non-emulated machines, the code runs just fine.

    That's good news, though perhaps slightly frustrating for us cross-platform developers. 

    Importantly, it quite likely means that the problem lies with the developers of the OpenGL virtualization in these emulators rather than Microsoft.

    • Marked as answer by BongoVR Thursday, December 11, 2014 7:51 AM
    Wednesday, January 29, 2014 12:44 PM

All replies

  • Have you installed an OpenGL ICD on your Windows 8 system? Do other OpenGL apps function?
    Friday, April 12, 2013 10:16 PM
  • No, I have not installed anything. I am using Windows 8 out of the box. The problem mentioned does only show up with 64 bit applications in Windows 8. I have seen it on my development environment (Windows 8 Enterprise in a VM) as well as on a customer's PC running Windows 8 64 bit. 32 bit Open GL applications are working though. While I can understand (although not tolerate) that there might be issues with VMs there must not be problems with PCs bought off the peg. Please also note that there is at least one other person experiencing exactly the same problem (see http://connect.microsoft.com/VisualStudio/feedback/details/780757/opengl-in-mfc-application-does-not-work-in-windows-8-64-bit).

    The problem manifests in the same way for our application and the CubeView sample from MSDN. It is also important to note that the very same 64 bit binary works with Windows 7 64 bit just fine.

    If wglMakeCurrent is not sufficient/no longer usable/superseded/deprecated to set up OpenGL in Windows 8, Microsoft should provide sample code to demonstrate the steps necessary to set it up correctly. Otherwise, one has to suppose that this is a bug in 64 bit Windows 8.

    Monday, April 15, 2013 5:29 AM
  • Error 6 is: ERROR_INVALID_HANDLE thus either the m_pDC->GetSafeHdc() or wglCreateContext returns invalid handle (i.e. NULL or -1 or something like that). If the wglCreateContext fails then check (and try changing) what pixel format descriptor are you passing by SetPixelFormat. They might e.g. have stopped supporting some obscure feature that you are asking forin the SetPixelFormat and don't even use or realize since it is a little complicated.

    I don't think the problem is in Windows 8 itself, although it may be graphics driver, since OpenGL software run on my Windows 8 x64 quite well.

    Monday, April 15, 2013 8:53 AM
  • Both handles seem to have reasonable values. HDC is a typical value and HGLRC something like 0x0000000000020000, incrementing by 0x0000000000010000 with each new created window in the session. So this looks OK to me.

    I have changed the pixel format according to http://www.opengl.org/wiki/Creating_an_OpenGL_Context_%28WGL%29 and have played with dwFlags to no avail.

        PIXELFORMATDESCRIPTOR pfd = {0};
        pfd.nSize = sizeof(PIXELFORMATDESCRIPTOR);
        pfd.nVersion = 1;
        pfd.dwFlags = PFD_DRAW_TO_WINDOW |    // support window
                PFD_GENERIC_FORMAT |
                PFD_DOUBLEBUFFER |
                PFD_SUPPORT_OPENGL; // support OpenGL
        pfd.iPixelType = PFD_TYPE_RGBA;
        pfd.cColorBits = 24;
        pfd.cDepthBits = 32;
        pfd.cStencilBits = 8;
        pfd.iLayerType = PFD_MAIN_PLANE;
    Including PFD_GENERIC_FORMAT or PFD_DOUBLEBUFFER or leaving them out did not change the behaviour as did fiddling with the bits counts.

    After reading a bit further I even made sure the HDC is correctly set up using AfxRegisterWndClass as recommended in http://www.opengl.org/discussion_boards/showthread.php/156913-How-to-set-CS_OWNDC-in-MFC-info-here! This also did not change the behaviour.

    I am seeing this issue only with 64 bit executables. 32 bit OpenGL applications work just fine on my Windows 8 x64 as does my code when compiled in 32 bit mode. Did you make sure that your OpenGL software is 64 bit?

    Monday, April 15, 2013 12:37 PM
  • It all looks good ...although I usually use PFD where pfd.cColorBits=32 and cDepthBits=24. Would you care to try that out? Just to be sure.

    Other than that I am out of ideas. The software I mentioned earlier is probably 32-bit :-/

    Monday, April 15, 2013 3:25 PM
  • Originally, Color/Depth/Stencil have been set to 24/32/0 for more than a decade. The setup code remained basically unchanged since then. I have already played with 24/32/8, 32/24/8 and 32/24/0 getting the same result in each case. HDC and HGLRC are fine but wglMakeCurrent returns INVALID_HANDLE on Windows 8 running the 64-bit build.
    Tuesday, April 16, 2013 5:31 AM
  • Hello,

    I am also experiencing the same issue in a piece of software I develop. After some investigation, it seems that wglMakeCurrent always fails on Windows 8/8.1 when running 64 bit OpenGL applications compiled with Visual Studio >= 2012. Running the same binary on e.g. Windows 7 works fine. A temporary solution was to either use a 32 bit build or compile for 64 bit using a previous version of Visual Studio (I used 2010). 

    Obviously, this is not a satisfactory solution. This bug basically breaks OpenGL on Windows 8/8.1 when using an up-to-date development pipeline!

    For a nice minimal code example that triggers the bug (and some associated discussion), see http://stackoverflow.com/questions/19236021/wglmakecurrent-fails-on-x64

    Best regards,
    Wenzel
    Wednesday, November 20, 2013 2:06 PM
  • Well, if we know that the same program compiled as 64-bit in VS2012 fails and in VS2010 works, then the problem must lay in some difference in the runtime code. Either in appropriate msvcr???.dll, in some pre-WinMain code that the compiler inserts, or maybe the XML manifest for the executable brings in different SxS DLLs.

    I believe this could be worked out.

    Could anyone compile some identical simple program in both VS2010 and VS2012 and upload it somewhere so I could check it out?
    My primary machine unfortunately caught Sirefef!cfg so I can't do it by myself now until the reinstall finishes ;-)

    Wednesday, November 20, 2013 3:41 PM
  • Please see the following links:

    These contain Visual Studio projects and i386/x64 binaries (Debug+Release) of the small problematic example from stackoverflow, compiled using Visual Studio 2010 and 2013. The Visual 2013 x64 version will stop with an error message when run on Windows 8/8.1. In all other cases (using an earlier Windows version, or using the i386 or Visual Studio 2010 builds), the program runs successfully.

    https://www.mitsuba-renderer.org/files/repository/openglcrash_vs2010.zip

    https://www.mitsuba-renderer.org/files/repository/openglcrash_vs2013.zip

    Wenzel

    Thursday, November 21, 2013 2:58 PM
  • Hi,

    any news on this issue? It appears that OpenGL is just completely broken within 64 bit Windows 8 applications developed on the latest Visual Studio. I'm really surprised that such a serious bug could go by unnoticed so far.

    Wenzel

    Thursday, November 28, 2013 2:06 PM
  • Hi, sorry for not answering sooner. My testing equipment is still unavailable and I didn't discovered much. The two executables do not differ significantly from a first look. The only difference is the runtime (msvcr120.dll vs msvcr100.dll). I am not that surprised it isn't noticed much so far. Most games for Windows use Direct3D rather than OpenGL and there isn't many software built in VS2013 in general yet, not only OpenGL apps. Large software manufacturers (e.g. 3D modeling software) probably burn support tickets and talk directly to Microsoft representatives rather than have their people search forums.

    Saturday, November 30, 2013 7:43 PM
  • Hi,

    please note that this situation is not acceptable at all. First, the problem does not only exist since VS 2013 but was present in VS 2012 as well. This bug obviously passed all QA testing at MS unnoticed. How can this happen? Second, if large software manufacturers directly talk to MS, this is all fine and well. But then, there obviously must be a solution offered to them. Why are such solutions or workarounds not made public? Why is there no patch available in one of the updates to VS 2012? Why is VS 2013 still shipping with this bug although this issue should have been known long before RTM?

    You are not surprised that this bug has not got much attention? But I am! Is there nobody responsible for this library at MS? The hype about 64 bit can be found all over the place, but if someone really wants to go 64 bit, he is facing such ridiculous problems that should not have existed in the first place. Code quality and testing coverage numbers from MS obviously exclude some libraries and APIs MS does not want to be used any longer by its users.

    What should small ISVs do when just recompiling OpenGL code - which makes only a small portion of their entire software package and that worked basically unchanged for 10 years - stop to work? Since the first time the bug was reported through Microsoft Connect (http://connect.microsoft.com/VisualStudio/feedback/details/780757/opengl-in-mfc-application-does-not-work-in-windows-8-64-bit), about 9 months passed already without any substantial progress. This is not really acceptable and this should concern all MS users. Is reporting issues through Microsoft Connect a waste of time and effort?

    Monday, December 2, 2013 6:37 AM
  • I am also getting the same error, but inside an ActiveX Plugin for 64-bit Powerpoint.  I ran the openglcrash executables from the links above, and they seem to work ok.  The odd thing is that I am compiling my ActiveX plugin using Visual Studio 2010.  I can hardly believe this issue has been open since March 2013 and not been addressed, and no workaround has been posted.  Is this really the case?  Is my product out of luck for supporting 64-bit Powerpoint?  Does anyone know whether I should:

    1) Try to compile using Visual Studio 2013

    2) Submit an issue to Microsoft, will it help?

    Thanks in advance.

    Blaine


    Blaine Bell

    Wednesday, December 11, 2013 3:21 AM
  • Hello Blaine,

    this is the same what I feel. To answer your questions:

    1) Visual Studio 2013 does have the same issue.

    2) The issue has been submitted to MS already; showing no meaningful results so far. So you can judge yourself about the usefulness of doing so. But you may up-vote it on the Connect site. When MS Connect was introduced some years ago, I remember that they were much more responsive and helpful, but no longer these days ...

    Our 64 bit product line is not yet ready to ship to the customer. When it will be ready and there is still no workaround, we are going to have to tell our customers that the 3 D graphics module will be temporarily broken :-(. This should be not a big problem since we recommend against using Windows 8 anyway.

    That is the way it is, unfortunately.

    Best regards

    Wednesday, December 11, 2013 6:12 AM
  • Thank you very much for your reply.  So is there no workaround for this problem, including Converting my entire ActiveX plugin to the latest Microsoft technology (is it WinRT? Metro? do these even make sense, or is it possible?)  Aren't there serious 3D applications (e.g., Maya, Photoshop, etc.) out there that need 64-bit to render?  I guess none of them use MFC, since we try to avoid MFC whenever possible.  But its not clear to me how to write an ActiveX plugin for Powerpoint without MFC.  If anyone knows, please let me know.  Thanks!

    Blaine


    Blaine Bell

    Wednesday, December 11, 2013 2:44 PM
  • Hello Blaine,

    please remember that this issue is unrelated to MFC. The bug also shows up in a plain Win32 API application.

    If it is possible for you, you might try using MinGW to build your binary. At least you can try to separate the OpenGL part into a DLL built with a different compiler. As long as you are using a C interface, this should work. It depends on how complex your code and the integration with the other parts is in your case. I have not tried since this is not an option for me.

    I guess many tools use either DirectX, are still in 32 bit world, use Visual Studio 2010 or older or an entirely different compiler, etc. Many people use older development tools, but I DO WANT to use the C++11 features of the new compiler.

    The latest MS technology? You see how OpenGL breaks with the most recent compilers on the most recent OS. You were able to see how investment in new technology (GDI+, WinForms, WPF, Silverlight, etc.) has been and is being invalidated rapidly. New technology is hyped every now and then. Sticking to the Win32 API and trying to use only what has been there in Windows 95 already, is still a safe bet.

    Best regards

    Wednesday, December 11, 2013 3:25 PM
  • My team has tried to reproduce this issue using the project posted here:

    https://www.mitsuba-renderer.org/files/repository/openglcrash_vs2013.zip

    But we are unable to reproduce it using Visual Studio 2013 and running on a Windows 8.1 machine.  Tried with x64 configuration and it works.

    Some more information about your particular configuration might help.Thanks,


    Raman Sharma | Program Manager, Visual C&#43;&#43; | <a href="http://twitter.com/rasharm_"> @rasharm_</a> <br/> <br/> (if my post has answered your question, please consider using the 'mark as answer' feature in the forums to help others)

    Tuesday, January 7, 2014 9:40 PM
  • Yes, I am able to reproduce this problem only on a VM (Parallels or VMWare).  To fix it, just turn Hardware Acceleration off, and a software 3D rendering window is available.  This is really strange behavior, especially since it only happens inside an ActiveX component, but at least we can give our users a workaround. 

    Blaine Bell

    Tuesday, January 7, 2014 10:11 PM
  • I can confirm the same error with code generated in VS 2012 running on Windows 8.1 in Parallels 9 in OSX Mavericks. The same code generated in VS 2008 generates error codes but continues to function. This is a problem for those of us working on cross platform C++ code.
    Friday, January 10, 2014 10:38 PM
  • In an MFC project which uses OpenGL the call to wglMakeCurrent fails and GetLastError returns 6 (Invalid Handle). Thus, no OpenGL can be used. This happens only in 64 bit mode under Windows 8. With Windows 7 64 bit the code runs fine. The initialisation code remained unchanged since the time of Windows 2000 and 32 bit executables built from the source run fine in all versions of Windows.

    This problem is also reproducible with the Cubeview Sample. In cubeview.cpp, lines 248/249 when the original code is changed to

        hrc = wglCreateContext(m_pDC->GetSafeHdc());
        if (!wglMakeCurrent(m_pDC->GetSafeHdc(), hrc))
        {
            DWORD dw = ::GetLastError();
            TRACE1("wglMakeCurrent -> %d", dw);
        }

    dw is always 6 when the programme is executed in Windows 8.

    Has anybody an idea what could be wrong?

    Best regards


    Sunday, January 19, 2014 4:28 AM
  • After some more digging, I also have conclude that this problem only occurs in a VM (Parallels in my case) -- on actual non-emulated machines, the code runs just fine.

    That's good news, though perhaps slightly frustrating for us cross-platform developers. 

    Importantly, it quite likely means that the problem lies with the developers of the OpenGL virtualization in these emulators rather than Microsoft.

    • Marked as answer by BongoVR Thursday, December 11, 2014 7:51 AM
    Wednesday, January 29, 2014 12:44 PM
  • > it quite likely means that the problem lies with the developers of the OpenGL virtualization in these emulators rather than Microsoft.

    I am skeptical to point fingers either way on this issue.  Its odd that I can open an OpenGL window in other places (i.e., non-activeX components) on the same Virtual Machine.  Why would opening a OpenGL window in ActiveX be any different than opening it in an Application?  I am very curious to know this answer, I remain neutral on this issue right now, and would just like either side (or both) to figure it out so we can avoid this issue!  If anyone wants to volunteer from either side, I will be more than happy to help reproduce this issue (I have a project that does so), and any other information that you might need.

    Thanks,

    Blaine


    Blaine Bell

    Wednesday, January 29, 2014 3:48 PM
  • Yes, that seems to be the point.

    After I updated my Parallels version, the error simply disappeared on my Win8 VM completely. OpenGL code now runs fine in 64 bit.

    Thanks and best regards

    Thursday, December 11, 2014 7:54 AM