This is a discussion on Using the Debug mode ((F10) V.S 2005 within the Windows Programming forums, part of the Platform Specific Boards category; Originally Posted by matsp Are you sure you don't get a compiler error or some other inconsistency in your building ...
F10 is step over. It executes any functions without stepping into them.
To step in, use F11.
In Release, debugging can be somewhat more difficult because the compiler can inline and remove code (optimize), thus it may be seen as stepping over something it shouldn't or jump around erratically and other things. This is normal.
In summary, the compiler may do anything it likes that doesn't change the outcome of the code itself. This makes it very tricky to debug the optimized code - I find it easier to follow the assembler code rather than the source code when debugging optimized code - but that probably comes from a long experience in debugging assembler code.
If it is possible to reproduce the bug with debug mode, then use that fore debugging. If you can only reproduce the bug in release mode, then you have to struggle with it.
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
The idea is to do the debugging in debug mode. The debugger is completely unreliable in release mode and as others have said it will skip breakpoints and refuse to show data to you in watches.
However I've not had a problem debugging console apps with VS 2003 or 2005. Not sure what the problem is here but I have no issues. You can output to the screen just fine and click on your app in the task bar and it will repaint itself. I debug console apps all the time at work and rarely need to use my second monitor. You could remote debug the app but then that is overkill.