No sure why, but every time I run my OpenGL program on my home computer a message box pops up at runtime stating "The procedure entry point glewInit could not be located int he dynamic link library glew32.dll". Now I am almost certain I installed everything properly, I followed the instructions from the glew webpage and I can even get the program to run on my work computer. I've tried searching online for solutions to this error but most people with this error have it because they forgot to include the dll file in the linker dependencies (Which is not my issue.) Does anyone have any insight on how to correct or circumvent this error? My current operating system is Windows 7 Professional edition (2009).
Quick solution of last resort is to look for an other glew32.dll on your system shipped with an other application (you can easily find such an application over the web).
The problem appears when mixing headers/libs versions. It will compile, but while the older versions declares glewInit as entry point, the newer ones (1.9 for sure) declares _glewInit#0 in release configuration.
Confusing your last compilation output with an old debug exe can also produce such a situation.
Not sure what the problem was, but I redownloaded glew, I think I might have been missing a header file (not glew.h) and that forced it to blow up with a less than helpful error message.
Related
I have customer code written for Visual Studio 6.0 MFC which has a simple GUI and launches an EXE with arguments. This code was ported from VS6.0 to VS2019 about 2 years ago and works in a production environment on several systems. We now have a new system where the code fails to function... and I'm starting to dig.
The code is throwing exception in appcore.cpp line 196
It is crashing at AfxGetThread() now that I have been able to get VS2019 to find "appcore.cpp".
This is new information.. I will be searching on AfxGetThread next... so this question likely to be a duplicate now.
One difference I have detected is the order where the Visual Studio 2019 debuger loads symbols. I can't say for certain that this is an indication of the actual DLL load order at runtime, but it appears to be. The screenshot below is the SYMBOL load order where a difference is detected between the working and non working instance of the application.
In the image below we have a Tortoise SVN Diff of two ASCII files. One is the DLL symbol load order on the left when the application works. The second is the DLL symbol load order on the right when the application fails to work. Line 7 is the divergance, where in the failig case the library win32u.dll is pulled in before mfc140d.dll.
The customer code uses some Apache log4cxx libraries which I need to investigate, but at this point in the load sequence I'm not 100% sure differences in those libraries or *.h files used at build time could influence the DLL loading order.
So this is the puzzle I'm looking at.
I will include some links to relevant StackOverflow questions that are similar in my search for an answer to this question.
Possibly Useful Links:
https://learn.microsoft.com/en-us/cpp/porting/porting-guide-mfc-scribble?view=msvc-170
The DLLs are searched in order in different locations: Standard Search Order for Desktop Applications
Most likely the DLLs on the failing machine are missing or they are in the wrong location, so Windows grabs something else.
Make sure all the dependencies are installed in the correct folders.
In this case, the crash in appcore.cpp was due to the code having 2 CWinApp derived objects in the code. And the crash occurs at construction time.
The first hurdle is to get VisualStudio2019 to find appcore.cpp and be able to step into this code. I browsed to C:\Program Files(x86)\VisualStudio and searched for "appcore.cpp". This provided the trail of breadcrumbs to get Visual Studio2019 the correct path when it asked for the file.
In my case the path is:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.29.30037\atlmfc\src\appcore.cpp
The second hurdle was to put a breakpoint at the ASSERT point, as the FIRST time the program comes up, this ASSERT is OK. At least in my case... the first constructor of the CWinApp object succeeded. So in my case the offensive code which was unexpectadly constructing a CWinApp derived object ran first. Then the second iteration through the ASSERT would happen.
By placing a breakpoint at the ASSERT, you can re-launch and look at the stack trace of the successful object to determine if it's expected or not.
In my case there was a *.h fix required to get ancient Visual Studio 6.0 MFC code to build and link successfully. I don't have the exact secret, but it's essentially getting a *.h to specify the proper WIN_VER minimum windows version before afx.h is included. For the code that failed, an incorrect *.h was included that included the fix PLUS objects that derived CWinApp.
As near as I can tell, the reason this worked on some sites and not others was due to a regression in the code that was built on that particular system.
The other "strange" behavior was that on the system with the bad *.h include the DLL symbol load order was different. I was able to replicate this bad behavior on more than one system running the "bad" Exe code. Then I did the same on working *.exe code. The strange thing was that the "bad" exe had reasonably correct sources in the workspace. So there were source control issues leading to this belief that it worked on one node and not others.
The runtime behavior I was able to catch matched obsolete code committed to source control.
I have downloaded gorilla-audio source code to use it in my software, but when I use the external library from OpenAL (in gorilla-audio, the OpenAL32.lib) the project compiles with no errors or anything, but it doesn't run normally, I still haven't implemented anything from gorilla sound, just wanted to check that after adding the library it would still work the same before editing anything, but it just doesn't, I have linked everything and used the correct version of .lib but when I run the project it says:
The program can't start because OpenAL32.dll is missing from your
computer. Try reinstalling the program to fix this problem.
What should I do, I've googled that but I'm just scared to download random things, plus I don't even know where should I put it.
Any help guys,
Thanks ^_^
I tried to run a program I wrote on a remote computer. As I knew there might be a dll problem, I set the runtime library option to /MT, so I can rely on static linking.
However, I still receive the error message on my remote computer, stating that MSCVP140.dll is missing. Isn't this what the /MT flag should take care of?
I even tried to install the redistributable, but no luck. I'm still stuck with the error.
Another thing I tried was placing a MSVCP140.dll I downloaded in the folder, but that way my program is simply crashing on startup. I suspect that the MSCVP140.dll version is not the expected one, so I'm not relying on the validity of this test.
Any ideas?
Try to open your exe with depends.exe and find the dependancies in the machine it crashes. Probably the MSVCP140 might have other dependancies. Copy all dependancy dlls into same folder and give a try.
Someone please punch me for being this stupid... I was compiling on x86 instead of x64 all the time. No surprise the dlls didn't work.
Thanks for the help nevertheless. At least you got me on track to take a closer look at my dlls.
I apologize if this question is vague, but I can't really get any more specific. I have a pretty large project that I'm porting to Windows. After finally getting it to compile with cl, and link with link.exe, I run it and get the following 'System Error':
The program can't start because C:\Windows\SYSTEM32\tm.sys is missing
from your computer. Try reinstalling the program to fix this problem.
It's a console application which requires no installation. Does tm.sys signify anything to you, perhaps a Linux dependency that I missed that Windows allowed during compile time but is now interpreting oddly? I'm looking for hints/guesses/anything to run with because I fully realize that my description (and lack of code example) is less than satisfying.
It is a C project with some mixed in C++ code (C++ accounts for maybe 1%), and is built using the WDK. The compilation yields 5 static .lib files and one .exe file.
The issue resided within ntoskrnl.lib. I removed that unnecessary library from my sources file and the executable ran fine. I'm not sure the significance of tm.sys, but lesson learned: KNOW YOUR DEPENDENCIES!
I'm using boost for several C++ projects. I recently made a upgrade (1.33.1 to 1.36, soon to 1.37), since then I cannot run any debug-builds anymore.
To be sure that no other project issues remain, I've created a minimum test-project, which only includes boost.thread, and uses it to start one method. The release build can be started, the debug build cannot, although the Dependency Walker shows that all required libraries are found (this also means that the required MS Debug CRT is found in the SxS directory).
On startup I only get:
Die Anwendung konnte nicht richtig initialisiert werden (0xc0150002).
Klicken Sie auf "OK", um die Anwendung zu beenden.
Which means nothing more than "failed to initialize app". An internet research primarily lead to an MS Office installation problem, which recommends to perform a repair of WinXP.
So, beside the repair setup (which I think will not help as I'm talking about debug-dll issues), any ideas?
Ah, before I forget: Absolutely the same source-code leads to no errors on the build-machine (i.e., DLLs can be registered, means executed). So it's obviously an installation problem, but as the DLLs are there, and dependency-walker finds it, what else have I forgotten?
(edit) Well, I have not yet resolved my problem, but thanks to deemok I'm a step further. For the sake of reducing misunderstandings I give some clarifications below:
The program fails to run on the developer-machine
I am working with an installed VS2005 (it's a VC++8 project)
I used the boost-setup from BoostPro, compiled all possible build-versions, and I double-checked that they are there (otherwise I'd already get linker-errors during build).
and I double-checked any corner of include/lib/bin configuration I can think of -- as boost uses auto-linking on windows, with a special naming convention, the build or start-up would have failed, with a much more comprehensible error-message.
I cannot use static linking, as boost.thread requires dynamic linking for DLL projects (I maybe could mess around here, but as this problem seems to happen only on my machine, I do not want to mess with this, as I'm sure the boost-guys had a reason to place that check in there in the first place)
As I wrote, I checked with Dependency Walker, and it says everything is just fine.
Currently it seems to be an error in the boost-dll (maybe incorrect Manifest), will check that.
It's a Side-by-Side (SxS) issue – simply copying the DLLs is not enough anymore.
Regarding your specific problem concerning the Debug build, see: Running vc2008 debug builds on non-dev machines
Short answer:
You can't, because there's no installer redist for the debug runtime (and in fact the software license forbids distributing it, so you'd be breaking the EULA even if you did get something put together).
So, you'll need to install Visual Studio there.
However, if you still want to try without taking that path, you could read puetzk's answer in its entirety.
Or, you could try to link everything statically.
So you are using the pre-built libraries from BoostPro? If so, your environment might somehow be slightly different to the one they were built in (TR1 feature pack or not, etc). Perhaps best to try building Boost yourself in your specific environment.
This might turn out to have nothing to do with SxS. I suggest checking the Event Log for SxS error messages and using dependency walker to check for most probable DLL dependency issue, or one of the DLLs is returning FALSE from its DllMain (for whatever reason).
Also, enabling loader snaps:
gflags -i yourapp.exe +sls
might shed extra light when run under debugger (or dependency walker for that matter).
Note: gflags is part of Windows debugging tools.
Get yourself the dependency walker. Open your application exe in it. It will show you all the dlls that your application needs but can't load/access.
If that's not enough, you can also profile your app with the dependency walker, which will give you a lot of output to find out where the problem is.
[edit]
since you only have problems with the debug build:
make sure that when you upgraded boost, you also rebuilt not just the release binaries but also the debug binaries of boost. And of course, make sure that the debug build was built with the same version of VisualStudio than you're using now.
And make sure that the include paths (tools->options->projects and solutions->VC++ directories) are correct: the paths to the latest boost version must be there, not maybe to an older version.