Yes, surely what NooM said; I get that all the time too, when there is junk on the line (like when the serial device powers up or down), or if the port is configured incorrectly.
I would add this:
* when faced with a problem like this, you can wrap the failing call in a try, and catch the exception. the exception object has some useful info sometimes
catch (Exception e){ Debug.Print("exc in Blahblah: " + e);}
this isn't real error handling, but you can get some info. even setting a breakpoint there will allow you to look into 'e' and see it's members
* when faced with a problem like this, I break the compound statement into distinct lines, so I can see which call failed. the GetChars? the new string? The Debug.Print? (its surely the GetChars in this case, but you see what I mean about breaking the compund statement up to find the particular statement that is throwing).
* when debugging the serial protocol, as NooM also points out, it's useful to dump the raw binary. Heres a little thing I find handy:
public static string HexStr(byte[] p, int nIdxStart, int nCount){ char[] c = new char[nCount * 2]; byte b; for (int y = 0, x = 0; y < nCount; ++y, ++x) { int nIdx = nIdxStart + y; b = ((byte)(p[nIdx] >> 4)); c[x] = (char)(b > 9 ? b + 0x37 : b + 0x30); b = ((byte)(p[nIdx] & 0xF)); c[++x] = (char)(b > 9 ? b + 0x37 : b + 0x30); }return new string(c);}
Good Luck!