Gfx: Bandicam causes Piston draw_2d/draw_3d calls to gfx devices to panic.

[patowen]

When creating a minimal working example with Piston graphics and a gfx backend, like in https://github.com/PistonDevelopers/piston-examples, I get the following error when rendering onto a window when Bandicam is attached to that window. (Operating system: Windows 10, Graphics card: Nvidia GTX 970)

Error InvalidEnum executing command: BindProgram(0)

The following is a minimal example that should cause the error:

extern crate piston_window;

use piston_window::WindowSettings;
use piston_window::PistonWindow;

fn main() {
    let mut window: PistonWindow = WindowSettings::new("Testing", [640, 480])
        .build()
        .unwrap();

    while let Some(e) = window.next() {
        window.draw_2d(&e, |_, _| {});
    }
}

The stack trace is as follows:

thread 'main' panicked at 'Error InvalidEnum executing command: BindProgram(0)', C:\Users\Patrick\.cargo\registry\src\github.com-1ecc6299db9ec823\gfx_device_gl-0.14.6\src\lib.rs:777:12
stack backtrace:
   0:     0x7ff676ba1081 - std::sys_common::backtrace::_print
                               at C:\projects\rust\src\libstd\sys_common\backtrace.rs:94
   1:     0x7ff676ba764c - std::panicking::default_hook::{{closure}}
                               at C:\projects\rust\src\libstd\panicking.rs:380
   2:     0x7ff676ba7335 - std::panicking::default_hook
                               at C:\projects\rust\src\libstd\panicking.rs:397
   3:     0x7ff676ba7cb5 - std::panicking::rust_panic_with_hook
                               at C:\projects\rust\src\libstd\panicking.rs:611
   4:     0x7ff676ba7b48 - std::panicking::begin_panic<alloc::string::String>
                               at C:\projects\rust\src\libstd\panicking.rs:572
   5:     0x7ff676ba7a21 - std::panicking::begin_panic_fmt
                               at C:\projects\rust\src\libstd\panicking.rs:522
   6:     0x7ff676aab03f - gfx_device_gl::Device::process
                               at C:\Users\Patrick\.cargo\registry\src\github.com-1ecc6299db9ec823\gfx_device_gl-0.14.6\src\lib.rs:777
   7:     0x7ff676aa6bbf - gfx_device_gl::Device::reset_state
                               at C:\Users\Patrick\.cargo\registry\src\github.com-1ecc6299db9ec823\gfx_device_gl-0.14.6\src\lib.rs:406
   8:     0x7ff676aab1a0 - gfx_device_gl::Device::no_fence_submit
                               at C:\Users\Patrick\.cargo\registry\src\github.com-1ecc6299db9ec823\gfx_device_gl-0.14.6\src\lib.rs:782
   9:     0x7ff676aabf32 - gfx_device_gl::{{impl}}::submit
                               at C:\Users\Patrick\.cargo\registry\src\github.com-1ecc6299db9ec823\gfx_device_gl-0.14.6\src\lib.rs:906
  10:     0x7ff67699dc7f - gfx::encoder::Encoder<gfx_device_gl::Resources, gfx_device_gl::command::CommandBuffer>::flush_no_reset<gfx_device_gl::Resources,gfx_device_gl::command::CommandBuffer,gfx_device_gl::Device>
                               at C:\Users\Patrick\.cargo\registry\src\github.com-1ecc6299db9ec823\gfx-0.16.2\src\encoder.rs:194
  11:     0x7ff67699e1ae - gfx::encoder::Encoder<gfx_device_gl::Resources, gfx_device_gl::command::CommandBuffer>::flush<gfx_device_gl::Resources,gfx_device_gl::command::CommandBuffer,gfx_device_gl::Device>
                               at C:\Users\Patrick\.cargo\registry\src\github.com-1ecc6299db9ec823\gfx-0.16.2\src\encoder.rs:185
  12:     0x7ff67699808e - piston_window::PistonWindow<glutin_window::GlutinWindow>::draw_2d<glutin_window::GlutinWindow,input::Event,closure,()>
                               at C:\Users\Patrick\.cargo\registry\src\github.com-1ecc6299db9ec823\piston_window-0.74.0\src\lib.rs:227
  13:     0x7ff6769ffc5d - breakage::main
                               at C:\Users\Patrick\git\piston-examples\src\breakage.rs:12
  14:     0x7ff676ba8821 - panic_unwind::__rust_maybe_catch_panic
                               at C:\projects\rust\src\libpanic_unwind\lib.rs:99
  15:     0x7ff676ba7f61 - std::rt::lang_start
                               at C:\projects\rust\src\libstd\rt.rs:54
  16:     0x7ff6769ffe5b - main
  17:     0x7ff676bb3a88 - __scrt_common_main_seh
                               at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:283
  18:     0x7ffde7ee1fe3 - BaseThreadInitThunk
error: process didn't exit successfully: `target\debug\breakage.exe` (exit code: 101)

I believe the issue is related to the fact that Bandicam, in addition to being able to record rectangles on the screen, can also record OpenGL game windows. renders the framerate onto the window. In doing so, it must somehow be interfering with gfx.

This is an issue involving the latest version of Bandicam: 4.1.0.1362, the paid version (although I believe the unpaid version will also have this issue). OpenGL windows made with other programming languages and libraries do not have this issue.

[msiglreith]

The issue seems to be related with Core context creation (on Bandicam side). Configuring the glutin context builder with .with_gl_profile(glutin::GlProfile::Compatibility) fixes the issue for me in the triangle example.
Related forum post: https://forum.bandicam.com/viewtopic.php?f=10&t=6907

Would be interesting to see if we can error out more gracefully in the future or detect it earlier if possible.

[kvark]

Closing as pre-ll is deprecated