I am trying to establish an OpenGL rendering context for a window handle owned by another process. ChoosePixelFormat works returning a good pixel format index. SetPixelFormat with that index fails with a last-error code of 0xc0070006. My environment is Vista with an NVIDIA 8800 GTX (Forceware 169.25, the latest). The above works on other systems tried, including Vista with an ATI RADEON 9600 and several XP configurations (none with 8800 GTX). The same code works on the Vista 8800 GTX system in a single process. This sure smells like a driver problem, but I have to confess that the inter-process communication makes this a peculiar environment. Yahoo and Google searches on "c0070006" suggest that others have gotten this message in other environments, but there is no definitive information for the error code. 1) Does anyone know what "c0070006" is trying to tell me? 2) Does anyone have any troubleshooting suggestions? Walt

Did you check to make sure it's not some permissions/security issue? Try running your main process as administrator if you aren't right now...

Both of those replies are very interesting. My process (the one I am coding) is the one that kicks off the process that creates a dialog window and hands me a handle to a child window for OpenGL I/O. The subsidiary process that owns the dialog window is a commercial product developed by others.

I tried running my process explicitly as Administrator with the same result as described in my original post -- failure. However, then it occurred to me that invoking my process with Administrator permissions may have nothing to do with the permissions of the subsidiary process that owns the dialog window.

I have queried the developer about this, and I'll report back any results.

Thanks,

Walt

Quote:Original post by AverageJoeSSU
Um... i tried something similar. Using Pthread i tried a multithreaded OpenGL Color Cube, and there was a problem when the set pixel when glutInit was seperated , however, it didnt break every time... it worked maybe 1 out of 7 times. the other 6 it gave a pixel format error. Make sure your contexts are ok, i heard that you can only have one active OpenGL context at a time? or something like that.

Yep. I'm familiar with all of the above. In my current case, all of the OpenGL stuff (including rendering context) is in the same thread and process. It's the hWnd that is owned by another process.

I have an older application that splits application computation (e.g., animation displacements) and OpenGL/GLUT between two processes. The latter process employs a GLUT/OpenGL thread and a thread responsible for asynchronous communication with the other process. It works quite well. At the time, I think it was Nate Robins that advised me to not try to split any GLUT work between multiple threads. All of the OpenGL advice or documentation I have seen says to keep all OpenGL calls within the same thread that owns the rendering context. Other threads can be employed fruitfully if they avoid calling OpenGL functions themselves and are carefully synchronized.

On the current problem, I still have not heard anything from the developer. I assume he is off for the holidays.

Update: The developer suggested that I try running with Vista User Account Control disabled, which I did. The same SetPixelFormat failure occurred.

Curious, I installed all the prerequisite software on my wife's XP machine, which has an NVIDIA GeForce FX 5200 GPU. I updated Forceware to 169.21, the latest for XP. I got the same SetPixelFormat failure with the same return code.

Conclusion: This problem has nothing to do with Vista. It seems to occur only with NVIDIA GPUs. (I have to add that behavior with ATI GPUs tried is quirky.)

Walt

Update: An experiment has been tried directing DX9 output to a window owned by a separate process. (The window owner process is identical to that used in all the experiments reported above.) The experiment was successful with two different NVIDIA GPUs, several AMD GPUs, and an Intel chipset. It sure looks like my problem is tied to the OpenGL part of the NVIDIA driver.