that's the clear screen color for opengl, which means it's loading but some part of the opengl code is not compatible with your system.
here's the deal - i'm an old guy i don't have any friends to test stuff for me. i upload my software, maybe i get three mentions a year.
what you have is a standard msvc "win32 dektop application wizard" standard banal default app. the opengl is accessed from the .dll using LoadLibrary and getProcAddress. then i prototype a couple dozen opengl APIs, i have an example here
https://github.com/atomictraveller/win32-OpenGL
the reason i'm saying this is because i can't fix it unless i know which API isn't working on your system but does work on mine. i released my first win32 app with msvc two years ago and have had less than a dozen reports, but it works for some people :p i did use borland fclt to use about the same win32 routine with windows for all the decades beforehand.
but i'm an old guy. i'm not using a resource or library. i can only fix this if someone talks back to me.
After that example code uses LoadLibrary to load up OpenGL and initialize a bunch of API function pointers, it calls FreeLibrary because it doesn’t need the library handle anymore. But wouldn’t that close the entire library and invalidate all those function pointers? I guess if OpenGL is itself loaded into shared memory, a different process keeps it open, and Windows doesn’t invalidate the address space in the application, it could still work? But if that was happening, I’m not sure why OpenGL would just nondeterministically not work, I think it would crash.
So I’m confused about that. I didn’t read the source code listing super closely so I might have overlooked something obvious. But I can’t help but wonder if you’re using example code that itself is unreliable in some way. I wonder what else that code listing is dropping before it’s actually done with it…
What version of Windows are you using? What CPU is it running on?
hopefully this is quite interestingly solved ;) i'll repeat it here in case it's buried on discord,
in bb1 i have an array of "random values" passed as a 1D uniform. later, i decided this was silly and declared the float array inside the shader. apparently the crux is that nvidia opengl driver are characteristically tolerant of opengl code whereas other drivers don't like this. it was quite vexing because there was so little difference between the two forms, but that is it. i've uploaded builds with the array on a 1D uniform. we'll see, but i'm guessing that nails it and provides what would have been an extremely elusive, at least for me on my own, solution! :) super thanks for sticking with me here, i'd say this issue has plagued the last 6 months of my releases unknowingly..