I'm running into a strange thing while making a game in VC++. I'm using the Cocos2d-x platform and VC++ 2010 in Windows 7 and it works perfectly fine on my machine. However, I have another computer that is Windows XP. I am currently using /MT so there is no problem with the runtime library, but the program doesn't run in Windows XP and it doesn't even produce an error. I have tried with 2010 C++ redist on the other computer, and it doesn't work with or without. There is nothing in the console and no error log. Nothing appears odd in DependencyWalker, only missing internet explorer frame stuff. What can cause a program on windows XP to execute and close immediately without leaving an error?
Anyone has any ideas? I am using the game framework's dynamic linked libraries, so could that be a problem? Also, even though I linked statically, my executable is only about 140 KB. Is something messing up?
Thanks for any help.
EDIT: There's also an interesting problem with CRT I ran into before. When I ran the program with permission level "asInvoker" on windows 7, I got a "CRT Not Initialized" error. Once I set it to "highestAllowed", it started working but I was wondering if it had anything to do with CRT?
Okay, I've found the problem. It turns out that my other computer has an integrated Intel Graphics card that doesn't support the graphics renderer (OpenGL ES 2.0) that the framework uses. That's why it ends up crashing without outputting any errors.
Thanks to anyone who helped.
Related
I'm working in a project building an application with Computer Vision using C++, OpenCV and Visual Studio. I'm no expert in deploying programs to use them on other PCs.
I've made a program which I need to distribute to a certain amount of people and I can't make it work on all the computers I'd like to. The program was written using Visual Studio 2015, it's an MFC Project and the code is written in C++ since I'm using OpenCV.
When it was finished, I tried to run it on another computer and I realized that it won't open. I looked on the Internet and found out that I needed to statically link the libraries, so I did it. Also, when I was looking for information, I found that Visual Studio 2015 builds its projects so you can run the programs on machines with Win7 to Win10. When I learnt that, I tried to open it on PCs running Windows 7, 8, 8.1 and 10. I tested my program in like 20 computers, give or take.
The results? I couldn't make it work for Windows 7, the error ucrtbase.terminate api-ms-win-crt-runtime-l1-1-0.dll showed every time I tried to open it. It also didn't open in one machine with Windows 8 without showing any error message, but it DID open on most of the machines with Win 8.1 and Win 10. The thing is that "most"; there were some PCs (with Win 8.1 and 10) that I couldn't open my program on. I found that sometimes it would show up in the Task Manager for less than a second and then disappear. The most stressful thing is that it doesn't tell me what the problem is, it doesn't show any error message. It just won't open.
I tried using Dependency Walker (both on my PC and one of those that I couldn't run my program on) to see if there's something missing and I got a reeaaally long list of files that the system couldn't find, here's an example:
List 1/11. Something curious is that my program executes just well on my computer and on those I could open it, even though Dependency Walker (DW) tells me that there might be a problem with it. This indicates me that DW is not finding the exact error I'm having.
Another thing I've tried is to compare the things I have installed on my computer and install them on the one I want to execute my program on. I tried installing .NET Framework 4.6.1 just because VS 2015 says that my project was built using it (and I have it installed in my PC and that other one doesn't. Also I tried with .NET 4.6.1 SDK). Nothing changed.
Just look here:
https://msdn.microsoft.com/de-de/library/ms235299.aspx
The quick-and-dirty way would be to copy the DLLs from your redist directory. For my MS VS 2013 it is hidden under the VS installation directory in:
VC\redist\x86
or
VC\redist\x64
...
which depends on your application.
So, I'm using CodeLite on Windows, building with Mingw64 on 64 bit system. Everything builds, but when i run the application, it crashes with "Client.exe" has stopped responding. Client.exe being my application. I'm literally running the default example code off the SFML website. When I've googled around for quite some time now and I honestly have no idea as what to even look at for this error.
Sometimes my console will output
Application has exited with error code: 255
But most of the time it outputs:
Program exited with return code: -1073740940
Using help from the comments on my question.
As stated by Satus, The issue was, first, my libraries were statically linked, using the Dynamic libraries, instead, seemed to have fixed my issue. My second issue was that my SFML libraries were built using the wrong version of MingW. Recompiling this was simple enough. I downloaded the SFML source code. Used CMake to set everything up as displayed on the official SFML compiling and building tutorials, and built it using my version of MinGW. After copying the newly compiled DLL's and Debug DLL's, everything worked perfectly.
Be sure if you're using two different version of MingW (64bit and 32bit) to compile each version in CMake accordingly, otherwise you may get issues.
I would like to point out that I am still learning and it could be something obvious that I am missing.
But to the point:
For my assignment, we had to make a simple game that would display an interactive scene.
So I wrote all the code on my computer and everything works fine, the code compiles and the program runs exactly as intended.
I've decided to move it to my laptop because it is due tomorrow and now I got a problem.
When I try to compile exactly the same code, visual studio shows me an error at line:
_programID = glCreateProgram();
Which works perfectly fine on my desktop.
It says "Exception thrown at 0x00000000 in Project.exe: 0x00000005: Access violation executing location 0x00000000."
The code is literally the same on both machines.
Both machines use windows 10 and exactly the same version of visual studio.
I have also linked my libraries relative to the solution directory so it is not a problem with a wrong path.
What could be the case? I really don't understand why is this happening. I have copied the entire folder with all the libraries and additional header files that I use along with the project.
I thought maybe it is because I am using libraries compiled on my desktop? Does that matter?
Please help.
I write this in case somebody had a similar problem in the future:
The problem was with my graphics card driver on the laptop. After my last format I didn't install the drivers (didn't really think about it since I use my laptop only for office and simple visual studio stuff) and that was causing OpenGL functions to throw errors. Installing drivers fixed the problem.
Thank you very much #Humam Helfawi.
here is some information to understand my situation better.
OS: windows 8.1
IDE: Visual Studio 2008 Pro
Language: C++
i have just my Firefox reinstalled and after this(maybe it was not the reason),
my visual studio Project compiled only with 9.0.30729.6161 VC++ Runtime DLL.
Until yesterday it always compiled with 9.0.30729.8387 VC++ Runtime DLL.
Because of this (or maybe other reason), now i cannot start my Project.exe.
Nothing is changed in source-code. Project-Property and all other things are also unchanged.
I just get the error number 0xc000007b suddenly.
How can i fix this?
It was because of an 32bit DLL, which should not be loaded for my 64bit Project.exe.
I have found this with Process Monitor.
I don't know why, but anyway is the "path" is changed and the 32bit DLL(which has the same name with 64bit DLL) is loaded..
If you have the same Problem, check whether there is a problem between your application and its dependencies using dependency walker.
Entered the answer in another place, but figure it could be helpful for folks who badly need some help:
It has been mentioned in other answers that using dependency walker is the way to go, in my case (my application keeps failing with the error code), dependency walker showed a few dll that are NOT relevant!
Finally figured out that I can run profiling by going to "profile" menu and it will run the application and stop at the exact dll that's cause the problem! I found out a 32bit dll was picked because of path and fixed it.
-Turn off your antivirus software before starting the installation.
-Accept any additional software offered during installation process, since it may be crucial for running your application properly. You can skip things such as search bars, antivirus scanners, registry cleaners and the other software which isn’t directly related to the application.
-Install an application to the system partition (C:). Although this shouldn’t matter, it’s been proven that some apps may return an error if installed on a logical partition.
There is more than one way to solve it. This link might also be helpful.
http://finally-found-the-solution.blogspot.com/2015/02/how-to-fix-0xc000007b-application-error.html
i've written a small application using c++, Qt and Visual Studio 2010. It's working on Windows XP (32bit) but it crashes on Windows 7 (64 bit) right after start-up. I see a "The program has stopped working..." error. Do I have to recompile the application for Windows 7? And is it possible to get more information why it crashes?
Thanks
In general you wouldn't have to recompile for windows 7, but it depends on your application which you haven't provided details of.
The easiest way to find out is either debug it in windows 7 or put more error handling in, so that it lets you know what has gone wrong, or where it has gone wrong
I agree with what martiert said, also, if you are using some external elements, images. sound files, video files, etc ... be sure of the file location asd this was a problem for me when I was presenting my graduation project, I moved the whole solution from a directory to another and it crashed because it was reading a not found directory ... so be sure of the links of the images, videos, sounds etc ...
You might have to recompile for Windows 7/64bit. It might not even work after a recompile, since Windows 7 is not XP, and a program written for 32 bit might not work for 64. Often one don't have to recompile, but sometimes one have to, and some times a program which works on XP won't work on Windows 7.