Visual C++ windows Application Executable file Crash

Visual C++ windows Application Executable file Crash

• mr hankey

  There is not enough information to say.  Applications crash for different reasons, and you should still attempt to use the debugger to reveal some clues.  This is a better strategy than trying to guess external causes.

  First, what is the exact nature of the crash   Exception code

  If running from the IDE via F5 does not break into your app when (not necessarily where) the fault occurs, try running it from the shell and let the VC++ debugger attach itself (press the "debug" button). 

  If running from the IDE reproduces the problem, you could set a breakpoint early in the app (first line in WinMain or main perhaps), and step-by-step.

  Brian

   

  
  

• victtim

  There is not enough information. Allow the debug infos to be used for the release build. Than start the release build in the debugger or attach the debugger when the application crashes. Look into the callstack.
  
  

• tamzyn

  Compile your application under the debug configuration, and run by pressing F5. the Visual C++ debugger should take you to the source code line where the crash occurs. At that point, diagnose the bug and fix it.

  Brian

  
  

• Fchans

  There is no fault in the code, it is not that, i just dont know why it is doing it, its odd, and other people are experiencing the same problem as me.

  
  

• HHAAPPYY

  ok the thing is that there is no problem with the debugger.

  when you compile release or run the exe of a debug build direct have bits missing. for his the file open didnt work. and with release there was no graphics.. theres nothing specific..It "crashes " when you try and quit the application.

  does it have to do with NET runtime files

  any idea

  lilly

  
  

• JeffSeifert

  As I understand you so far, the bug doesn't manifest itself when running from the IDE, but rather from the shell.  What I don't know is whether launching a debug app from the shell manifests the problem.  Assume release only:

  As Martin says, make sure you are enabling debug mode on the Release files (which usually occurs on default projects).  Do this in two parts:

  Set Project Properties->C/C++->General->Debug Information Format->Program Database for Edit and Continue (/Zi)

  Set Project Properties->Linker->Debugging->Generate Debug Info=Yes (/DEBUG).

  Now set a hardcoded breakpoint at the entry point of your application: e.g. in WinMain(), add __debugbreak().  This is a compiler intrinsic that injects the machine instruction Int 0x3, which is a breakpoint.  Run it, let the debugger attach to the point of Int 0x3, and then step through the application, with the intention of finding out more clues as to why this crash is occuring.

  Now if this does manifest under debug, you're obviously better off debugging using it instead of Release, since stepping through release code is a bit messy due to optimizations that have occurred.

  Brian

  
  

• r3ds0x

  Brian Kramer wrote:

  As Set Project Properties->C/C++->General->Debug Information Format->Program Database for Edit and Continue (/Zi)

  Just a small correction: Use /Zi as Brian wrote, but the setting is not "Program Database for Edit and Continue". This would be /ZI.

  Use /Zi (Program Database). This is sufficient for getting the smallest executable with the program database. Edit and Continue might increase the exe file and it is wise to have the pdb files for every version of an exe/dll you ship. This helps you to find problems and bugs at the customer.

  
  
  
• Visual C++ windows Application Executable file Crash