Program crashes when outside test environment - C++

Question

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.

See if the response(s) here helps you: http://stackoverflow.com/questions/5905110/why-does-my-multithreaded-c-net-application-only-crash-when-executed-outside-o — yasouser, Jun 10 '11 at 01:51
@user791928 It just says ".exe has stopped working" and then closes. — Satchmo Brown, Jun 10 '11 at 01:54
@yasouser It is not a multithreaded application but thank you. — Satchmo Brown, Jun 10 '11 at 01:54
Should I just upgrade my Visual Studio to the full thing and then attach to the debugger? — Satchmo Brown, Jun 10 '11 at 01:55
@Satchmo: You don't need to; just use Debugging Tools for Windows. — Downvoter, Jun 10 '11 at 02:05

score 2 · Answer 1 · answered Jun 10 '11 at 01:54

2

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.

answered Jun 10 '11 at 01:54

zdan

28,667
7
60
71

Yeah, I wish I had more information to give but I really don't. If I upgrade to the full version, can I attach the debugger to the external .EXE and see what line is causing the crash? – Satchmo Brown Jun 10 '11 at 01:58
@satchmo: If you want to save some cash and are adventurous, I would reccommend downloading the free WinDbg (http://msdn.microsoft.com/en-us/windows/hardware/gg463009). It has all the functionality you need to debug, but is a bit less user friendly than the IDE version. – zdan Jun 10 '11 at 17:35

score 2 · Answer 2 · answered Jun 10 '11 at 02:09

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.

I will look into that. Installing the full Visual Studio too so hopefully I can debug. — Satchmo Brown, Jun 10 '11 at 02:16
@Satchmo: You sound too desperate to upgrade to a full blown version of VS :). Like others suggested the Debugger Tools for Windows has everything you need. If you have the pdb, you can step through your code like you will in the VS's integrated debugger. — yasouser, Jun 10 '11 at 12:55

score 2 · Answer 3 · answered Jun 10 '11 at 02:43

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.

Actually you forgot to mention that it is not necessary to debug the live process. Asp art of the crash of the process a dump or minidump file (depending on the windows configuration) is produced. You can load the dmp file in the debugger and analyze it. — steve, Jun 10 '11 at 04:04
@Steve Yes, true. Good comment. I took his statement of "I want to attach it to the .exe" quite literally. The advantage of the live debugging is that the debugger will stop right at the exception. Whereas, depending on how the dump is created, you'll either be lucky and be greeted at the context upon loading it in the debugger, or you'll need to .cxr or inspect the callstack thru the ntdll handlers for the right frame that blew up (or let !analyze do the work). — nithins, Jun 10 '11 at 14:21

score 0 · Answer 4 · answered Sep 02 '13 at 14:41

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.

score 0 · Answer 5 · answered Jun 10 '11 at 13:45

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.

Program crashes when outside test environment - C++

5 Answers5

Linked