I’m writing an OpenGL application on Windows 98 in Visual C++. I can always debug my app normally a few times. Then, while my app starts, an error message occurs:
DDHelp caused an invalid page fault in module <unknown>
(and all that register stuff)
I found out that this error occurs exactly when I call ChoosePixelformat().
DDHelp is some DirectDraw module which I’m very surprised about to have anything to do with OpenGL because I’m not using DirectX anywhere in my app.
I have a Geforce4Ti4200 with latest Detonator drivers for W98 and I tried several DirectX versions (7.0, 8.0 and 8.1),
but the problem persisted.
I’ve checked if memory is freed correctly and if the textures are deleted, and that seems to be okay.
I’ve tried out quite a few things but it’s all the same - it drives me mad!
There’s one thing that I found out now: I’m getting the device context for my window with GetDC() in the beginning, this value is stored until the end, and then I try to release it with ReleaseDC() (after deleting rendering context and before destroying the window). But this ReleaseDC()-call seems to fail because it returns 0. Could this cause the problem? And why should ReleaseDC() fail, what’s wrong then?
Do you know the problem or have any other idea about it?
There has been previous posts about this. Some people say that it has something to do with ddraw not cleaning up after itself.
I beleive that some GL drivers use ddraw to render on. Maybe this problem is fixed on NT/2k/XP or never existed.
About the DC, you should make sure CS_OWNDC is part of the window class style, and you should release the dc when the destroy command is sent.
Thanx.
I have searched the forum for the topic “ddhelp” (I know, I should have done that before) and found several postings discussing this problem.
It seems that it only occurs with Win98. (The problem is, apart from this error I’m still quite happy with that OS; I know Win2000 is much safer but also much slower.)
Reading through those postings, I found no real solution, but people mentioned some possible workarounds. I just want to list them here:
deinstall Internet Explorer (one guy said the problem did not occur on his system until installing IE)
run KillHelp.exe from the DirectX SDK before running your OpenGL app
run an app that uses DirectDraw (like Media Player) before running OpenGL; but not every DDraw-app seems to have the ‘magic’ effect to eliminate the ddhelp-error
Some people said that they did not have the problem when using specific driver versions, but if someone wrote about a driver fixing the problem, there was another one who said that exactly that driver did not fix the problem on his system; so it appears to me that there’s no really ‘clean’ driver - you may have good or bad luck with every driver.
By the way, I found out why my ReleaseDC()-call returned NULL: I feel like an idiot. I passed the two arguments (window handle and device context handle) in the wrong order! But after correcting this, I was sure that I had eliminated the problem - I could happily debug my app several times without any error. And then it was there again: “DDHelp caused blablabla…” So I’ve given up the ‘hope’ that it is my fault - it really seems to be the fault of the OS and/or the video driver alone…
But if somebody still knows a hint or another workaround (just to be able to debug the OpenGL stuff): please post it here!
The purpose of DDHELP.EXE is to clean up shared resources after an “abnormal” program determination.
When I first started at NVIDIA, I had a similar crashing problem in one of our NV20 demos. Turned out to be a reference counting bug in DDHELP or DirectSound. It ended up unloading our DDraw driver one too many times, while the core DirectDraw DLL thought our driver was still loaded. This crashed, plus when the next app came up, ddraw.dll was trying to call into our now unloaded driver. Crash again.
We worked around it by explicitly freeing all the DirectSound buffers used by the demo. DX8.0 was broken, DX7.0 was fine. I haven’t tried to reconfirm, but anecdotal evidence suggests that DX8.1 is similarly broken.
I am able to debug my app normally now if I start the MediaPlayer after the Win boot and play back any video file (starting the player without loading a video does not help). After that I can run my app without problems… except the one that I am not able to really eliminate the problem because it’s some magic Windows stuff…
