Differences in USB ports when talking (to C#)

I'm currently writing a program in c# that will take in data from my device and display it, as well as graph it in real time. My device is powered off of a Due.

My current c# program uses the event SerialDataRecievedEventArgs to trigger when to read the data from the serial port. What I am noticing is that when I send the data out of the programming port, things work as intended, the program picks up the data. When I send it out of the Native port the event never triggers. It's as if c# doesn't realize there was any data received.

Interestingly this is not what happens when I open the arduino serial monitor. That picks up everything. Does the arduino serial monitor run off a timer or a data received event? Is there a difference in the packets that are sent from a due when using the separate ports (Using Serial.print vs SerialUSB.print)? Are there differences in stop bits, parity, or data bits?

I have the right COM port selected in each case and the baud rate is at 115200 for both.

If you use the native port, there are no stop bits or parity bits. There isn't even a baud rate. (Note the serial monitor will always connect to the native port, even with the wrong baud rate.)

Until your sketch on the Due starts running and initiates SerialUSB.begin() there isn't a serial port to connect to. Perhaps if you test when the C# program only attempts to connect after the Due is running?

MorganS:
If you use the native port, there are no stop bits or parity bits. There isn't even a baud rate. (Note the serial monitor will always connect to the native port, even with the wrong baud rate.)

Until your sketch on the Due starts running and initiates SerialUSB.begin() there isn't a serial port to connect to. Perhaps if you test when the C# program only attempts to connect after the Due is running?

I can only connect to the com port when the due is running.

I found a solution in somebody's similar problem trying to do this with processing. That was to add DtrEnable=true after opening the port. Still not sure how the port itself works, but thanks for the insight.