One of my win32 application working fine in debug mode.but malfunctioning in release mode.Can i do debug operation on release mode?I tryed to debug in release mode,But valuse showing is not correct.How to solve this problem?
Printable View
One of my win32 application working fine in debug mode.but malfunctioning in release mode.Can i do debug operation on release mode?I tryed to debug in release mode,But valuse showing is not correct.How to solve this problem?
Well, you are not the first having such a problem. See Surviving the Release Version
Yes, you can. See How to: Debug a Release Build
Fix your bugs.
I made changes on Project property to debug my relaese build,But still i am not getting the correct values for the variable,Quote:
Suppose i have writtenAdd watch for a will show zero,Like that happening,Second thing,Now i canot debug my debug build one.What to do, i am entirely stucked.Please help meCode:int a=10;
You are getting confused with what a "debug" build is.
All you're doing when you turn on debugging is generating the necessary information to generate .PDB file. That PDB file is then matched with the source code. You can turn on debug symbols for any configuration, whether it is called "Release", "debug", "ReleaseWithMyOwnStuffAdded", etc. Similarly, you can turn off debugging when you choose the "Debug" configuration.
Now, when the preprocessor symbol "DEBUG" is defined, it pulls in extra code that allows heap analysis, checking for invalid pointers etc. That's all -- nothing else. It doesn't turn on or off generating information necessary for the debugger to work. That is done in the Linker and Compiler options for Debugging.
Regards,
Paul McKenzie
Ok.I didn't understand completely what is debugging,any how i got a brief idea.Now my application working fine with development system .But same application(Release build with optimization enabled/Disabled )running on other PC(other than developmentPC)misbehaving.Please give me some solution,What may be the reason for that?
There may be a lot of...
Different environments, working directories, and so on.
Do you, for example, open some file using its relative or some hard coded path?
In any case you have to check the return values of all the APIs you call and signal somehow if they failed...
See more here
At first you must locate it. Where in your code does it happen?
What is the exact error message? Address?
Sometimes you can finf this info in the Windows event viewer.
You have never heard of an application that works in the shop, but fails at a customer's site? You've never read the release notes of various applications, and find that they have fixed bugs (usually identified by other users)?
Just because a program works on your PC means nothing except you have an expectation that it should work on another PC. But nothing guarantees it working -- that's why you see the cases I mentioned above.
Unlike most other computer languages, when you make a mistake in a C++ program, there is no guarantee how your program will behave. For example, if you don't check the return values for functions and you expect the function to always work, what happens when that function returns a failure value? Since you didn't check the return value, your program then goes on the path that things are OK when they are not OK.
What if you don't initialize your variables? What if that uninitialized variable just happens by luck be 0 every time you run it on your machine, and thus your program "works"? However on another machine that uninitialized variable value is -748932478. Then your program fails.
These are just a few of the scenarios that cause applications to fail. There are many more, and you must have the expectations that these things will happen and be prepared to debug as best as possible these scenarios.
Regards,
Paul McKenzie
Does the program misbehave on all other pcs apart from your development system - or works on some pcs but not all?
What do you mean by 'misbehave'?
Apart from suggestions from Paul, Victor and Ignor, another possible reason could be buffer overflow, memory corruption etc from a bug in the program not picked up during debugging. Just because a program 'works' on one pc doesn't necessarily mean that the program will work on other pcs!