0

I am writing a game in C++ using MS Visual Studio 2010. The game is almost at beta state but I'm facing a serious problem here, hopefully someone will be able to help.

So, if I run the game from VS (e.g. with F5 key) everything works perffect. But as soon as I run the newly compiled .exe file of the same game at some points in game I get crashes and some other strange things happen. Is there something I can do to fix it? Is there maybe a certain setting in VS? It's really confusing me, please help if someone knows a solution.

Andy8888
  • 1
  • 3
  • Are you running the executable in debug mode within MSVC? – James Elderfield Jul 14 '16 at 10:21
  • Every relative path you use is a bug waiting to happen. Fix those, and you'll get a lot closer to, uhm, sounds more like pre-alpha. – IInspectable Jul 14 '16 at 10:26
  • Try cltr + F5 instead of F5 (i.e execute instead of run). Refer here: [link](http://stackoverflow.com/questions/11202088/what-is-different-between-visual-studio-f5-ctrlf5-or-running-outside-of-visua) – Rotem Jul 14 '16 at 10:26
  • 2
    @Rotem ctrl-F5 does not run in the debugger, and thus still not catch the exception. it just launches the process as if you did it free form, using the project-dir (not the build dir) as the working directory. – WhozCraig Jul 14 '16 at 10:28
  • 1
    *Is there something I can do to fix it?* -- Yes -- debug your code, it has bugs. It isn't an issue with Visual Studio. Uninitialized variables, wild pointer usage, or anything that can invoke undefined behavior can cause this. – PaulMcKenzie Jul 14 '16 at 10:30
  • Try increasing warning level. With luck that will reveal something like use of uninitialized variable. – hyde Jul 14 '16 at 10:30
  • 1
    Regarding your debugger configure its exception options and light up all the *important* ones, particularly the access exceptions, illegal instructions, etc, to be caught in the debugger. Alternatively, you could research and configure setting up an automatic dump on your process if it crashes, then load the dump in either VS or WinDbg (a bit archaic, but incredibly powerful). And make damn sure your debugging the same bits (Release or debug mode, but always build with symbols) as you're running free-form. – WhozCraig Jul 14 '16 at 10:32
  • Your code behaves exactly as written. It's your expectations that are different. – jonspaceharper Jul 14 '16 at 10:34
  • The fact that you need to ask such a vague question means that there are a lot of unchecked assumptions in your code. Nobody likes a crash, but a crash without a hint of what went wrong is even worse. Go through your code and add error dumps or logging at critical assumptions (like accessing a file, running a non-trivial computation successfully, allocating memory, ...) the better the dumps, the faster you'll find and resolve your bugs. If you have a beta (and you should) leave those logging tools enabled and collect all dumps from crashes during the testing phase. – BeyelerStudios Jul 14 '16 at 10:35

1 Answers1

3

If I remember correctly the F5 key is used to start debugging, and when running in a debugger Visual Studio does things that does not happen when not running in a debugger.

First and foremost the debugger will clear all memory for you, meaning things like uninitialized variables becoming zero. This clearing include uninitialized pointer variables being initialized as null pointers.

If you have uninitialized pointer variables and have null-pointer checks for them, those checks will work fine when running in the debugger, but when not running in a debugger those variables will have an indeterminate value, a value that will be seemingly random and most likely not a null pointer. Thus when you run outside the debugger those non-null pointers will make your program think the pointers are valid and you will dereference them which will lead to undefined behavior.

What you need to do is to go through your code and look for uninitialized variables, especially pointers, and make sure they are properly initialized before you use them.

Like other mention, there are also many other things that can go wrong when running in a different environment than the Visual Studio debugger or by starting the program from Visual Studio. One major problem mentioned is that relative file paths may not be correct any more. The programs working directory when run from the command line at a different directory, or when running by double-clicking its icon, will be different than when started from withing Visual Studio. Having some sort of configuration-value stating things like a base-directory for game assets and other files you need is a good idea. Then you can change the process current working directory to that, or use it to resolve the absolute path for your assets yourself.

Some programmer dude
  • 400,186
  • 35
  • 402
  • 621
  • Thank you very much, I will review all my code for those things. Actually I always try to initialize my variables but probably there is still something somewhere where I should look into. – Andy8888 Jul 14 '16 at 10:33
  • @Andy8888 If this solved your problem please accept the answer. – Jonathan Mee Jul 14 '16 at 10:36
  • I think my major problem is that there is something wrong with pointers because worst things happen during loading and unloading of a map where a lot of things happen inside of the memory (e.g. many new and delete calls). I think there is a lot to do :/ – Andy8888 Jul 14 '16 at 10:47