You can share the serial port with the debugger although most of the time it isn't required and causes additional complications.

For example the "At Brkpnt"message can be produced by a breakpoint by setting the "When Hit" message property. So there is little point in adding your own serial message.

The debugger works in exactly the same way as when you manually add "Serial.print" code so this problem is the arduino trying to send tooo much data toooo quickly... 

If you are adding serial print messages to code that runs as fast as the arduino loop() then normally you would have to take care or add small pauses after x number of serial.print() messages otherwise the buffer on the arduino overflows because it is not able to transmit the data fast enough.

Adding a breakpoint to a serial.print() is the one thing that is not really supported because there is no need for it and will certainly cause too many arduino serial messages. It's like adding the following code manually to your arduino project.

Serial.println("I am at line 5 and doing stuff, and some stuff here");
Serial.println("I am at line 5 and doing stuff, and some stuff here");
 

Visual Micro makes allowances for new users that might add breakpoints into the 16mhz loop() or any other fast running code but it can't make allowances for your own serial code so you have to do that or take care.

In a real program you wouldn't really want serial messages at 16mhz, you would send them only in response to certain events. Ensuring that we have no more than 10 messages per second it normally good.

9600 will make the problem worse because it will take longer to send the messages.

Try this test, it's just a test not a suggestion for a real program! Add a "delay(10);" between your message and the breakpoint line. Does that fix it? If so then you really don't need the delay you just need to make sure serial.prints are not to close to a breakpoint or that you use the breakpoint condition facility to limit the number of times the breakpoint is hit or use code to conditionally limit when the serial message and breakpoint are emitted.

There is a lot to this senario that I could explain but don't want to confuse things at this point. Until you are more experienced with serial message rates and the arduino it might be an idea to use one system or the other. Use your own serial messages OR use breakpoints. Not both in an unconditional scenario.

If you have an FTDI USB cable you also have the option of using SoftwareSerial for the debugger. SoftwareSerial can use any of the digital pins on the arduino instead of the main usb serial port. By splitting your serial messages from the debugger messages you won't hit buffer overflows so easily, if at all.

I hope this helps, I will try to make a better document to shows some examples of how this can work and why it won't work if the amount of data exceeds what the arduino can handle.

Feel free to show your code in this thread and to explain where you have breakpoints. 

Also confirm if you are also using the automatic reports such as DigitalPins because these cause additional messages and will be more prone to issue if you have manual serial.prints. Again there are other ways to configure the automated reports so they are transmitted as part of a breakpoint instead of in-addition to a breakpoint.