The following tradeoffs and restrictions apply to using traceback:
Using the /traceback option to get automatic PC correlation does increase the size of an image. For any application, the developer must decide if the increase in image size is worth the benefit of automatic PC correlation or if manually correlating PC's with a map file is acceptable.
The approach of providing automatic correlation information in the image was used so that no run-time penalty is incurred by building the information "on the fly" as your application executes. No run-time diagnostic code is invoked unless your application is terminating due to a severe error.
At the heart of the stack walking code is the Win32 routine StackWalk( ) found in imagehlp.dll. In the ia32 systems environment, there are no firm software calling standards documented. Compiler developers are under no constraints to use machine registers in any particular way or to hook up procedures in any particular way. The StackWalk( ) routine therefore, bases its decisions on how to walk the call stack on a set of heuristics. That is, it makes a "best guess" to determine how a program reached a particular point in the call chain. With C code that has been compiled with Visual C++ with the Frame Pointer Omission Option (/Oy) enabled, this "best guess" is not usually the correct one.
If you are mixing Fortran and C code and you are concerned about stack tracing, consider disabling this option (/Oy-) in your C compiles. Otherwise traceback will most likely not work for you.
When incremental linking is enabled, automatic PC correlation does not work. Use of incremental linking always disables automatic PC correlation even if you specify /traceback during compilation.
When you use incremental linking, the default hexadecimal (hex) PC values will still appear in the output. To correlate from the hexadecimal PC values to routine containing the PC addresses requires use of a linker map file. However, if you request a map file during linking, incremental linking becomes disabled. Thus to allow any PC values generated for a run-time problem to be helpful, incremental linking must be disabled.
In the visual development environment, you can use the Call stack display, so incremental linking is not a problem.
Programs can fail for a multitude of reasons with unpredictable consequences. Memory corruption by erroneously executing code is always a possibility. Stack memory may be corrupted in such a way that the attempt to trace the call stack will result in access violations or other undesirable consequences. The stack tracing run-time code is guarded with a local exception filter. Should the traceback attempt fail due to a hard detectable condition, the run-time will report this in its diagnostic output message as:
Stack trace terminated abnormally
Be forewarned, however, it is also possible for memory to be corrupted in such a way that a stack trace can seem to complete successfully with no hint of a problem. The bit patterns it finds in corrupted memory where the stack used to be, and then uses to access memory, may constitute perfectly valid memory addresses for the program to be accessing. They just do not happen to have any connection to what the stack used to look like. So, if it appears that the stack walk completed normally, but the reported PC's make no sense to you, then consider ignoring the stack trace output in diagnosing your problem.
You may also see the stack trace fail if the run-time system cannot dynamically load imagehlp.dll or cannot find the routines from that library it needs to do the stack walk. In this case, you would still get the basic run-time diagnostic message. You just will not get any call stack information.
Another condition that will disable the stack trace process is your program exiting because it has exhausted virtual memory resources.