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.