Recognize crashed graphics driver

Question

On my notebook (dell xps 15, win8.1 x64, nvidia/intel gpu) I can use up to three displays at the same time, but if my laptop disables the displays because of energy saving and turns them back on, if you move the mouse, sometimes the graphics driver crashes and will be recovered.

No magic at all, but sometimes the graphics driver can not fully recover - it is acting normally unless I'm creating an OpenGL context - the context will be created successfully, everthing acts normal - but it's a standard OpenGL 1.1 GDI context, and all function pointers devised after OpenGL 1.1 and not covered by the GDI are just null pointers, so the application immidiatly crashes when loading resources.

Is there any chance I can detect a crashed driver and tell the user to reboot her/his machine (that's already the solution I'm adopting for this problem) - or should I simply tell him/her, that something might be wrong or their OpenGL driver version is not supported?

Oh, and both, the Intel and the NVIDIA gpu are unable to create a newer OpenGL context.. weird behaviour indeed..

Answer 1

Driver crashes are handled "seamlessly" in WDDM (Windows Vista/7/8). Generally, when the display driver resets itself the screen goes black for a while and then a little message pops up in the system tray telling you that this happened. Both NV and AMD drivers do this. That said, the behavior you are describing also happens a lot with NV drivers - this state where no ICD OpenGL context can be created until a full reset seems to be exclusive to NV. The best solution is to check the GL version/extension support when your software starts and print an error if the implementation is inadequate.

Often, assuming your application is not what caused the driver reset, in OpenGL after a driver reset your application will continue running. Context resets are handled behind the scenes in GL and the driver will reload all of the resources for you. You might be able to detect this situation if you use a robust context (new WGL extension), but this really sounds more like a problem that happens while your software is not running.

Answer 2

but it's a standard OpenGL 1.1 GDI context, and all function pointers invented after OpenGL 1.1 and not covered by the GDI are just null pointers, so the application immidiatly crashes when loading resources.

Are you not testing the availability of required extensions/OpenGL version? And don't you test that the function pointers actually obtained are valid?

To me it sounds you blindly assume, that OpenGL extensions will always load just fine. It's mandatory to perform those checks though, and if they fail to provide a meaningful error message to the user.