I'm trying to build a release version of my chess engine that was built in the Qt environment and recently ported over to the visual studio 2015 environment. Everything runs fine in debug, and using this post here I was able to use windeployqt.exe to get dependencies that were giving error messages.
But now when I run it, it shows up in the process explorer for about 3-4 seconds then disappears. It's not throwing any errors so I'm not sure what's wrong. It could be it needs a dependency that I haven't copied yet? There's nothing that I know of that would cause it to run and quit, it never does that during debug.
Any tips or direction as to where to look for an answer would be appreciated! Thanks.
As trivial as it may sound, welcome to C++! You're programming in a very low level language that errors may some times crash your program with no apparent erros. This is not Java or Python or some high-level language where everything is done for you. In other words, if you mess up, you probably could get weird crashes like you're having.
There are many things you can do:
Delete all your compiled files and rebuild them from scratch. Linking issues with legacy code often cause what you're describing
If you added a list of libraries to link to (other than Qt), make sure that you need every library of them. Create a new "Hello world" program and link to them, and see if you'll get the same crash.
If it's not a linking issues, you're most likely having an access violation (or segfault).
Run the program in debug mode, and see if you get any information about the error.
The last resort is the low-level, stupid, binary search couting method. Basically you print a message in various places in your program, and see at which message the propgram will stop. The reason I call it "binary search", is because if have N places to test, with a binary testing approach you only need about log(N) compiles to find the problem, which is not a lot, but will cost you some time to recompile the program. In other words: Keep printing messages until you see where they stop appearing, and then blame that line.
Good luck.
Related
If I have a series of C/C++ programs that I need to build using Make , would it mess up the code run if I made changes to the code and recompiled while the program is executing an executable? Or is all the information preloaded in the executable before runtime?
Thanks.
This depends entirely on whatever operating system you're using.
Linux is perfectly happy continuing to execute a program whose binary has been removed, and replaced with a new binary.
It is my understanding that Microsoft Windows is, on the other hand, rather grumpy in the same situation, and won't be happy if something like this is attempted.
If I am understanding correctly, you can edit the code while you run the program and the program will not change while you run it.
I've been running and compiling a program on my Windows 7 64-bit machine for several months now, but recently I had to change several VC project settings of the static libs that it uses and now the generated executable file requires me to run it in "Windows XP Compatibility Mode".
Compiled on Windows7 64-bit machine with Visual Studio 2010 SP1
The program I am generating is being built in Win32, debug mode.
The static lib projects specify Target Machine /X86.
When I run the program from the debugger, it start up and runs, however if running via the windows icon, it requires XP compatibility mode.
When trying to start outside of the debugger the EXE shows up in task manager for a second then goes away.
I've tried using Microsoft Application Verifier on it, however I don't know what to look for in the output.
I've been unable to find any details on how to troubleshoot this issue so if anyone has any ways if finding what could be causing this recent Compatibility Mode requirement I'd love to hear how it was fixed.
I have the source/projects/solutions for the majority of the static libs that I link against, as well as the exe file generated, however some of the external dependencies I only have the .lib,.dll, and .h files for. This means I can change (most) of the project settings for the dependencies if neccessary, but I need to know which ones to look for.
Thanks
To be honest, don't be afraid to make another project and copy the code files, even if it's 5 projects. You need to cut the problem in half. If it works with the new projects then it's the project files, if not, it's the code. Making projects isn't that hard really, though I'm sure a source of much consternation and something people avoid. If its the projects you can diff the files and see what happened by process of elimination. If you are really worried, copy the entire solution to another folder; always make backups.
The problem is that you probably won't be able to hoist enough information up to us to get a meaningful answer unless get lucky, and all the answers will be shots in the dark.
So I'm goign to take this question as "this happens, what can I do about it". The strategy above will get you out of it, if this used to work before. This exercise will arm you for the future and will be more productive in the long term. Go look at UAC and manifest files, aka Vista+ difference tht dramatically changes load and run behaviour (Linker Commands, Vista Migration Guide) if you need one thing to look at, but try the above process.
----
Other generic things to try:
1) another machine
2) another install of VS
3) a simple project with one window that does nothing to prove everything else in your tool chain and environment is ok.
4) planting message boxes along the code path with different messages so you know where its crapping out.
5) turing on pdb in release and runnign outside of debugger. If craps out, then try debugging and see if still craps out, but you get to see where.
6) assume that your code is unstable and you were getting lucky when it used to work. (this one is no fun). Many times things work in debug and not in release due to mem layout being different. If your progam is large you can find creative ways to use #if's whatever to elimitate code from running while haivng the whole thing still load. You can find the code that causes the bad behaviour.
7) turn off UAC and error reporting if its on, see if changes.
8) go find the "run without debugging" menu button in Visual Studio, so you don't have to go run it with the icon. That's an accident waiting to happen, and eliminates one more environmental difference. It looks like the run with debugging button, but it's hollow, a plain green triangle. It's under debug menu set. My oppinion is that it has done more harm than good to not have that on the bar by default as its confused many many people to think launching wiht VS means always using the debugger.
and so on....
I am very new to VC++ and I am running the program on VC++ for the first time.
I strictly followed the instructions given in Microsoft Programming Visual C++ book and created one project as instructions given.
About the ex03a.exe:
I saw in the path "...\Ex03a\Debug\" and in that no file exists such as ex03a.exe.
I tested my vc++ by executing a simple 'Test.cpp' file. I was able to run the simple c++ program and I got the output. And Test.exe is there in '\Test\Debug\Test.exe'
My Question:
How could I get rid off the error.
Almost always when VS says it isn't able to open a file, it's about opening it for writing.
And almost always this doesn't work because the file is locked.
And almost always this is because the file is an executable that is currently running :-)
This is a specialty of Windows - an exe is not simply loaded, it's locked for all of it's run time. This is probably due to the fact that exe files (actually called portable executables, for whatever reason) contain not only code, but usually also an arbitrary number of resources (like images, etc.), and changing the file on the fly would make the aplication crash hard when it attempts to read one of those resources at run time.
Therefore, I suggest looking for a way to exit / close / terminate the application, so it isn't running any longer, so the file is not locked anymore, so in this case the linker can do its work.
The error message, btw., isn't that intuitive from my point of view - this problem being SO standard, it could at least attempt to tell you anything about this possible source of the problem - afaik, this hasn't been improved until now, probably because most developers have seen this before, found out why it happened, and therefore do not have any more problems with it.
I see that in that screenshot, that you are running multiple versions of VC6.
Now You get that error if you run the newly compiled exe of that program without shutting down the previous compiled exe.
VC tries to overrwrite the exe that is currenty running but encounters that exact error.
Always close the program when you are done.
This shakes my understanding of computers and operating systems on a level that makes me very uneasy. I have just spent about an hour entering different iterations of compile commands to g++ and in my exasperation I renamed the executable which kept having the delay from game.exe to gameg.exe and all of a sudden the problem vanished.
Here's some more background: I was noticing recently that when I ran my Eclipse unit test build, when I start with an SDL enabled test it would open the SDL window and freeze for about 20 seconds before being able to get the test started. On subsequent tests (which call SDL_Quit() and re-initialize SDL as part of the test process) this delay is not present. Now I have ascertained that ONLY when the executable is named exactly "game.exe" does this happen! I rename it to any other filename and it goes along running tests happily, initializing the SDL system within a second like it usually does. I had assumed before that there must be some kind of bug that was causing my Eclipse build to have this behavior which wasn't present in the makefile build, but it turns out if I take the eclipse build and rename its executable (the project folder it's in is called game hence game.exe) it doesn't exhibit the behavior.
Likewise I take my makefile build (whose filename is entropy_unittest_disp.exe fyi) and rename it to game.exe and it begins to do this. I rename it to game and it also does it (I am running from mingw's bash.. when not with .exe extension, explorer doesn't know it's an executable). However I changed it to game.exx and it worked normally.
WHAT IS THIS BLACK MAGIC? Why should a program function differently depending on its filename??? I do query argv[0] and i actually do it to print to console its value (for debug purposes) but unsurprisingly it just prints the program and its path. No logic is ever performed on it in my program.
I tried to run GDB to find out where it is freezing but once I press Ctrl+C GDB simply exits.
does anybody have any idea what this might be caused by? A virus?
edit: I downloaded this demo from this site: http://www.sdltutorials.com/sdl-opengl-tutorial-basics/
extracted it, renamed the file to game.exe, and yup, same thing happens. WHAT IS THIS? I'm going to try running dependency walker next to see if something's trying to hook into it.
I'm assuming you have either a AMD (ATI) or Nvidia graphics card with their official drivers.
Chances are, game.exe is the executable name for an actual game released and your drivers are running special optimizations for the "game" or loading the Crossfire or SLI profiles for this game. A quick Google search seems to tell me that Resident Evil 4 calls their executable "game.exe."
I recommend taking a look at this link for further details as to what may be happening:
http://www.kn00tcn.net/site/ati-catalyst-profiles/
not sure how to reply to steven's comment on the top answer, but regarding driver profiles, it's just a basic brute force check of .exe filenames
some games are guaranteed to be in a specific sub folder, so the driver looks for where the exe is located, such as '\team fortress 2\hl2.exe'
but since most games let you pick what folder name you're installing to, & a lot of the time the exe is in that same root folder, the drivers have no choice but to blindly assume gameX.exe is going to be gameX
a nice 'side effect' of this is you can force other game profiles on any game for troubleshooting purposes, or to try to enable CF/SLI scaling
so always try to make sure that your executable has an original name to know that the gfx driver isnt attempting to run 'optimizations' made exclusively for other games
Could this be due to Anti virus software running on your OS? Certain files are commonly used in Virus "Game.exe" could be one of them and hence additional care from OS / AV to ensure that it is safe
Test it in clean windows, without any extra software installation, if it work fine, then maybe you have some protection software like Anti-virus or sandbox , ... , if you have any of this software disable them, and test again
Check to see if game.exe is listed in the Image File Execution Options registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options. It can be used to launch a particular program as a debugger for an application with a particular name. (More info on Image File Execution Options)
An EXE will behave differently based on its name due to AppCompat Shimming. Check the loaded module list and see if there are a bunch of DLLs that start with "ac" loaded into your app.
I'm working on a pretty tricky problem that I've been on for literally a week now. I've hit a very hard wall and my forehead hurts from banging it so I'm hoping someone can help me out.
I am using Visual Studio 2005 for this project - I have 2008 installed but was running into similar issues when I tried it.
We have an application currently working compiled against OpenCv1.1 and I'm trying to update it to 2.2. When we switch over statically link to the new libs, the application crashes - but only in release mode. So dynamic linking and debug both work fine.
The crash is in std::vector when calling push_back.
I then came up with a sample test application which runs some basic code in opencv which works fine and then took that exact same code and added it to our application. That code fails.
I then gutted the application so it didn't instantiate any code objects except the main gui and 1 class which called that code and it still crashed. However, if I ran that code directly in the main gui, it worked fine.
I then started commenting out huge amounts of the application (in components that should never be instantiated) and eventually I worked my way down down down until...
I have a class that has a method
void Foo()
{
std::vector<int> blah;
blah.begin();
}
If this method is defined in the header, the test code works, but if this code is defined in the cpp file, it crashes. Also, if I use std::vector<double> instead of int, it also works.
I then tried to play with the compiler options and if I have optimizations turned off (/Od) and Inline Function Expansion set to Only __inline (/Ob1) it works even with the code being in the cpp file.
Of course, if we go back to the ungutted application and change those compiler options by themselves, it crashes.
If anyone has any insights on this, please let me know.
Thanks,
Liron
ARGH! Solution figured out.
In our solution we had defined _SECURE_SCL = 0, but in the 3rd party libs we had build, that was undefined (which means = 1). Setting _SECURE_SCL to 0 supposedly reduces runtimes drastically, but it has to be done the same across all included libs otherwise they will treat array sizes differently.
http://msdn.microsoft.com/en-us/library/aa985896%28v=vs.80%29.aspx
That was a fun week.
The STL classes, like vector<>, have a layout mismatch between the release and the debug builds, caused by iterator debugging support. Your problem behaves exactly like the kind of trouble you get into when you link a debug build of a .lib or DLL in the release build of your application and exchange an STL object between them. Heap corruption and access violation exceptions are the result.
Triple check your build settings and ensure that you only ever link the release build of the .libs in your Release build and the debug build of the .libs in your Debug build.
could you try:
void Foo()
{
std::vector<int> blah;
blah.reserve(5);
blah.begin();
}