[BUG] Pixel format not accelerated, The driver does not appear to support OpenGL

[hanno]

So, since it's not possible to workaround the problem when using IDEs (because they always start "java" to launch your app), I'm now downgrading to an older driver. Very funny that this was the first thing I tried, but I tried it with the 10th latest driver version - which I wasn't able to install and then I gave up early. A very weird optimization Nvidia did there.

[avm1979]

I haven't been able to verify this yet, but apparently running java on Windows using this:

CreateProcess( TEXT("..\\jre\\bin\\java.exe"), ...

Also produces the same error, despite running java.exe.

This post on reddit seems to indicate that running javaw.exe rather than java.exe is the solution, but that doesn't mesh with you guys being able to get around it by running java.exe. Again, haven't confirmed - hesitant to update drivers at the moment.

[Kai]

apparently running java on Windows using this:
CreateProcess( TEXT("..\\jre\\bin\\java.exe"), ...
Also produces the same error, despite running java.exe.

I cannot reproduce this behaviour. For me, using this program:

#include <stdio.h>
#include <Windows.h>
int main(int argc, char** argv) {
	STARTUPINFO si;
	PROCESS_INFORMATION pi;
	ZeroMemory(&si, sizeof(si));
	si.cb = sizeof(si);
	ZeroMemory(&pi, sizeof(pi));
	if (!CreateProcess(TEXT("any\\relative\\or\\absolute\\path\\to\\java.exe"), 
            TEXT("any\\relative\\or\\absolute\\path\\to\\java.exe -jar the.jar"), NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi)) {
		fprintf(stderr, "%s\n", "ERROR!");
		fflush(stderr);
		return 1;
	}
	WaitForSingleObject(pi.hProcess, INFINITE);
	CloseHandle(pi.hProcess);
	CloseHandle(pi.hThread);
    return 0;
}

runs just fine. Of course, leaving out the ".exe" extension will not work since CreateProcess() is no shell/command interpreter like cmd.
Also take note that the program name must be repeated in the second argument to CreateProcess() because of conventions on how to call C programs, as mentioned in the documentation of CreateProcess, or otherwise the Java launcher will not see the first command line argument.

EDIT: Changing the "java.exe" to "java" in the _second_ argument of the CreateProcess() call results in the known error. That's probably what you were using/experiencing.

EDIT2: It seems that the Nvidia driver does not like when the first command line argument of the process (argv[0] in C-speak) does not exactly match the last path-segment of the exe module name including the '.exe' file extension the process was started with. Practically with any other application it is possible to specify argv[0] as anything you'd like, such as with this call:

CreateProcess(TEXT("path\\to\\java.exe"), TEXT("whatever -jar the.jar"), ...

This works with any non-OpenGL, non-Direct3D Java application, because the JVM does not care what argv[0] was.

But when running a program that uses OpenGL/Direct3D API via Nvidia's driver, it is a bit different:
Here, it _only_ seems to work when the last path-segment of the module name (the first argument to CreateProcess()) _exactly_ matches the last path-segment of the first command-line argument (the second argument to CreateProcess()). This means, the Nvidia driver checks the executable module name (the exe file) and matches this with the last path-segment of argv[0] of the current process.
It does not seem to matter that the path to the exe module name matches (or even would resolve to a valid/existing file), because this in turn works fine:

CreateProcess(TEXT("path\\to\\java.exe"), TEXT("some\\none\\existing\\path\\to\\java.exe -jar the.jar"), ...

[avm1979]

Ah, yeah, that looks like what was happening. In my case, the 2nd parameter did not include the executable name but rather started with -server to run the JVM in server mode. Which I could've sworn it did, but double-checking now, it didn't. Thank you for clearing this up! And pointing me to another bug in the process.

[CoDi]

Ah, yeah, that looks like what was happening. In my case, the 2nd parameter did not include the executable name but rather started with -server to run the JVM in server mode. Which I could've sworn it did, but double-checking now, it didn't. Thank you for clearing this up! And pointing me to another bug in the process.

Well, according to MSDN you don't need to include the executable name in the 2nd parameter if you already did in the first. https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx

If both lpApplicationName and lpCommandLine are non-NULL, the null-terminated string pointed to by lpApplicationName specifies the module to execute, and the null-terminated string pointed to by lpCommandLine specifies the command line.

As usual, this Win32 API is confusing as hell and full of "if this, then that... -- oh and btw, on Windows X it's different" rules.

[Kai]

Well, according to MSDN you don't need to include the executable name in the 2nd parameter if you already did in the first. https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx

Yes, you don't need it for CreateProcess() to know which executable it should run. But you need it because of the C convention that the program name is always the first parameter of the command line (accessible via argv[0] or via the Win32 call GetCommandLine()) because those C programs expect the program name to be in argv[0] and therefore will only parse real command line arguments starting with argv[1].
See:

Console processes written in C can use the argc and argv arguments to parse the command line. Because argv[0] is the module name, C programmers generally repeat the module name as the first token in the command line.

[BenMcLean]

I have encountered an issue which I think probably has the same cause. This commit here which worked last week quit working after the driver upgrade, and now says "Process finished with exit code -1073740791 (0xC0000409)" when launching on desktop. (libGDX 1.9.4's LWJGL backend)

The graphics hardware in my laptop is nVidia GeForce 840M and I managed to fix it for now by downgrading from driver version 378.49 (which I think caused the issue) to version 376.33.

[BenMcLean]

I posted about this on the official nvidia geforce forums and I expect nVidia would appreciate anyone providing additional info there.

[CoDi]

I doubt they will disclose how they messed up, but at least they seem to work on a fix.

I must confess I had a chuckle at this. I'm a bad person.

I went back to the previous driver release, after discovering that 378.49 "broke" one of my java reliant Irish Revenue service taxation programs.