“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.
On the 32-bit machine, if your glew32.dll is used, then it will generate the initialization error that was reported before:
“The application failed to initialize properly (0xc0000142). Click on OK to terminate the application”
If the glew32.dll from SourceForge is used, then it will crash a bit farther down with no error message like the one above. In other words, the initialization is okay with the SourceForge’s glew32.dll.
On my netbook, the glewinfo.exe has the following output below. I guess that means the graphic chips can work only with OpenGL version up to 1.4? If that is true, then the crash probably makes sense if you are using some methods available only in OpenGL 1.5.
GLEW Extension Info
GLEW version 1.6.0
Reporting capabilities of pixelformat 3
Running on a Intel Pineview Platform from Intel
OpenGL version 1.4.0 - Build 8.14.10.2230 is supported
etc etc
On the 32-bit machine, if your glew32.dll is used, then it will generate
the initialization error that was reported before:
“The application failed to initialize properly (0xc0000142). Click on OK
to terminate the application”
If the glew32.dll from SourceForge is used, then it will crash a bit
farther down with no error message like the one above. In other words,
the initialization is okay with the SourceForge’s glew32.dll.
On my netbook, the glewinfo.exe has the following output below. I guess
that means the graphic chips can work only with OpenGL version up to
1.4? If that is true, then the crash probably makes sense if you are
using some methods available only in OpenGL 1.5.
I did a build which uses the ARB functions in case OpenGL 1.5 isn’t
supported:
The new test.exe crashed without generating any dump. The previous version of test.exe crashed but Windows could generate a minidump. Since I don’t have any symbol files for the test.exe, I don’t know where it crashes. I am uploading the dumps here for you.[attachment=0]testdump.zip[/attachment]
The new test.exe crashed without generating any dump. The previous
version of test.exe crashed but Windows could generate a minidump.
Since I don’t have any symbol files for the test.exe, I don’t know where
it crashes. I am uploading the dumps here for you.
What kind of files are these? I don’t know what to do with them.
Would it help if I put the source for the demo in a public git repo?
The Windows mdmp file is like Unix’s core dump file. If I have your build environment, I probably can read it.
On the other hand, I guess your crash is probably the same as the one seen on mine when I used the Visual Studio IDE to build your original code. So, I browsed the web and found this:
On my netbook, the value is 1024. On my W7 64-bit, it is 2147483647. On my W2k VM, it is only 256 (OpenGL 1.1).
So, I wonder how large your array is. If it is larger than 1024, that may explain it. Is there any way for you to limit the size to something less than 1024 so that I can test it? I am not that familiar with OpenGL so I don’t know right away where I should go to trim off the array that glDrawArrays uses.
Perhaps that has something to do with the crash seen in glDrawArrays?
The last binary I uploaded uses glBindBufferARB if glBindBuffer isn’t
available, and there’s a check in test.cpp which should print an error
messasge to your terminal and exit if neither are available. This check
comes well before any OpenGL functions are called.
On the other hand, I guess your crash is probably the same as the one
seen on mine when I used the Visual Studio IDE to build your original
code. So, I browsed the web and found this:
On my netbook, the value is 1024. On my W7 64-bit, it is 2147483647.
On my W2k VM, it is only 256 (OpenGL 1.1).
So, I wonder how large your array is. If it is larger than 1024, that
may explain it. Is there any way for you to limit the size to something
less than 1024 so that I can test it? I am not that familiar with
OpenGL so I don’t know right away where I should go to trim off the
array that glDrawArrays uses.
All of the vertex arrays being drawn have 4 elements. I haven’t done
anything fancy yet to pack vertices from multiple objects into larger
arrays.
I could not get your code compiled with VS 2010 yet. On checking the working code you just uploaded, I did not find anywhere calling glBindBufferARB though. I suppose if anywhere, that change should be in map.cpp?
I could not get your code compiled with VS 2010 yet.
How did it fail? What were the error message?
On checking the
working code you just uploaded, I did not find anywhere calling
glBindBufferARB though. I suppose if anywhere, that change should be in
map.cpp?
In order to avoid checking for OpenGL 1.5 support every time we use
one of the VBO functions, I set up some function pointers for these
functions (and for all of the other OpenGL functions we use). These
are in the gl namespace, declared in glutil.h and set in glutil.cpp.
Unless I have the wrong test in setup_gl_fptrs() in glutil.cpp, there
shouldn’t need to be any changes made elsewhere.
The last binary I uploaded uses glBindBufferARB if glBindBuffer isn’t
available, and there’s a check in test.cpp which should print an error
messasge to your terminal and exit if neither are available. This
check
comes well before any OpenGL functions are called.
Actually, I never see any error message. Your last binary just crashed
after trying to start.
Do the core dumps you have tell you wehere it’s crashing?