Program crashes when outside test environment - C++_问答_开发者

I have a program that runs fantastically when run from inside Visual Studio 2010 Express but when built and taken out, it has problems. I have set up the external test environment the same as when it is run from within Visual Studio so that shouldn't be the problem. I want to开发者_高级运维 attach it to the .exe to see where the crash is but I don't have the non-Express versions.

Any suggestions? Why would a program crash outside of the the VSC++ 2010 Express environment but run perfectly inside.

I would post code but it's a huge project, not a line that would cause an error.

Thank you so much for your time.

It's very difficult to know for certain without knowing what the crash is, but a couple of common issues that may cause this:

Environment variables not the same. Perhaps you are relying on something in vcvars32.bat in your test environment.
The PATH environment variable is not the same and your picking up some bad or incompatible DLL.
Your code is somehow dependant on the current working directory being the one when run from Visual Studio.

Wikipedia to the rescue?

Time can also be a factor in heisenbugs. Executing a program under control of a debugger can change the execution timing of the program as compared to normal execution. Time-sensitive bugs such as race conditions may not reproduce when the program is slowed down by single-stepping source lines in the debugger. This is particularly true when the behavior involves interaction with an entity not under the control of a debugger, such as when debugging network packet processing between two machines and only one is under debugger control.

Also, note that User32.dll slightly changes its behavior when under a debugger, in order to make debugging easier for you. That shouldn't change anything, though.

You could debug this using the freely available Debugger Tools for Windows. There's plenty of documentation and quick start guides available, especially the chm included in the install. In your case, you may want to try the following:

Make sure you have the PDBs for your app available somewhere on a share.
Attach to the running instance of the app: windbg -p <PID>. Note that you can also start the program under the context of the debugger by doing windbg -g foo.exe.
Repro the crash.
Change the symbol path to your symbols and the Microsoft public symbol server to get proper symbols for components: .sympath x:\YourPathToPDBs; SRV*x:\symbols*http://msdl.microsoft.com/download/symbols
Tell the debugger to reload symbols using your path: .reload
Get a callstack by hitting k in the debugger.

That's the barebones you need to figure out where it's crashing. You can then go deeper and try to analyze exactly why it's crashing by looking at the debugger chm or other resources on MSDN or Tess's blog. One useful command is dv to dump local variables for a particular frame. If the callstack doesn't give line numbers, type .lines and then hit k or kb.

You could surround all code in your Main function with a try catch block. When you catch an excepcion, write to a log file the stack trace.

Then run your exe and check the log file to know where your program is crashing.

PS: Don't forget to place the *.pdb file together with the exe file, otherwise you won't be able to get the stacktrace information.

I realise this question is a couple of years old, but I have been experiencing the same thing and came upon a possible culprit (the actual culprit in my case), which may help others who have this issue.

One important difference when running an application within Visual Studio and running it outside is the Current Working Directory ("CWD").

A typical directory structure for a Visual C++ Solution/Project is along these lines:

Solution     <- the location of your solution file
  Debug      <- where the Debug executables end up
  Release    <- where the Release executables end up
  Project    <- the location of your project file
    Debug    <- where Debug intermediate files end up
    Release  <- where Release intermediate files end up

When you execute the application from within Studio, either with "Start Debugging" or "Start Without Debugging", the default CWD is the Project directory, so in this case Solution\Project.

However, when you execute outside by simply double-clicking the application, the CWD is the application directory (Solution\Debug for example).

If you are attempting to open a file from the current directory (which is what happens when you do std::ifstream ifstr("myfile.txt")), whether it succeeds depends on where you were when you started the application.