Hi all. I'm trying debug a MultiWii pre2.4, but in finish line I have a few errors and process is stoped. In release mode everything is ok, project compiling without problem.
I'm using Atmel Studio 6.2, Arduino IDE 1.0.3,  Arduino IDE 1.6 and last version of Visual Micro plugin. 
Flight controller is Crius AIO v1, with ATmega 2560
There is error log

As I understand, MultiWii have his own Serial lib. 
I tray run project in release mode with Serial.println() and I'm got the same error, like with debug mode. 
Can you please watch in my project?
https://www.dropbox.com/s/3zahwt9568wjmu4/MultiWii_debug_error.zip?dl=0

I've looked at the build temp you sent me which has a copy of the core.

Debug is going to be a problem on the main serial ports as is currently stands because the core dumps the old Arduino serial and replaces with an alternative. At first glance the issue appears to be that the replacement is not wrapped in a class that derives from the print class which Visual Micro uses to transmit the various types of data (automatically converting to ascii).

Instead you could use the SoftwareSerial option (in the project properties) and hook up an ftdi cable or xbee to one or two spare pins on the MultiWii board. You only need 1 pin for trace only debug or 2 pins for trace/break/write.

One warning about debugging any moving vehicle is that the debugger will slow the arduino processor down and cause it to pause if breakpoints are hit more than once within each 100ms time period. This is called "debug throttle", you can switch the throttle off in the project properties "Throttled Enabled". 

If you switch the throttle off then you will need to make sure you don't flood your pc with thousands of debugger trace messages by adding trace points at locations in the code that give useful information at a controlled rate. Alternatively use conditional or timed breakpioints (see breakpoint properties). The Arduino can send messages faster than the debugger can process them (more than 8 per second is pushing it on some pc's

Please also remember that if you use breakpoints instead of trace points, the arduino will pause/delay() until you tell the debugger to continue. A moving drone will either stop dead or become out of control at that time. 

Lastly bear in mind that, debugger aside, using additional serial in a drone project might affect the critical timings that were created during the calibration phase but that also need to be consistent. 

With wheels or props attached, it might be that well placed tracepoints (without Throttle) might be the only safe debugger features to use in your project.

Sorry for the obstacles but better safe than sorry