I got the same error on both of my Windows 7 (netbook and desktop)
machines.
My netbook is an Acer Aspire One 532h series machine. It has an
integrated Intel Graphics Media Accelerator 3150 video processor. I
think this kind of setup is typical of netbook.
It has something to do with an exception being thrown. From where, I’m
not sure yet.
I got the same error on both of my Windows 7 (netbook and desktop)
machines.
My netbook is an Acer Aspire One 532h series machine. It has an
integrated Intel Graphics Media Accelerator 3150 video processor. I
think this kind of setup is typical of netbook.
It has something to do with an exception being thrown. From where, I’m
not sure yet.
I see what it is now: This is something I read about somewhere, namely
that everything beyond OpenGL 1.1 is supported in Windows as extensions.
I have the demo throwing an exception if OpenGL 2.0 isn’t supported.
I did run it as administrator since I wanted to use FileMon and RegMon to see if it was looking for some non-existing files or registry keys. It still crashed but then I could not see in the logs which files or registry keys are missing.
What is weird though is that your test.exe spawns a randomly-named executable, which seems to be the one that actually runs. If this is true, I am afraid that even if this turns out to be working, some anti-virus software may shut it down in the end.
“The application failed to initialize properly (0xc0000142). Click on OK
to terminate the application”
Lance
I read that this error can be caused by a missing DLL. I thougth I’d
included all of the DLLs which you wouldn’t have already. Here’s what I
get when I check what DLLs the exe links to:
What is weird though is that your test.exe spawns a randomly-named
executable, which seems to be the one that actually runs. If this is
true, I am afraid that even if this turns out to be working, some
anti-virus software may shut it down in the end.
I read that this error can be caused by a missing DLL. I thougth I’d
included all of the DLLs which you wouldn’t have already. Here’s what I
get when I check what DLLs the exe links to:
“Errors were detected when processing…(the filepath test.exe). See the log
window for details”
In the log window:
Error: At least one module has an unresolved import due to a missing export
function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.
Ieshims.dll - error opening file. System cannot find specified file
Wer.dll - error opening file. System cannot find the file
Can send you the dependency walker image if you like?
I read that this error can be caused by a missing DLL. I thougth I’d
included all of the DLLs which you wouldn’t have already. Here’s what I
get when I check what DLLs the exe links to:
“Errors were detected when processing…(the filepath test.exe). See the log
window for details”
In the log window:
Error: At least one module has an unresolved import due to a missing export
function in an implicitly dependent module.
Error: Modules with different CPU types were found.
This error is not one I see when I try it on my VM. Can you tell which
DLLs are causing it?
Warning: At least one delay-load dependency module was not found.
Ieshims.dll - error opening file. System cannot find specified file
Wer.dll - error opening file. System cannot find the file
These two are the same ones I saw missing in my VM. Everything I’ve read
about these says that they aren’t loaded unless they’re needed, and on
systems where they are needed, they will exist already.
I did some more testing on W2k VM 32-bit, XP SP3 32-bit, W7 32-bit and W7 64-bit. All of them failed but on checking the Filemon logs, I got a clue when I noticed that something seemed to happen when glew32.dll was loaded. So I went to glew32.dll’s SourceForge location to download its latest. After replacing the file, my W7 64-bit works but all others still fail.
I then looked at the log files produced by running the glewinfo.exe utility that comes with the glew32 download. The log files suggest that the OpenGL binaries on my 32-bit machines are no newer than 2 whereas my gaming W7 64-bit is patched all the way to 4. I think that because my W7 64-bit has a real graphics card, when its drivers were installed, its installation package probably automatically upgraded the W7 system with the latest OpenGL binaries whereas all my other 32-bit machines are still using those default ones that come with the OS. For example, I think the glDrawArrays call works only if the OpenGL is at least of version 3.1 or above.
I did some more testing on W2k VM 32-bit, XP SP3 32-bit, W7 32-bit and
W7 64-bit. All of them failed but on checking the Filemon logs, I got a
clue when I noticed that something seemed to happen when glew32.dll was
loaded. So I went to glew32.dll’s SourceForge location to download its
latest. After replacing the file, my W7 64-bit works but all others
still fail.
So you replaced the glew32.dll that I built, and then it worked on
64-bit Windows? I don’t know what to make of that. The glew32.dll I
supplied is 32-bit, but if it’s just a bitness issue, then I would
expect the one I suppied to work on the other systems you tried. What
happens if you dump in the 32-bit GLEW DLL from their site and try that
on your 32-bit systems?
I then looked at the log files produced by running the glewinfo.exe
utility that comes with the glew32 download. The log files suggest that
the OpenGL binaries on my 32-bit machines are no newer than 2 whereas my
gaming W7 64-bit is patched all the way to 4. I think that because my
W7 64-bit has a real graphics card, when its drivers were installed, its
installation package probably automatically upgraded the W7 system with
the latest OpenGL binaries whereas all my other 32-bit machines are
still using those default ones that come with the OS. For example, I
think the glDrawArrays call works only if the OpenGL is at least of
version 3.1 or above.
Here’s a complete list of the OpenGL functions the demo uses, sorted by
the minimum version of OpenGL which supports them:
The OpenGL 1.5 functions we’re using are also present in the
ARB_vertex_buffer_object extension. It might be that the way we need to
handle this is by calling the ARB versions on Windows. I thought part
of the point of GLEW was that the function pointers for the core
functions would point to the ARB versions on Windows in the event that
the core ones weren’t there… Possibly I’ve misunderstood this, but
then I’m not sure what exactly GLEW is for if not that.